← Insights  ·  July 2026 · 7 min read

The Graviton Math: When ARM Beats x86 on Your AWS Bill

AWS's ARM-based Graviton instances price out around 20% below comparable x86, and newer generations often outperform the x86 instances they replace. The question isn't whether to migrate. It's which workloads, in what order.

Start where migration is a config change

The best Graviton candidates involve no application changes at all, because AWS runs the software for you:

• RDS / Aurora: change the instance class from db.m5 to db.m7g. The engine is AWS's problem, not yours.
• ElastiCache and OpenSearch: same story. Pick the Graviton node type at the next maintenance window.
• Lambda: set the architecture to arm64. Duration pricing is about 20% cheaper, and most runtimes just work.

If you run managed databases on x86 today, this is usually the largest zero-code-change saving left on the table.

Then the workloads that need a rebuild, not a rewrite

Containerized Linux services are the next tier. Modern base images ship arm64 variants, and docker buildx produces multi-arch images from the same Dockerfile. Interpreted and JIT-compiled stacks (Node, Python, Java, Go, .NET Core) run on ARM without source changes. The work is in your CI pipeline and your test plan, not your codebase.

And the ones to leave alone

• Windows workloads: no Graviton support. Different levers apply there (licensing, rightsizing).
• Closed-source x86 binaries: if the vendor doesn't ship an arm64 build, you're stuck. Check first; most major agents (Datadog, CrowdStrike, New Relic) now support ARM.
• Anything with hand-rolled SIMD or native extensions pinned to x86: possible, but benchmark before you commit.

A worked example

Say you run 40 m5.2xlarge instances around the clock (us-east-1, on-demand):

The third row is the part teams miss: because the newer generation performs better per vCPU, load testing often shows you can serve the same traffic with 10–20% fewer instances. The sticker discount is 15%; the real number after consolidation is closer to 28%. Stack a Savings Plan on top and the compound discount gets serious.

The rollout that doesn't bite back

• Pick one stateless service. Build multi-arch. Deploy one canary behind the load balancer.
• Compare p95 latency and error rates against the x86 pool for a week.
• Roll forward service by service. Keep the x86 launch templates around for 30 days as an exit.

Do managed services first, then containers, then EC2 fleets. Leave Windows and vendor-locked binaries for last or never. That order front-loads the savings and back-loads the risk.

Written by Ruben Rivero, AWS Certified Solutions Architect – Professional. 12+ years running enterprise AWS environments.