Paying x86 prices for compute you could run cheaper?

Your AWS compute bill is going up every quarter, and the uncomfortable part is that a large chunk of it is still running on x86 instances that have a cheaper ARM twin sitting right next to them in the same console. You are paying a premium for an architecture choice nobody revisited.

This is not another generic cost teardown telling you to right-size and buy commitments. This is a specific lever: moving the workloads you already run onto AWS Graviton, the ARM processors AWS builds in-house. Done carefully, an AWS Graviton migration cuts compute cost 20-40% on the slices you move, with no drop in performance your users would feel. Done carelessly, you ship an x86 binary to an ARM host and your service refuses to start. The difference is method, and that is what this post is about.

What Graviton is and why it costs less per vCPU

Graviton is AWS's own line of ARM-based processors - Graviton2, Graviton3 and Graviton4 across the current generation. ARM is a different instruction set from the x86 chips Intel and AMD make, and that difference is the whole story. Because AWS designs Graviton itself, it does not pay a chip vendor's margin, and the ARM design is built for the power and density profile of a data centre rather than a desktop. The result lands on your bill in two ways:

• The instances are cheaper per vCPU - typically around 20% lower list price than the equivalent x86 instance in the same family and region.
• For many workloads they also do more work per vCPU, which is why AWS quotes up to 40% better price-performance. That second number is the one that matters, because it captures speed as well as price.

The practical signal is the instance name. An ARM Graviton instance has a g in its type - m7g, c7g, r7g, m6g - where the x86 version is m7i or m6a. Same families, same console, same APIs. You are not learning a new platform; you are swapping the chip underneath.

Which workloads are safe to move first

Not everything should move on day one, but a surprising amount can. The safe-and-easy tier, the place every AWS Graviton migration should start, looks like this:

• Web and app tiers. Stateless services behind a load balancer - Node, Python, Java, Go, Ruby, PHP. These are the classic quick win. We have seen teams take a 20% compute cut on the web tier in a single weekend because the application code never had to change.
• Containers. ECS and EKS workloads run on Graviton once you provide an arm64 image. Fargate offers Graviton too, so even serverless containers qualify.
• Managed services. This is the lowest-risk saving of all. RDS, Aurora, ElastiCache and OpenSearch all offer Graviton instance classes. You change the instance type, AWS runs your engine on ARM, and your application never knows. No build, no binary, no risk to your code.
• Lambda arm64. Flip the function architecture to arm64 and most interpreted runtimes just work, at a lower price per millisecond.

If you want the deeper trade-off on where containers should actually run, our breakdown of when Fargate beats EC2 on ECS pairs well with this, because the cheapest answer is often Graviton plus the right launch type together.

The compatibility check: where the real risk lives

Here is the honest part. The instance swap is trivial. The risk is your dependencies. ARM is a different instruction set, so anything compiled down to x86 machine code has to be rebuilt or replaced. The rule of thumb:

• Interpreted languages are easy. Python, Node, Ruby, PHP and the JVM are largely architecture-neutral. Your source runs the same on ARM.
• Native and compiled dependencies are the watch-out. A Python package with a C extension, a Node module with a native binding, an image-processing or crypto library compiled for x86 - these need an arm64 build. Most popular ones now ship one, but you confirm it, you do not hope.
• x86-only binaries are the hard stop. A vendor agent, a proprietary tool, or a sidecar that only ships an x86 build will not run. If something in your stack has no arm64 version, that workload stays on x86 until the vendor catches up.

The check itself is fast: inventory your runtime, list every native dependency and third-party binary, and confirm an arm64 build exists for each. Ninety percent of stacks pass. The ten percent that do not, you find in an afternoon rather than in a production incident.

Multi-arch container builds with docker buildx

For container teams, the enabler is the multi-arch image. You do not maintain two pipelines; you build one image manifest that holds both an amd64 and an arm64 variant, and the runtime pulls the right one. The tool is docker buildx:

• Set up a buildx builder, then build with --platform linux/amd64,linux/arm64 and push. That single command produces a manifest list covering both architectures.
• Your ECS task or Kubernetes node pulls the variant that matches its CPU automatically. No tag juggling, no separate registry path.
• Build arm64 natively where you can - on a Graviton CI runner - because cross-building under emulation is slower. A small Graviton build host pays for itself in pipeline time.

Once your images are multi-arch, mixing Graviton and x86 nodes in the same cluster becomes routine, which is exactly what you want during a phased move.

The benchmark-then-cut method (the part that protects you)

This is the discipline that separates a clean migration from a cost-cut that quietly hurt your latency. Do not migrate on the promise of a cheaper price. Migrate on measured price-performance. The sequence:

1. Pick one slice. A single stateless service, or one node group, or one Lambda function. Small enough to move and judge in a day.
2. Build for arm64. Rebuild the image or flip the function architecture, and run your compatibility check on its dependencies first.
3. Run both in parallel. Put a portion of real traffic on Graviton beside the x86 version. Same load, same conditions.
4. Compare price-performance, not just price. Measure p50 and p99 latency, throughput, and error rate against the x86 baseline, then divide by cost. The right answer is cheaper AND at least as fast. If Graviton is cheaper but slower under your real load, you have not won - you have moved a problem.
5. Cut the slice over. Once the numbers hold, shift the remaining traffic. Then move to the next slice and repeat.

This is the same evidence-first habit behind any sound AWS cost work. Our guides on EC2 right-sizing without overpaying and the Lambda vs ECS performance comparison lean on the same idea: change one thing, measure it against a baseline, keep what the data supports.

Rollback safety: keep the exit one config change away

Because you moved slice by slice and kept your images multi-arch, rollback is not a project - it is a setting. If a Graviton slice misbehaves, you point the service back at the x86 task definition, or flip the Lambda architecture back to x86, or scale the x86 node group up and the Graviton one down. Traffic returns to the known-good path in minutes. That safety net is the reason the phased method is worth the small extra effort over a big-bang cutover - you are never more than one change from where you started.

The honest trade-off: when NOT to move

Graviton is not a universal yes. Leave a workload on x86 when:

• A core dependency or vendor agent ships x86 only, with no arm64 build on the roadmap.
• The workload leans on x86-specific hardware acceleration or instruction sets your benchmark shows ARM does not match for that exact job.
• The slice is tiny and rarely runs - the engineering time to move it costs more than the saving for a year.
• You are mid-incident or in a change freeze. Migrate from stability, not into a fire.

A 20-40% saving on 70% of your fleet beats chasing the last awkward 30% into diminishing returns. Move what is easy and proven, document why the rest stays, and revisit it next quarter.

Where Graviton stacks with Savings Plans

This is the saving most teams leave on the table. Graviton and a Compute Savings Plan are not either-or - they multiply. The instance swap gives you the lower per-vCPU rate. The Savings Plan then discounts the committed spend on that already-cheaper Graviton usage. Two discounts on the same workload.

The order matters. Migrate first, let the Graviton fleet settle so your baseline reflects the new, lower steady-state usage, then buy the commitment against that figure. If you commit before you migrate, you lock in spend against x86 instances you are about to retire, and you blunt the saving. If you are weighing the commitment side of this, our explainer on Reserved Instances versus Savings Plans covers which commitment fits which fleet. Sequenced right, the combined effect on the migrated slices is well past what either lever delivers alone.

If you would rather hand the whole thing over, our AWS consulting services and managed cloud services teams run migrations like this end to end - compatibility check, multi-arch builds, phased cutover and the Savings Plan timing. For shorter engagements you can also hire an AWS developer to pair with your team on the build side, or use our cloud consulting services to size the opportunity before you commit a sprint to it.

FAQ

Will moving to Graviton break my application?

For interpreted languages - Python, Node, Ruby, PHP, the JVM - usually not, because the code is architecture-neutral. The break risk sits in native compiled dependencies and x86-only binaries that have no arm64 build. That is exactly what the compatibility check catches before you move, so you find it on a test slice, not in production.

How much can an AWS Graviton migration actually save?

Around 20% on per-vCPU list price for the slices you move, and AWS quotes up to 40% better price-performance once you account for the extra work many Graviton instances do per vCPU. Stack a Savings Plan on top of the migrated fleet and the combined saving on those workloads goes further still.

Do managed services like RDS support Graviton?

Yes. RDS, Aurora, ElastiCache and OpenSearch all offer Graviton instance classes. You change the instance type and AWS runs your engine on ARM with no code change on your side, which makes managed services the lowest-risk place to start.

What if a Graviton slice underperforms after we cut over?

Rollback is one config change. Because you keep multi-arch images and move slice by slice, you point the service back at the x86 task definition or flip the Lambda architecture back, and traffic returns to the known-good path in minutes. You are never more than one change from where you started.

The takeaway is simple: a rising AWS compute bill does not always mean you are using too much - often it means you are paying x86 prices for work that runs just as well, and cheaper, on ARM. Run the compatibility check, move one slice, benchmark price-performance rather than price alone, keep rollback a single config change away, and time your Savings Plan after the move. Do it in that order and a 20-40% compute cut on a big share of your fleet is a careful afternoon's work, not a leap of faith.