AWS Graviton migration: where the ~20% savings actually come from

Quick answer

Graviton (ARM) instances list ~20% cheaper than the equivalent x86 family, with up to 40% better price-performance once you account for speed. The discount applies across EC2, Lambda (arm64), RDS, Aurora, ElastiCache, and OpenSearch, and stacks on top of Savings Plans. The only real cost is making sure your software runs on ARM64 — trivial for most modern stacks, impossible for x86-only commercial binaries.

Graviton is the rare cloud cost lever that's a near-pure win: same workload, ~20% lower bill, often with a performance bump on top. AWS designed its own ARM chips and prices the instances below the Intel/AMD equivalents to drive adoption. The reason teams haven't all moved is migration friction, not the savings math.

The discount, concretely

Compare a general-purpose instance across architectures in us-east-1:

m7i.large  (Intel x86)   2 vCPU, 8 GB   ~$0.1008/hour   ~$73.58/month
m7g.large  (Graviton)    2 vCPU, 8 GB   ~$0.0816/hour   ~$59.57/month
                                          difference     ~19% cheaper

That ~20% holds across families (c-series compute, r-series memory) and across services. On Lambda, switching a function to arm64 is ~20% cheaper per GB-second. On RDS and Aurora, the Graviton db instance classes (the g-suffixed ones) carry the same discount. Because Graviton is also faster for many workloads, you can sometimes drop to a smaller size, compounding the saving.

Where it applies

EC2: m7g, c7g, r7g, and the rest of the g-suffixed families. See the m5/m6i/m7i comparison for the x86 generations, then map to the g equivalent.
Lambda: architecture = "arm64", ~20% off per GB-second.
RDS & Aurora: Graviton db instance classes.
ElastiCache, OpenSearch, MemoryDB: Graviton node types at the same ~20% discount.

The migration friction (and how small it usually is)

The blocker is always the same: does your code run on ARM64?

Usually trivial: Python, Node, Java, Go, Ruby, .NET — interpreted or cross-compiled languages run on ARM unchanged. Container images just need an arm64 or multi-arch build.
Watch out for: native extensions and libraries without ARM wheels, old vendored binaries, and commercial/agent software shipped x86-only. Test these before committing.

A practical rollout: build multi-arch images, move a non-critical service first, verify, then migrate by family. The risk is low because you can roll back to the x86 instance type in one Terraform change.

Stacking with commitments

Graviton instances are covered by Compute Savings Plans and Reserved Instances, so the ~20% Graviton discount compounds with the 40-60% commitment discount on baseline capacity. See Reserved Instances vs Savings Plans for which commitment to use.

FAQ

How much does AWS Graviton actually save?

Graviton (ARM) instances list about 20% cheaper than the equivalent x86 instance, and AWS reports up to 40% better price-performance because the chips are also faster for many workloads. So the headline is ~20% on the rate and potentially more once you account for needing fewer or smaller instances.

Which AWS services support Graviton?

EC2 (the g-suffixed families like m7g, c7g, r7g), Lambda (arm64 architecture, ~20% cheaper per GB-second), RDS and Aurora (Graviton db instances), ElastiCache, OpenSearch, and more. The discount is consistent across them: roughly 20% off the x86 equivalent.

What's the catch with migrating to Graviton?

Your software has to run on ARM64. Most interpreted languages (Python, Node, Java, Go, Ruby) just work, and container images need a multi-arch or arm64 build. The friction is native dependencies, old binaries, and commercial software without ARM builds. For greenfield and most modern stacks the migration is small; for legacy x86-only software it may not be possible.

Is Lambda cheaper on Graviton?

Yes. Setting a function's architecture to arm64 is about 20% cheaper per GB-second than x86, and often faster, so the effective saving can be larger. It's usually a one-line change for runtimes without native dependencies.

Can I use Graviton with Reserved Instances and Savings Plans?

Yes. Graviton instances are covered by Compute Savings Plans and can be reserved like any other family, so the ~20% Graviton discount stacks on top of the commitment discount.

How does C3X help with a Graviton migration?

Change the instance_type or db instance class to the Graviton equivalent in your Terraform and re-run C3X — it reprices against the ARM rate so you see the saving before you migrate, across EC2, RDS, ElastiCache, and more.

What to do next

Quantify the saving before you migrate. Swap the instance_type (or db instance class) to the Graviton equivalent in your Terraform and re-run C3X — it reprices the aws_instance, aws_db_instance, and node-based resources against the ARM rate so the ~20% shows up as a concrete dollar figure. The quickstart runs it on your stack in minutes.