AWS Lambda Support
AWS Lambda Graviton (arm64) migration.
Lambda can run functions on x86_64 or arm64 (Graviton). arm64 is priced lower per unit of duration and often performs as well or better, but only if every dependency has an arm64 build. We check compatibility, benchmark, and roll out with an easy way back.
When You Need This
The situations where this work pays for itself.
Signs it is time
- You want a lower Lambda bill without changing application logic
- Functions use only interpreted code and AWS SDK calls, so a move looks easy
- You ship Docker image functions and need multi-architecture builds
- Native libraries such as image, crypto or database drivers are involved
- You are already tuning memory and want to include architecture
What you get
- A compatibility report per function with blockers listed
- Updated build pipeline producing arm64 artifacts
- Benchmark results for x86_64 versus arm64
- A staged rollout and rollback plan
How we do it
A clear, safe process you can follow along with.
1. Inventory functions and dependencies
We list every function with its runtime, package type, layers and native or compiled dependencies. Pure Python, Node.js and Java code with no native modules is usually a simple switch.
2. Rebuild native dependencies for arm64
For zip packages we build dependencies on or for arm64, for example with a Linux arm64 build container, so compiled wheels and node addons match. A package built on x86_64 and shipped to arm64 fails at import time.
3. Fix layers and container images
Layers must declare a compatible architecture and contain arm64 binaries. For container images we build with buildx for linux/arm64 and use an arm64 Lambda base image.
4. Benchmark both architectures
We run the same payloads on x86_64 and arm64 with the power tuning workflow and compare duration and cost per invocation, because performance gain varies by workload.
5. Deploy with a weighted alias
We publish an arm64 version, shift a small share of traffic with an alias, and watch errors, duration and any import failures before moving fully.
6. Update CI and local builds
Build pipelines must produce arm64 artifacts or tests will pass on a different architecture than production. We update CodeBuild, GitHub Actions or SAM settings and keep a rollback version ready.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Switching the setting without rebuilding
Native code compiled for x86_64 will not load on arm64. The function fails on first import.
Skipping layers
A layer built for x86_64 breaks an arm64 function. Every layer in use needs checking.
Assuming faster means cheaper in every case
Some workloads gain little. We measure rather than assume.
Testing on the wrong CPU
If CI runs on x86_64 and production on arm64, bugs reach production. Tests should run on arm64 or in the same image.
Frequently Asked Questions
Is Lambda arm64 cheaper than x86_64?
arm64 has a lower price per GB-second. Whether total cost falls depends on how duration changes for your code, which is why we measure both.
Do all Lambda runtimes support arm64?
Current supported runtimes generally do, but check the Lambda runtime documentation for the specific runtime and version you use.
Can I switch back if something breaks?
Yes. Architecture is part of the function's code configuration, so you can publish an x86_64 version and point an alias back to it.
Want Help With AWS Lambda Graviton (arm64) migration?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required