# Suboptimal architecture selection in AWS Lambda Canonical: https://www.pointfive.co/efficiency-hub/inefficiencies/suboptimal-architecture-selection-in-aws-lambda Lambda functions default to the x86_64 architecture, which is more expensive than Arm64. By: Andrew Shieh Updated: 2026-09-28 [Cloud Efficiency Hub](https://www.pointfive.co/efficiency-hub) # Suboptimal Architecture Selection in AWS Lambda The short version Lambda functions default to the x86\_64 architecture, which is more expensive than Arm64. [Andrew Shieh](https://www.linkedin.com/in/shandrew/) Principal Engineer / Director of Engineering, Operations @ SmugMug AWS service [AWS Lambda](https://www.pointfive.co/efficiency-hub/cloud-services/aws-lambda) Category [Compute](https://www.pointfive.co/efficiency-hub/service-category/compute) Reference CER-0218 Type Inefficient Configuration ## 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. - [Selecting and configuring an instruction set architecture for your Lambda function docs.aws.amazon.com](https://docs.aws.amazon.com/lambda/latest/dg/foundation-arch.html) - [Migrating AWS Lambda functions to Arm-based AWS Graviton2 processors aws.amazon.com](https://aws.amazon.com/blogs/compute/migrating-aws-lambda-functions-to-arm-based-aws-graviton2-processors/) - [AWS Lambda pricing aws.amazon.com](https://aws.amazon.com/lambda/pricing/) ## Related inefficiencies [Browse the library](https://www.pointfive.co/efficiency-hub) - AWS Lambda CER-0204 ### [Inefficient SnapStart Configuration in Lambda](https://www.pointfive.co/efficiency-hub/inefficiencies/inefficient-snapstart-configuration-in-lambda) SnapStart reduces cold-start latency, but when configured inefficiently, it can increase costs. For Python and .NET functions, high-traffic workloads can trigger frequent snapshot restorations, multiplying costs. Slow initialization code... Compute - AWS Lambda CER-0230 ### [Excessive Lambda Duration from Synchronous Waiting](https://www.pointfive.co/efficiency-hub/inefficiencies/excessive-lambda-duration-from-synchronous-waiting) Some Lambda functions perform synchronous calls to other services, APIs, or internal microservices and wait for the response before proceeding. During this time, the Lambda is idle from a compute perspective but still fully billed. This... Compute - AWS Lambda CER-0213 ### [Excessive Lambda Retries (Retry Storms)](https://www.pointfive.co/efficiency-hub/inefficiencies/excessive-lambda-retries-retry-storms) Retry storms occur when a function fails and is automatically retried repeatedly by the service that invoked it: asynchronous invocations (e.g., EventBridge, SNS, S3) are retried twice by default after function errors, SQS event source... Compute --- Source: the public page above. Product screenshots and illustrative interfaces are examples, not live customer data.