Graviton is the rare cost lever that does not require an architecture debate. You are not consolidating services, renegotiating a contract or arguing about multi-region. You are changing a processor architecture, and if your image builds, the bill drops.
The headline is roughly 20 percent cheaper per hour for the same instance size, and often better than that per unit of work, because the newer generations also perform better on most web and JVM workloads. But the migration has a shape, and teams that skip the order below spend a month on it instead of a week.
The order that works
Start with the managed services. RDS, ElastiCache, OpenSearch and MemoryDB run Graviton with a modify-instance-class and a maintenance window. There is no build to change, because you are not running the binary. This is free money and it should be done before anyone touches a Dockerfile.
Then anything interpreted. Python, Node, Ruby and PHP services usually run on ARM with no source changes at all. What breaks is not your code, it is a native dependency wheel that has no aarch64 build. pip install will silently fall back to compiling from source, your image build goes from two minutes to fourteen, and someone blames Graviton.
Then the JVM and Go. Both are excellent on ARM. Go needs GOARCH=arm64 and nothing else. The JVM needs a recent version; Java 17 and up are well tuned for Graviton, Java 8 is not.
Last, anything with a vendor agent or a compiled C extension you do not control. APM agents, security agents, licensed binaries. Check the vendor's ARM support before you plan the migration, not during it.
The four things that bite
Multi-arch images are not optional. Build with docker buildx build --platform linux/amd64,linux/arm64 and push a manifest list. Otherwise the day you need to roll back to x86 capacity — during a spot shortage, say — you will not have an image for it. Building ARM images on x86 runners through QEMU emulation works but is slow; native ARM runners in CI cut build times by more than half.
Mixed node groups need taints or they will lie to you. In EKS, an autoscaling group with both architectures and a single-arch image produces pods stuck in CrashLoopBackOff with an exec format error. Either use kubernetes.io/arch node selectors on every workload or keep architectures in separate node groups during the transition. We prefer separate groups: it makes the rollback a single scaling operation.
Lambda is the easiest win and the most forgotten. Switching a function's architecture to arm64 is a one-line change in Terraform, gives you around 20 percent off the per-millisecond price, and usually runs faster. Anything with a bundled native layer needs the layer rebuilt; everything else is instant.
Benchmark per unit of work, not per hour. The instance is cheaper, but what you care about is cost per thousand requests. Run a real load profile against both architectures with the same autoscaling policy and compare the p99 and the instance count. We have seen cases where the ARM instance was 20 percent cheaper and needed 15 percent fewer instances, and cases where a badly tuned JVM ate the whole gain.
What to expect on the bill
On a typical estate where compute is 40 to 60 percent of the invoice, moving the compatible two thirds of it to Graviton lands between 8 and 15 percent off the total. It stacks with Savings Plans, which is the point of sequencing it before you commit — buy a Compute Savings Plan against the post-migration baseline, not the current one. That is step five of the five layers of the AWS bill, and doing it in the wrong order locks in the higher price for a year.
Plan one week per major workload family, including a load test. Most of that week is CI work.
What to do this week
List your RDS and ElastiCache instances and check which classes have a Graviton equivalent. That change is a maintenance window, needs no code, and is usually the first five percent. While the window is scheduled, flip your Lambda functions to arm64 in staging and watch the duration metric.