Why You Should Default to arm64 for New AWS Lambda Functions

When creating a Lambda function, you can choose between x86_64 and arm64 for the architecture.

Until now, I have often created them with the default x86_64 without thinking too much about it, but upon investigation, I felt that it is generally fine to start with arm64 for new Lambda functions.

The reason is simple: based on official AWS information, arm64 has lower costs for execution time and can be faster depending on the workload.

Of course, it does not mean arm64 is always the best choice in every situation, as there can be compatibility issues with native binaries, Lambda Layers, and extensions. Therefore, my personal policy is:

1. Start new Lambda functions with arm64.
2. Consider x86_64 if issues arise due to dependencies or measured performance metrics.

I think this is a reasonable approach.

What is Lambda Architecture?

Lambda architecture refers to the type of processor used to run the function.

AWS documentation explains that Lambda offers the following two types:

Architecture	Description
arm64	64-bit ARM architecture for the AWS Graviton2 processor
x86_64	64-bit x86 architecture for x86-based processors

In short, choosing arm64 means your Lambda will run on AWS Graviton2.

By the way, if you do not explicitly specify it, the default is x86_64. If you are managing your infrastructure with CDK or SAM, it is possible that it has been left as the default unintentionally.

The Cost Benefit is Almost Guaranteed

First, let's look at pricing.

Here, I am assuming a standard on-demand Lambda execution. While there are other cost elements such as Lambda Managed Instances, Durable Functions, and additional ephemeral storage, roughly speaking, standard function execution costs are mainly determined by:

• Number of requests
• Execution time

What arm64 affects here is the price for execution time. The AWS blog states that Arm/Graviton2 Lambda functions have a 20% lower duration charge compared to x86.

Roughly speaking, for the same memory and the same execution time, arm64 is cheaper.

For example, if you have a process that runs for 1 second with 1GB of memory, the execution time portion (excluding request costs, etc.) will be cheaper with arm64. Although unit prices vary by region and pricing tier, the example on the AWS pricing page for US East uses $0.0000166667 / GB-second for x86 and $0.0000133334 / GB-second for Arm.

Looking at the unit price alone:

0.0000133334 / 0.0000166667 = approx 0.8

This is approximately a 20% discount.

This does not mean that total costs, including request fees, are reduced by 20%. The main reduction applies to the charges for the function's execution time.

Performance Depends on the Workload

Next is the performance aspect.

AWS claims up to 19% performance improvement and up to 34% price-performance improvement for Graviton2 Lambda. This means that in addition to the 20% lower cost, execution times can also be shorter, resulting in better price performance.

However, it is risky to say that it is "always faster."

Even in the AWS migration guide, it is written that performance does not improve for all workloads, so you should test with your own specific workload.

Therefore, the right understanding is:

• Unit price is cheaper for arm64
• Performance varies by workload
• arm64 is cheaper if the speed is about the same
• It is even more beneficial if the process becomes faster

Conversely, if arm64 causes your execution time to slow down by more than 25%, it might cancel out the benefit of the cheaper execution time price.

x86_64 execution time price = 1.0
arm64 unit price = 0.8

If arm64 is 1.25 times slower:
0.8 * 1.25 = 1.0

If the slowdown exceeds this threshold, x86_64 might be better from a cost perspective. However, if performance degrades that significantly in a standard Lambda function, there is likely a specific reason related to dependencies or process content.

Lambda Functions Well-Suited for arm64

Personally, I felt that the following types of Lambda functions are good candidates for arm64 from the start:

• Simple APIs written in Node.js or Python
• Processes calling AWS SDKs such as DynamoDB or S3
• Processes running on bytecode like Java
• CPU-intensive tasks such as image processing, data processing, or encryption
• Processes with high execution frequency where even small unit price differences accumulate

In particular, if your dependencies do not contain architecture-specific binaries, switching to arm64 is quite easy. The AWS blog also mentions that interpreted languages like Node.js and Python, or those using Java bytecode, are good examples that are easy to switch provided there are no binary dependencies.

Furthermore, as of May 2026, AWS documentation states that supported Lambda runtimes support both x86_64 and arm64. As long as you are using major managed runtimes, there will be very few situations where you cannot use it because the "runtime does not support arm64."

Points to Consider

That said, the biggest thing to be careful about with arm64 is dependencies.

If the Lambda code itself consists only of JavaScript or Python, it is unlikely to cause issues, but the situation changes if your dependency packages include native binaries.

Examples include:

• Native addons in npm packages
• Wheels in Python packages
• Executables built with Go, Rust, C++, etc.
• Binaries included in Lambda Layers
• Lambda Extensions
• Container images

These must be built for arm64.

AWS documentation also explains that function code, layers, extensions, and container images must be compatible with the function's architecture.

Especially if your local PC or CI environment is x86_64, running npm install or pip install and zipping them without thinking can sometimes result in x86_64 artifacts being mixed in. If you are running on an arm64 Lambda, it is safer to build for the same Linux + arm64 target as the Lambda environment.

Specifying with CDK

With CDK, you simply specify the architecture.

import * as lambda from 'aws-cdk-lib/aws-lambda';

new lambda.Function(this, 'MyFunction', {
  runtime: lambda.Runtime.NODEJS_22_X,
  handler: 'index.handler',
  code: lambda.Code.fromAsset('lambda'),
  architecture: lambda.Architecture.ARM_64,
});

For SAM / CloudFormation, specify arm64 in Architectures.

MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    Runtime: nodejs22.x
    Handler: index.handler
    CodeUri: src/
    Architectures:
      - arm64

If you are creating via AWS CLI, use --architectures arm64.

aws lambda create-function \
  --function-name MyArmFunction \
  --runtime nodejs22.x \
  --architectures arm64 \
  --handler index.handler \
  --zip-file fileb://function.zip \
  --role arn:aws:iam::123456789012:role/service-role/MyRole

Cases Where You Should Choose x86_64

Conversely, cases where it might be fine to use x86_64 from the beginning include:

• The library you want to use does not support arm64
• Vendor-provided binaries are only available for x86_64
• Lambda Layers or Extensions require x86_64
• You cannot build container images for arm64
• Measured performance shows arm64 is clearly slower
• The verification cost for a production migration is not worth it

There is no need to force the use of arm64 in these situations.

In particular, processes with many native dependencies often get stuck due to build environment or distribution binary issues rather than the application code itself. If you are going to waste time there, I think it is more realistic to keep it running on x86_64 and optimize it later if necessary.

Personal Conclusion

I have decided to think about Lambda architecture as follows from now on:

Situation	Selection Policy
New Lambda	Start with arm64
No native dependencies	Should be fine with arm64
Managed by CDK / SAM	Explicitly specify arm64
Existing production Lambda	Gradual migration while watching metrics
Stuck due to dependencies	Revert to x86_64
Slower based on measurement	Consider x86_64

In short, my stance is "basically arm64, revert to x86_64 if in trouble."

arm64 has a lower unit cost, so if it runs about the same, that alone is a reason to adopt it. Furthermore, it can be faster depending on the processing, so there are fewer reasons than before to deliberately start with x86_64 for new Lambda functions.

Closing Thoughts

I hadn't been very conscious of Lambda architecture until now, but upon investigating, I found that arm64 is a very standard choice to use.

Especially for new development, it seems best to create it with arm64 from the start. It is easier to have the dependencies and build environment based on that premise from the beginning than to migrate from x86_64 later.

Of course, actual performance depends on the workload. However, the cost benefits are easy to understand, so I plan to proceed by creating with arm64 first and considering x86_64 if something goes wrong.

References

• AWS Documentation - Configuring Lambda function options
• AWS Lambda Pricing
• AWS News Blog - AWS Lambda Functions Powered by AWS Graviton2 Processor
• AWS Compute Blog - Migrating AWS Lambda functions to Arm-based AWS Graviton2 processors
• AWS Documentation - Lambda runtimes