ARM against x86: what Graviton, Ampere and Axion save

A FinOps guide by OptimNow · list prices from the live OptimToken compute catalogue

Every cloud sells an ARM line, and every cloud sells it on price. AWS has Graviton, Azure and Google both resell Ampere, Google has added its own Axion, and Alibaba builds Yitian. The number attached to all of them is roughly 20%. That number is checkable, so this guide checks it: same cloud, same vCPU count, same memory, on-demand Linux list price, and nothing else changed. The answer depends almost entirely on one thing nobody states, which is what you are comparing the ARM instance to.

How the gap is measured here

An instance pair qualifies when both rows come from the same provider, carry the same vCPU count and the same memory, and sit in the same burstable class. A burstable instance buys CPU credits rather than a dedicated core, so t4g is compared to t3 and never to c6i. Accelerated shapes are excluded: when a GPU sets the hourly rate, matching on cores compares the wrong component. The catalogue today yields 77 qualifying pairs across 33 ARM instance sizes and 4 clouds (AWS, Azure, GCP and Alibaba).

Both sides of every pair come off the same rate card in the same region, so this is a ratio between two prices a customer sees on one screen. Regional multipliers apply to both rows and cancel. What the ratio cannot tell you is covered further down, and it is the part that decides the migration.

Against Intel, the clouds agree

Measured against Intel instances of the same size, the median discount is 19.8% across 53 pairs. The 4 clouds land within 1.5% of each other while selling 6 different ARM chip generations between them, which reads as a pricing convention rather than a measured cost of silicon.

Against AMD, it halves

Same ARM instances, same method, different baseline: measured against AMD rows of the same size, the median gap is 10.6% across 24 pairs. That is under half the figure against Intel. The ARM discount, as published, is largely a discount against Intel, and AMD had already taken most of it. A business case built on the 20% headline while the estate runs on AMD is sized against a baseline it does not have.

This is where the comparison matters for a FinOps team. The choice presented internally is usually "ARM or x86", and the rate card does not work that way: it prices three processors, not two. OptimNow's practice library makes the same point from the other direction, recommending that representative workloads be benchmarked on Intel, AMD and ARM before a family is picked, rather than on the two most familiar.

Worked examples

At 730 hours a month and a fleet of 50 instances, held for a year:

The two right-hand columns are the same migration, costed against two different starting points. Neither is wrong. Which one applies is a question about the current estate, answerable from a tag or an instance-type inventory, and worth answering before the saving is put in a business case.

The newest ARM chips carry the smallest discount

Grouping the same pairs by silicon rather than by cloud shows the direction of travel. Each step below stays inside one cloud's own ARM line, so it compares two generations rather than two rate cards, and all of it is measured against Intel to keep the baseline fixed. Graviton2 to Graviton3 moves the median from 20.0% to 15.0%; Ampere Altra to Axion moves the median from 20.7% to 7.5%. The discount shrinks as the silicon gets newer, which is the opposite of what a reader expecting a widening ARM advantage would predict.

The clearest case sits on GCP. c4a-standard-2 (2 vCPU / 8 GB) lists at $0.0898 an hour against $0.0845 for n2d-standard-2, the AMD row of the same size. The ARM instance costs 6.3% more, not less, and the same holds at the other matched size. A team that moved to ARM on GCP expecting the headline, from an AMD starting point, moved to a more expensive instance. The catalogue carries the price and not the reason: newer cores priced on what they deliver, rather than discounted for the architecture, would produce this pattern, and that reading is a hypothesis rather than a measured result.

What a rate card cannot tell you

Everything above measures price per vCPU-hour. It says nothing about how much work a vCPU does, and the two are not the same question. A Graviton3 core and a Graviton2 core both count as one vCPU on the bill while doing different amounts of work per hour, which is the most plausible explanation for the narrowing above: the newer generations charge more per hour because they deliver more per hour. OptimToken publishes prices, not benchmarks, so treat the direction as an observation with a stated limit rather than a measured price-performance result.

The practical consequence is that a same-size swap is the wrong migration in both directions. Moving from Ampere Altra to Axion at an unchanged size raises the bill, because the newer generation is the dearer row of the two. Sizing the target fleet on observed utilisation, rather than mapping it one-for-one, is where the rest of the saving sits.

What the migration costs

• Multi-architecture builds. Container images, Lambda packages and any compiled dependency need an arm64 target. Interpreted runtimes and bytecode move with a configuration change; anything linking x86-specific binaries does not.
• Commitments strand. Reserved instances scoped to an instance family, and resource-based committed use discounts, do not follow a workload from Intel to ARM. A term signed on the old family is a real cost of the move, and it is usually the reason a technically ready migration waits. Where the architecture is still in flux, a spend-based commitment trades a few points of discount for the freedom to move.
• Managed services move separately. The same processor choice exists on RDS, ElastiCache and OpenSearch, on their own schedules and their own rate cards. The EC2 estate is not the whole of it.
• Not every cloud offers the choice. DigitalOcean and OVH list no ARM instance in this catalogue. OCI lists ARM shapes carrying different memory per core than the x86 shapes beside them, so no like-for-like pair clears the rule above and no gap can honestly be quoted.

Where this leaves a shortlist

For a team running general-purpose or compute-optimised Linux workloads with no x86-specific dependencies, ARM is the cheaper row at every matched size on 3 of the 4 clouds measured here (AWS, Azure and Alibaba), and the saving is real money at fleet scale. Two corrections to the usual framing: measure the gap against the processor you run today, and check which ARM generation you are moving to, because the newest is not the cheapest and on GCP it is the more expensive option at some sizes. Both checks take an afternoon against an instance inventory, and they move the size of the business case by roughly a factor of 2.

The full rate card, including the spot and commitment columns this guide leaves aside, sits on the cloud compute pricing table.

Figures on this page are recomputed from the compute catalogue on every build, at on-demand Linux list prices for the US East region group.

The FinOps reasoning behind this guide comes from OptimNow's open-source practice library: github.com/OptimNow/cloud-finops-skills. If you want your own estate sized against the processor families you are already paying for, OptimNow runs that review.

Data snapshot: 2026-09-20 · Compare all models · Cloud compute pricing · All guides