Explanation
Why the waste happens and who it affects.
For many workloads, especially those written in interpreted languages (e.g., Python, Node.js) or compiled to architecture-neutral bytecode (e.g., Java), there is no dependency on x86-specific binaries. In such cases, moving to Arm64 can reduce compute costs by 20% without impacting functionality. Despite this, many teams continue to run Lambda functions on x86_64 due to legacy configurations, inertia, or lack of awareness. This leads to avoidable spending, particularly at scale or in high-volume environments.
Billing model
The pricing dimensions that drive this cost.
Lambda is billed based on:
- Number of requests
- Duration of execution (in milliseconds)
- Memory allocated
- CPU architecture (Arm64 functions cost up to 20% less than x86_64)
How to detect
5 checks to find it in your estate.
- Architecture is set to x86_64
- Function code does not rely on architecture-specific binaries or compiled dependencies
- Runtime is compatible with Arm64 (e.g., Python, Node.js, Java)
- High aggregate usage of "GB-seconds" across x86 functions contributes significantly to Lambda costs
- No benchmarking or cost comparison has been performed between x86 and Arm
How to fix
5 ways to remove the waste.
- Benchmark representative functions on both architectures to validate performance and compatibility
- For functions using architecture-neutral runtimes or dependencies, migrate to Arm64 via configuration update
- Ensure CI/CD pipelines and IaC templates default to Arm64 for new functions
- Educate development teams on architecture implications and expected savings
- Use tagging or cost attribution to track savings post-migration
Documentation
Vendor references for pricing and configuration.