Graviton is AWS designed Arm based silicon, and AWS prices Graviton instances at about 20 percent below the equivalent x86 instance family while claiming up to 40 percent better price performance on suitable workloads. The 20 percent rate cut is contractual and applies the moment you switch; the larger price performance number is workload dependent and should be treated as indicative until you benchmark. For a fleet of any size that runs continuously, the standing saving usually dwarfs the one time engineering cost of porting.
This article costs the migration the way a buyer should: separate the guaranteed rate cut from the speculative performance gain, put a real number on the porting effort, and give you a threshold for when to bother. It belongs in the AWS compute cluster alongside EC2 rightsizing that engineers accept and spot instances and where they fit, because the three levers compound.
Where does the Graviton saving actually come from?
Two distinct effects get blurred together, and conflating them leads buyers to either oversell the migration or dismiss it. Pull them apart.
The first is a flat price advantage. AWS lists Graviton instances at roughly 20 percent lower on demand pricing than the comparable x86 instance of the same size. This is a rate cut for like for like capacity. It needs no tuning and shows up on the very first bill after you switch. It is the floor of the saving and the number you should plan against.
The second is a price performance gain. AWS claims up to 40 percent better price performance for Graviton on workloads that parallelise well across the Arm cores, such as web tiers, microservices, caching layers, and many data processing jobs. Where that holds, you can run the same load on fewer or smaller instances, and the saving exceeds 20 percent. But it is a property of your code, not the price list, so label it indicative and prove it with a benchmark before you bank it.
Buyer takeaway: underwrite the migration on the 20 percent rate cut alone. Treat any price performance upside as a bonus you verify per workload, never as the headline justification.
What does the migration cost?
The honest answer depends on your runtime. The work falls into three buckets, cheapest to most expensive.
Interpreted and managed runtimes
Workloads on modern Java, Python, Node, Go, and the like usually run on Arm with little more than a multi architecture container build and a retest pass. The instruction set is abstracted away by the runtime. Here the cost is mostly pipeline plumbing and validation, often a few engineer days per service, and the porting risk is low.
Compiled languages and native dependencies
Anything compiled to x86, or pulling native libraries, needs recompilation for Arm64 and a check that every dependency has an Arm build. Most mainstream libraries now ship Arm wheels and packages, but a single laggard dependency can stall a service. Budget time to find and replace or rebuild those, and test performance rather than assuming parity.
Licensed and third party software
Some commercial software is not offered for Arm, or is licensed per architecture. This is where migrations genuinely stop, and it is a hard constraint rather than an engineering cost. Inventory your licensed software for Arm support before you commit a timeline.
Across most estates we see, the dominant cost is retesting and the build pipeline, not rewriting. The mistake buyers make is pricing the whole fleet as if every service were the hard case. Segment first.
When does Graviton pay? A worked example
A Fortune 500 retailer ran a stateless web and API tier on x86 at an indicative 1.2 million dollars a year of on demand equivalent compute. The services were containerised on a managed runtime, so porting was a multi architecture build plus a load test, costed at roughly 30 engineer days across the platform team. The flat rate cut alone took the annual run rate down about 20 percent, near 240,000 dollars saved a year. Benchmarks on the web tier showed a further headroom gain, letting them shrink the fleet, but they underwrote the business case on the rate cut only. Payback on the one time engineering cost was under one month. Figures are verified against billing data and anonymised.
The shape generalises. A large, continuously running, easily ported fleet pays back almost immediately. A small, intermittent, or hard to port workload may never justify the effort. The deciding variables are fleet size, run hours, and porting difficulty, in that order.
Does Graviton interfere with my Savings Plans?
No, and this matters because buyers often fear a migration will strand a commitment. Compute Savings Plans apply across instance families and architectures, so the discounted Graviton rate sits underneath the Savings Plan rather than competing with it. The two stack: you keep the commitment discount and add the Graviton rate cut on top.
The sequencing point is simple. Migrate to Graviton first where it is easy, then size your commitment against the new, lower baseline so you do not over commit to capacity you are about to make cheaper. We cover how to get that order right in spot instances and where they fit and in the commitment sizing material linked from the pillar guide.
A short checklist before you migrate
Run this before committing a timeline, in order:
- Segment the fleet by runtime: managed, compiled, and licensed. Migrate the easy segment first.
- Inventory dependencies and licences for Arm64 support. One unsupported component can block a service.
- Benchmark a representative service to confirm the price performance gain before you assume it.
- Stand up a multi architecture build so the same image ships for both architectures during the transition.
- Resize commitments against the post migration baseline, not the old one.
Frequently asked questions
How much does Graviton actually save?
What does it cost to migrate to Graviton?
Does Graviton work with Savings Plans?
Where Graviton fits in a full AWS program
Graviton is one of the standing wins we sequence into an AWS cost program alongside rightsizing, gp3 storage migration, and commitment coverage. None of them works in isolation; the order and the interaction is the job. We help enterprises cut cloud spend across AWS, Azure, GCP, and OCI as an independent buyer side advisory with zero provider commissions, and our guarantee is simple: we reduce your cloud spend or we reimburse our service fee.
Want the monthly buyer side brief on moves like this? Subscribe to The Cloud Spend Navigator.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.