Graviton is rated up to 40% better price-performance than x86. Which workloads really save, and which should not move.
AWS describes its own silicon on its EC2 pages like this: powered by Arm-based Graviton processors, delivering up to 40% better price-performance over comparable x86 processors.
Open any "complete guide to AWS discounts" and Graviton is absent. It is not a discount — no commitment, no term, nothing to redeem. It is simply a different instance type.
The thing is, for whoever pays the bill, money saved by changing the chip and money saved by signing a one-year commitment are the same money — and the former carries no lock-in and can be reverted at will. This page is about whether it is worth doing. One ordering trap as well: commitment discounts are tied to an instance family, so changing architecture lowers your coverage — architecture first, then commitment. All five compared in cloud discount mechanisms compared.
It appears on no discount list, yet it may be the largest saving
Sort the saving mechanisms by what they cost you and its position becomes clear:
| Mechanism | Saving | Cost / lock-in |
|---|---|---|
| Spot Instances | Up to ~90% lower (floating) | Can be interrupted |
| Reserved Instances / Savings Plans | Commitment for discount | Locked 1 or 3 years, hard to undo |
| Move to Graviton | Officially up to +40% price-performance | No lock-in — switch back by changing instance type |
| Clean-up / storage tiering | Depends on waste | No cost, do it any time |
The key difference: Reserved Instances and Spot are ways of haggling over the same chip. Graviton changes the chip itself. It does not conflict with the others — you can have both the lower ARM baseline and the commitment discount, because they act on different layers.
That is also why it earns its own page: it is one of very few large savings that require no commitment and no interruption risk.
How to read "40% better price-performance"
Three qualifications before you use that number:
- It is price-performance, not price. The official claim is about the price of a unit of performance. It may come from a lower rate, from higher throughput at the same rate, or both. Your bill does not necessarily drop 40% — but the same work usually costs less.
- It is a vendor claim for a specific generation and comparison. Real results vary widely by generation (Graviton2/3/4), instance family and workload. Do not budget against 40% — benchmark first.
- It assumes your workload actually runs well on ARM. If a dependency has no ARM build and performance degrades, the saving is eaten by the slowdown.
So the correct reading is: a direction worth benchmarking, not a discount rate you can put in a budget.
The cheapest way to verify: take one stateless, easily reverted service — a web node, say — switch it to an equivalent Graviton instance, run real traffic for a day, and compare cost per request (total cost divided by requests), not the hourly rate. That is the number that means something for your business.
Four workloads that usually do save
The test is simple: does your software stack have mature, officially supported ARM builds? If yes, it probably saves; if not, leave it. By that test these four usually qualify.
| Workload | Why it fits | Watch out for |
|---|---|---|
| Web / application servers | Nginx, Node, Python, Java, Go and PHP all ship ARM builds | Confirm your runtime version has an ARM package |
| Containerised microservices | You build the images yourself in CI — make them multi-arch | CI must be able to build ARM images (or cross-compile) |
| Caches and middleware | Redis, Memcached, Kafka and similar all support ARM | Check client drivers and monitoring agents |
| Managed databases (family change) | Some managed databases offer Graviton instance families | Reservations are tied to instance family — check your commitments first |
- What they share: either you control the build, or the vendor explicitly supports ARM.
- A bonus: ARM instances are usually more energy-efficient, and at high density (many small containers) the per-compute advantage compounds.
Start with the most stateless layer. Web tiers and container workers are the easiest to verify and the easiest to revert; the lesson carries forward to harder layers. Databases can move too, but they should not be first.
Choosing instance families and comparing equivalent sizes is on how to choose EC2 instances.
Three cases to leave alone (or that cannot move)
These three cause most migration incidents. What they share: the problem is not the chip, it is the dependencies.
- Closed-source software or x86-specific instructions. Some commercial software, older agents and certain crypto/codec libraries ship x86 binaries only. On ARM they either fail to run or degrade badly. Test: run your full deployment on one ARM instance first.
- Monitoring, security and ops agents with no ARM build. The most commonly missed item — the app is fine but the APM, EDR or log shipper cannot be installed, which means giving up observability. List every agent and confirm each one before migrating.
- ML / scientific computing tied to specific accelerated libraries. Availability and optimisation of these libraries differ on ARM; and if you depend on GPUs, the bottleneck is not CPU architecture anyway, so Graviton gains little.
⛔ One rule people trip on: Windows instances are not supported on Graviton. If your workload depends on Windows, skip this section — look for savings in Reserved Instances, storage tiering and clean-up instead (see AWS discounts beyond EC2).
There is also a "can move but not worth it" category: jobs that run for a few minutes at night and cost almost nothing. Migration costs build, test and canary time; if the service's monthly bill is tiny, the trade is poor. Prioritise what is large on the bill and stable in shape.
Migration order: one layer at a time
The risk in a Graviton migration is not technical difficulty, it is changing too much at once. Four steps, each independently reversible.
- Step 1: run a comparison. Take one stateless, removable node, switch it to an equivalent ARM instance, run real traffic for a while, and record cost per request and P95 latency.
- Step 2: fix the build chain. Produce multi-arch images in CI (both x86 and ARM) and make sure the release process manages both. Do not begin bulk switching before this is done.
- Step 3: canary. Send 10–20% of traffic to ARM nodes and watch for at least one full business cycle, including peak windows.
- Step 4: scale up, then deal with commitments. Only after the ratio is stable do you expand; handle Reserved Instances and Savings Plans last, because they are tied to instance family and a change affects coverage.
| Stage | Success criteria | On failure |
|---|---|---|
| Comparison | Cost per request falls, latency does not regress | Switch back to x86 — zero cost |
| Build chain | Both architectures build and release automatically | Stay at comparison stage; do not expand |
| Canary | No anomalies across a business cycle | Shift traffic back to x86 nodes |
| Scale + commitments | Coverage and discount meet expectations | Revert the family and re-plan commitments |
Why "independently reversible" matters: the most common failure is not poor performance, it is a dependency breaking somewhere unexpected. With one-click rollback that is a manageable risk; without it, it is an incident.
Five real pitfalls and how to avoid them
In order of how often they are hit:
| Pitfall | Symptom | Avoid it by |
|---|---|---|
| Wrong-architecture image / AMI | Instance will not boot, or runs under emulation at terrible performance | Specify the ARM image explicitly; verify architecture and instance type match after boot |
| CI only builds x86 | ARM nodes cannot pull the image | Convert CI to multi-arch builds before switching nodes |
| Third-party agents lack ARM builds | Monitoring / security / log collection silently missing on some nodes | Inventory every agent and confirm each — the most commonly missed item |
| Reserved Instances do not cover the new family | Coverage drops after the move and the bill goes up | Read the instance-family lock section in how to buy AWS Reserved Instances before deciding the pace |
| Comparing rates instead of cost per request | Looks cheaper but throughput drops and total cost is flat | Compare total cost divided by business volume — the only metric that means anything |
The fourth deserves emphasis: Reserved Instances are tied to instance family. Buy a three-year commitment on an x86 family, move to Graviton, and the commitment does not follow — coverage falls and the bill can rise. So there is a clear order: settle the architecture first, then buy commitments. Doing it the other way round means dealing with stranded commitment (options in how to buy AWS Reserved Instances).
A more robust combination: if an architecture change is plausible, prefer Compute Savings Plans over Reserved Instances — they do not lock instance family or region, so a move to Graviton stays covered. The cost is usually a slightly shallower discount; what you buy is architectural freedom. Comparison on Savings Plans vs Reserved Instances.
Finally, Graviton is an official-side saving — it lowers the unit price AWS bills. Settling through a reseller lowers what you actually pay. Different layers, stackable — see AWS discounts and reseller pricing.
Common questions
Does moving to Graviton really save 40%?
Not in that sense. The 40% is AWS's claim about price-performance versus comparable x86 for a specific generation and comparison — it is the price of a unit of performance, not a 40% cut in your bill. The right approach is your own comparison: move one service, then compare total cost divided by business volume. That is the number that matters to you.
Do I have to change my code?
Usually not the business code — but you do change build and deployment: container images need ARM variants (or multi-arch), and the launch image must match the architecture. Real code changes are typically needed only in two cases: architecture-specific dependencies baked in, or closed-source libraries that ship x86 binaries only.
Can Windows move?
No. Graviton is ARM, and Windows instances are not in scope. If your workload depends on Windows, this route does not apply — look to Reserved Instances, storage tiering, clean-up and the reseller channel instead (see AWS discounts beyond EC2).
I already hold x86 Reserved Instances — can I still move?
Yes, but the commitment does not follow the architecture. RIs are tied to instance family, so moving to ARM reduces coverage and the bill may rise. Remedies (resell / modify / absorb) and the case for buying in batches are in how to buy AWS Reserved Instances. If an architecture change was always likely, Compute Savings Plans were the better buy — see Savings Plans vs Reserved Instances.
Which layer should I move first?
The stateless, removable, one-click-reversible one: web tier or container workers. Run real traffic and compare cost per request and P95 latency. Databases can move too, but should not be first — reverting them costs far more.
Does it conflict with Spot or Reserved Instances?
No — different layers. Graviton changes which chip you use (the rate baseline); Reserved Instances and Savings Plans discount on top of that baseline; Spot trades interruptibility for a lower price still. All three can apply at once: ARM instances with a reservation, and the elastic portion on ARM Spot. See AWS discounts and reseller pricing.