My full-stack application runs on Lambda, and the bill has somehow reached an absurd $3.5 billion. Could switching the functions from x86_64 to ARM64 meaningfully reduce compute costs, or should I be investigating other causes first? I'm also wondering whether concurrency limits, unusually heavy workloads, or moving certain tasks to containers or virtual machines would have a bigger impact.
3 Answers
Put a reserved or account-level concurrency limit on the functions so a traffic spike or retry loop can’t keep creating more execution environments. Also check for recursive triggers, failed jobs being retried, and scheduled tasks that may be running far more often than intended.
At that scale, don’t focus only on ARM64. Profile the expensive operations and consider moving long-running or consistently heavy workloads to a container service or regular virtual machines. Lambda is convenient, but it isn’t always the cheapest option for sustained processing.
ARM64 can reduce Lambda compute pricing and may offer better price-to-performance, but it won’t explain a massive bill by itself. First check the billing breakdown, invocation counts, duration, memory settings, retries, and any runaway workloads. Set budgets and alerts immediately so the spending can’t continue unnoticed.
That makes sense. I’ll inspect invocation volume and duration before treating the architecture change as the main fix.
Exactly. ARM64 may be a useful optimization, but workload shape and execution volume usually matter much more than the processor choice.