Lambda ARM Graviton savings: cheaper functions by switching architecture
Running Lambda functions on ARM-based Graviton instead of x86 costs about 20 percent less per unit of compute, and many functions run just as fast or faster. Here is how the savings work, what to check before switching, and how to migrate.
Quick answer
Switching a Lambda function from x86 to ARM-based Graviton lowers the per-millisecond compute price by about 20 percent, and because many workloads run equally fast or faster on Graviton, the effective savings can be even larger once you account for duration. The change is usually a one-line architecture setting plus rebuilding any native dependencies for ARM. Functions that are pure interpreted code (JavaScript, Python) or use ARM-compatible libraries switch easily; the main thing to check is that any compiled binaries or native modules have ARM builds.
AWS prices Lambda on the compute your functions consume (memory times duration), and it offers two processor architectures: x86 and ARM-based Graviton. Graviton is priced lower per unit of compute, so moving a function to ARM cuts its cost with, in many cases, no downside. It is one of the rare optimizations that is close to a free lunch: a configuration change that lowers the bill without degrading the workload.
How the savings work
| Architecture | Relative compute price | Notes |
|---|---|---|
| x86 | Baseline | Broadest compatibility |
| ARM (Graviton) | About 20 percent cheaper | Often equal or faster runtime |
The headline is roughly a 20 percent lower price per millisecond of compute on ARM. But Lambda bills on duration too, so if a function also runs faster on Graviton, the total savings compound: cheaper per unit and fewer units consumed. This is the same architectural savings that shows up across compute in the broader Graviton cost savings story, applied to the serverless world.
What to check before switching
The one real prerequisite is dependency compatibility. Pure interpreted code (JavaScript on Node, Python) generally just works on ARM. The risk is native modules and compiled binaries: any dependency with architecture-specific builds needs an ARM version. Check your packaged dependencies, container image base (if you use container-based Lambda), and any layers for ARM support. Most popular libraries publish ARM builds today, so this is usually a quick verification rather than a blocker.
How to migrate
For most functions the switch is a single architecture setting in the function configuration, plus rebuilding your deployment package on or for ARM so native dependencies are the right architecture. Test the function on ARM (correctness and latency) in a non-production environment, then roll out. Because the change is small and reversible, you can migrate function by function and measure the effect. Fold the expected savings into your overall Lambda picture from the Lambda cost deep dive.
When it is worth it
The savings scale with how much a function runs, so high-invocation, high-duration functions are where a 20 percent compute discount adds up to real money, and they justify the small migration effort first. Rarely invoked functions save little in absolute terms, so they are lower priority. For a serverless-heavy backend, moving the busiest functions to Graviton is a high-ROI change: minimal effort, durable savings, and no performance sacrifice, which is why it belongs near the top of any serverless cost review alongside right-sizing memory and cutting idle work described for a SaaS backend on AWS.
FAQ
How much does Lambda Graviton save over x86?
About 20 percent on the per-millisecond compute price. Because Lambda also bills on duration, the effective savings can be larger if a function runs faster on Graviton, since you then pay a lower rate for fewer units of compute. The exact benefit depends on the workload, but 20 percent cheaper compute with equal or better performance is the typical outcome for compatible functions.
Is switching Lambda to ARM hard?
Usually not. For most functions it is a single architecture setting plus rebuilding the deployment package for ARM so native dependencies are the right architecture. Pure interpreted code in Node or Python generally works immediately. The change is small and reversible, so you can migrate function by function, test correctness and latency in non-production, and roll out with low risk.
What could break when moving Lambda to Graviton?
Architecture-specific native modules and compiled binaries. Any dependency, container base image, or Lambda layer with x86-only builds needs an ARM equivalent. Most popular libraries now publish ARM builds, so this is usually a quick compatibility check rather than a blocker, but it is the one thing to verify before switching a function that uses compiled or native dependencies.
Do all Lambda functions run faster on Graviton?
Not all, but many run equally fast or faster, which is why the effective savings often exceed the 20 percent price cut. Performance depends on the workload, so test latency in a non-production environment before assuming a speedup. Even when performance is merely equal, the lower compute price still delivers the cost savings, so the switch rarely hurts and often helps.
Which Lambda functions should I migrate to ARM first?
The busiest ones. Savings scale with how much a function runs, so high-invocation, high-duration functions turn a 20 percent compute discount into real money and justify the small migration effort first. Rarely invoked functions save little in absolute terms and are lower priority. Prioritizing by total compute consumed gives the most savings for the least migration work.
Does C3X show Lambda architecture cost before deploy?
C3X reads your Terraform and prices Lambda functions against a live catalog before deploy, so the architecture and configuration choices that shape function cost are visible in the pull request. That helps you see the cost implication of x86 versus ARM at design time, alongside memory sizing, before the function ships and starts billing.
What to do next
Price your serverless architecture choices before they ship. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.
Pricing references
Related posts
- Graviton cost savings explained: ARM instances for less money
AWS Graviton (ARM) instances typically cost about 20 percent less than comparable x86 instances while often delivering better performance per dollar. For most workloads the switch is nearly free. Here is what Graviton saves and how to adopt it.
- Lambda vs EC2 cost breakeven: when serverless stops being cheaper
Lambda is cheap for spiky, low-utilization workloads and expensive for steady, high-utilization ones, where an EC2 instance running full-time wins. The breakeven depends on request volume, duration, and how busy the compute would be. Here is how to find the crossover.
- Lambda vs Fargate cost: which serverless compute is cheaper
Lambda charges per request and per GB-second and scales to zero; Fargate charges per vCPU and GB by the second for continuously running tasks. The cheaper option depends entirely on your traffic pattern. Here is how to choose.
- AWS Graviton migration: where the ~20% savings actually come from
Graviton (ARM) instances list ~20% cheaper than x86 with up to 40% better price-performance, across EC2, Lambda, RDS, and more. Here's the discount, where it applies, and how small the migration usually is.
Share this post
Try C3X on your own Terraform
Free and open source. No API key required. One command to install, one command to estimate.