Graviton vs x86: Choosing an EC2 Instance Architecture
After picking an EC2 instance family, one axis remains: within the same m line, x86 (m7i, m8i) and ARM (m8g, m9g) split. The conclusion up front: for any workload free to choose its architecture, Graviton is the default. Hourly rates run 10–15% lower, the performance gap widens with each generation, and in price-performance terms the difference reaches tens of percent. What keeps x86 around is not performance but compatibility: commercial binaries, specific instruction-set dependencies, Windows licensing. Family selection itself is covered in the EC2 instance family comparison, and the hands-on migration process in the Graviton migration checklist; this post focuses on the decision. Prices are for us-east-1.
Side-by-side comparison #
| Aspect | Graviton (ARM) | x86 (Intel and AMD) |
|---|---|---|
| Hourly rate (m-family large) | m8g ~$0.090 | m7i ~$0.101 |
| Price-performance | Tens of percent ahead of comparable x86 (workload-dependent) | Baseline |
| Software compatibility | Most of the open-source ecosystem | Effectively everything |
| Containers | arm64 images and multi-arch builds required | Existing images as-is |
| Commercial software | Vendor support needs checking | Mostly supported |
| Windows | Not supported | Supported |
| Latest generation | Graviton5 (m9g, GA 2026-06) | Generations refresh in parallel |
Rates and performance: the real size of the gap #
On hourly rates, m8g.large (Graviton4) runs about $0.090 against m7i.large (Intel) at about $0.101, roughly 11% cheaper. The real distance opens up in performance. AWS states Graviton4 instances deliver price-performance advantages of tens of percent over comparable x86, and benchmarks of web and API serving typically show higher throughput at the same vCPU count. Part of the reason is what a vCPU is: on x86 it is one hyperthread, on Graviton one physical core.
June 2026 brought Graviton5-based m9g and m9gd to GA. They run about 9% more per hour than m8g with up to 25% more performance, which nets out to roughly another 15% in price-performance. Availability is limited early on (starting with Virginia, Ohio, Oregon, and Frankfurt), so use m9g where the region supports it; elsewhere, m8g is the current default. As with GPU generations, this is time-sensitive information — confirm the latest generation and region support at adoption time.
As a savings lever, the distinctive property is that the rate cut comes without a commitment. RIs and Savings Plans buy their discounts with 1–3 year lock-ins; a Graviton migration produces a similar-sized cut with no lock-in, and commitments stack on top of it. The commitment system is covered in RI vs Savings Plans.
Where to start: managed services first #
Migration difficulty differs completely by layer.
Managed services are the easy win. For RDS, Aurora, ElastiCache, and OpenSearch, the change is an instance class swap from db.m7i to db.m8g. Your code does not run on those machines, so compatibility risk is structurally absent; all you need is a restart window. The place to start collecting Graviton savings is here, not EC2.
Interpreted and JVM stacks are the next easiest. Python, Node.js, Ruby, PHP, Java, and Go have mature arm64 runtimes, and most moves end at a rebuild or an image swap. What snags is not the language but native dependencies: packages with C extensions, internally built binaries, and old base images need checking for arm64 availability.
Containers gate on multi-arch builds. Once CI builds amd64 and arm64 images together under one manifest, node groups can migrate gradually. The step-by-step process and verification list live in the migration checklist.
Where x86 remains is a clear list: commercial software without arm64 builds, numeric workloads tuned to x86-specific instructions (the AVX families), Windows, and small legacy systems whose migration validation cost cannot be justified. If a workload is on x86 without appearing on that list, it is worth asking whether anything but inertia keeps it there.
Decision order #
- Start new workloads on Graviton: building arm64 from day one makes the migration cost zero. m9g where the region allows, m8g otherwise.
- Switch managed services first: instance class changes on RDS and ElastiCache cut rates with no code involved. It is the most certain first saving.
- For your own workloads, scan dependencies and run a pilot: confirm no arm64-unsupported dependency exists, then compare measured performance and cost on a canary or separate node group.
- Design for a mixed period: multi-arch images and architecture-agnostic pipelines let services migrate one at a time. Nothing forces a single cutover.
- Keep the x86 remainder list explicit: recording why each workload stays (commercial binary, instruction set, Windows) makes revisiting easy when vendor support arrives.
Summary #
- Workloads free to choose default to Graviton: 10–15% lower hourly rates, with a larger price-performance gap behind them.
- The current default is m8g (Graviton4); where regions allow, m9g (Graviton5, GA June 2026) adds roughly another 15% price-performance.
- Start with managed services. RDS and ElastiCache class changes lock in savings with zero compatibility risk.
- The gates for your own workloads are native dependencies and multi-arch builds. Follow the migration checklist and confirm with pilot measurements.
- Graviton savings come without lock-in and stack with RIs and SPs. x86 stays only where a compatibility reason exists.