Migrating to ARM for cost: a staged playbook with real numbers

ARM instances are the rare cost lever that is a pure win when it applies and a waste of a quarter when it does not. The difference is entirely in what your workload is made of. A Go service moves in an afternoon. A Java service moves in a week. A service that depends on an x86 only vendor agent may not move at all. The playbook below front loads that determination so you find out in stage one rather than stage three.

The price gap

The sticker gap is 10 to 20 percent, but the more useful number is price performance. Recent ARM generations often deliver comparable or better throughput per vCPU for web serving, caching, and many JVM workloads, which means the same traffic runs on fewer or smaller instances. Teams commonly report effective savings of 20 to 40 percent once the fleet is resized to the new performance profile, which is why stage 3 below measures throughput per dollar rather than assuming the sticker gap. Context in Graviton cost savings explained.

Stage 1: inventory by runtime, not by service

Sort every workload into three buckets. Clean ports: Go, Rust, Python, Node.js, Java, .NET Core, PHP, Ruby, and anything running in an interpreted or JIT runtime with ARM builds available. These typically need only a rebuild. Conditional ports: anything with native extensions or compiled dependencies, where the question is whether every transitive dependency publishes an ARM64 wheel or binary. Blocked: workloads with x86 only licensed software, proprietary monitoring or security agents without ARM builds, or vendor support terms that do not cover ARM.

Spend real time on the blocked bucket first. Discovering in week six that your security agent has no ARM build is the failure mode that kills these projects. Check every sidecar, agent, and init container, not just the application.

Stage 2: multi architecture images

Build multi architecture container images so a single image tag resolves to the right architecture at pull time. Modern build tooling supports this directly, and cross compiling in CI is usually faster than emulated builds, which can be five to ten times slower and will make your pipeline unpleasant. Start with the base image: if your base is not available for ARM64 you have found a blocker early, which is the point.

For serverless functions the equivalent step is simply selecting the ARM architecture and confirming any layers or bundled binaries have ARM builds. Function pricing on ARM is about 20 percent lower per GB-second, and since functions are stateless and short lived the migration risk is unusually low, which makes them a good first target. See Lambda ARM savings.

Stage 3: measure side by side, do not assume

Run ARM and x86 nodes in the same load balancer target group or the same Kubernetes cluster with mixed node pools, send identical traffic, and compare three things: p99 latency, requests per second per instance, and cost per million requests. That third metric is the one that decides the migration, because a workload that is 5 percent slower on ARM but 20 percent cheaper is still a clear win, while one that is 30 percent slower is not.

Run this for at least a week to catch behaviour under daily traffic variation. Watch specifically for workloads with heavy x86 specific optimisation, certain compression, cryptography, and vector math libraries have hand tuned x86 paths that may fall back to generic implementations on ARM.

Stage 4: shift progressively

Move traffic in increments: 10 percent, then 50, then 100, with a defined rollback at each step. Mixed architecture node pools make this straightforward on Kubernetes provided your pods do not carry node selectors that pin them to x86. Non-production goes first, then internal services, then customer facing.

One financial detail to sequence correctly: if you hold instance family specific commitments on x86, moving to ARM strands that coverage. Compute Savings Plans apply across families and architectures, so they are unaffected, but family specific reserved instances are not. Check your commitment shape before you start, or time the migration to a renewal boundary. The distinction is in reserved instances versus savings plans.

Expected outcome

A realistic result on a fleet that is 70 percent portable is a 12 to 25 percent reduction in compute spend, achieved over one quarter. On a $100,000 a month compute bill that is $12,000 to $25,000 a month, recurring, for engineering effort that is mostly build system work rather than application rewriting. Price the ARM variants of your Terraform resources against the resource catalog before the migration so the business case is built on current rates rather than estimates.

FAQ

What to do next

Build the ARM business case on real rates. C3X prices instance alternatives from Terraform against a live resource catalog. Start with the quickstart.