Graviton vs. x86: what the discount is worth

Published August 30, 2026

Two EC2 instances with the same vCPU count, the same memory, and the same network bandwidth can differ in hourly price by 15 to 20 percent. The cheaper one runs Graviton, AWS’s own Arm processor. The expensive one runs an Intel or AMD x86 chip.

That discount is real, but it isn’t free. Whether it’s worth taking depends on what your software can run on, how AWS counts cores, and what you’re actually licensing. This guide walks through all three: what the architectures are, what the same size costs, what the same dollar buys, and the differences that never show up on the pricing page. For the history of the Graviton chips themselves, see Graviton versions: from experiment to default.

x86 and Arm in sixty seconds

A CPU instruction set is the vocabulary a processor understands. Software has to be compiled for the instruction set it will run on, which is why the distinction matters to you and not just to chip designers.

On EC2 you’re choosing between two of them:

• x86_64, sold by Intel (m7i, c7i) and AMD (m7a, c7a). This is what most server software has been built for since the 1990s. If you have a binary or a vendor image and you don’t know what architecture it is, it’s almost certainly this.
• arm64, sold on AWS as Graviton (m7g, c7g, t4g). Arm licenses its designs to chipmakers, and AWS builds its own from Arm cores. Your phone runs an Arm chip. So does the Apple Silicon laptop that’s probably within reach.

Everything else about an EC2 instance is the same either way: the EBS volumes, the VPC networking, the region layout, the console. Linux doesn’t care much either. uname -m prints x86_64 or aarch64 and most mainstream distros publish builds for both.

The catch is anywhere your software isn’t recompiled per architecture. A container image built for x86 won’t start on Arm. A Python package with a compiled C extension ships prebuilt wheels per architecture. This is where Graviton migrations succeed or stall, and we’ll come back to it.

vCPUs are not cores

Here’s the difference most people miss, and it changes how you read every spec sheet.

x86 chips run two hardware threads per physical core. Intel calls this hyper-threading; the generic term is SMT. The two threads share the core’s execution resources, so an x86 vCPU is roughly half a core, not a whole one. Graviton does it differently: through the generations we track, each Graviton vCPU maps to one full physical core.

Compare the same-size pair in the m7 generation:

Same advertised size, 16 GiB of memory each, completely different machines. The Graviton instance has four real cores running at a lower clock. The Intel instance has two cores running faster, each split into two vCPUs.

Three practical consequences:

Per-vCPU throughput skews toward Graviton. In our benchmark data, m7g.xlarge posts about 25,800 CoreMark per vCPU against m7i’s 22,300, despite the slower clock. A whole core beats half of a faster core.

Whole-instance throughput is closer than it looks. Add up all four vCPUs and m7g does about 16% more total work than m7i. SMT helps x86 more than the “2 vCPUs per core” line suggests, but it never doubles anything; two threads fighting over one core typically buy 15 to 30% over a single thread. If your workload keeps every vCPU busy with the same kind of work, expect Graviton to pull ahead modestly at equal size. If your workload is a single-threaded process that needs raw clock speed, the 3.2 GHz Intel core is the better fit and no amount of Graviton cores fixes that.

Licensing can cut either way. Software licensed per vCPU costs the same on both. Software licensed per physical core costs more on Graviton, because that 4-vCPU instance is four cores instead of two. Software licensed flat per instance gets cheaper on Graviton, since the instance itself costs less. Check how your vendor meters before you move; the license line item can erase the discount.

What the same size costs

Start with the m7 generation across sizes (us-east-1, Linux, on-demand):

The discount is flat within a family: AWS prices the Graviton variant at a fixed ratio, so the percentage doesn’t move with size. Pick a size for your workload, then compare prices; never assume the ratio transfers across families.

Across families and generations, the discount varies:

Two patterns worth knowing. The discount narrows in newer generations, roughly 19% in the Graviton3 era and 15% in the Graviton4 era. And memory-optimized pairs discount at the same rate as compute pairs, so a workload’s shape doesn’t change the percentage much.

The gap also moves a point or two by region. Check your region’s numbers on the instance detail pages rather than trusting us-east-1.

What the same dollar buys

Price is only half the equation. Divide each instance’s total benchmark score by its hourly price and you get estimated work per dollar:

Every Graviton bar is ahead, and the margins are bigger than the price discount suggests: 26 to 66% more work per dollar. The discount alone would predict 15 to 19%. The rest comes from Graviton getting more done per vCPU, as explained in the cores-and-threads section above.

The caveat that matters: these are synthetic benchmark scores. CoreMark measures a CPU in a loop, not your Rails app or your Postgres primary. Workloads that lean on single-thread speed, proprietary x86 instructions, or unoptimized Arm code paths can land at or below parity. Treat the chart as the shape of the answer, then measure your own workload. Graviton migrations that succeed usually start with a cheap experiment: a t4g.medium at $0.034/hour running your stack in staging tells you more than any table.

What the price tag doesn’t show

Four differences never appear in the pricing table.

Windows doesn’t run on Graviton. Our pricing data has Windows rows for every x86 size and zero for the Graviton families. Windows Server on Arm isn’t offered on EC2. Any Windows workload stays on x86, full stop.

Vendor software has to support arm64. Most popular open source and container images publish multi-arch builds now. Commercial software is patchier: some vendors ship Arm builds at the same price (effective discount, since the instance costs less), some charge extra, some don’t support it at all. Oracle, SAP, and a long tail of licensed appliances are the usual blockers. Before planning a migration, list every non-open-source component and check its Arm status explicitly.

Compiled dependencies follow the same rule. Python packages with C extensions, Node native modules, Go programs that vendor assembly, anything you build from source: all of it needs Arm builds. If you’re containerized with multi-arch images and package-manager-installed dependencies, this is mostly a non-issue. If you build vendor blobs or ship compiled artifacts, budget time for it.

Clock speed still favors x86. m7g runs 2.5 GHz against m7i’s 3.2. Latency-sensitive paths and per-thread-bound workloads (some game servers, some financial models, legacy single-threaded monsters) can prefer the faster Intel core even though Graviton wins the aggregate benchmarks. Newer Gravitons keep closing this gap: Graviton4 runs 2.7 GHz and Graviton5 hits 3.3, but the current-generation x86 parts run faster still.

One difference in the other direction: from Graviton3 on, the Arm parts carry SVE vector extensions and competitive memory bandwidth, so ML inference and media processing tend to do well. The c7 pair above shows the smallest per-dollar margin (26%) precisely because compute-bound x86 is at its best there.

Checking the gap for your actual size

The percentages above are patterns, not promises. Your workflow when deciding:

1. Look up your current instance in the instance explorer, note the vCPU and memory.
2. Find the Graviton family with the same ratios. For m7i, that’s m7g; for a c5, it’s c6g or c7g; for t3, it’s t4g.
3. Compare the two in the comparison tool to confirm size, network, and EBS bandwidth line up. Within matched families they usually do: same memory per size, and things like the 30 Gbps network on m7g.16xlarge versus 25 Gbps on m7i.16xlarge slightly favor Graviton.
4. Check the price in your region on the instance detail pages.
5. Run your workload on both for a representative week. Divide the cost by the work completed. That number, not the sticker discount, is the answer.

Making the call

Clear yes. New workloads with no x86-only dependencies. Containerized services using official multi-arch images. Anything on t3 burstable instances, where t4g is cheaper and faster. Managed services that offer Graviton engines (RDS, Aurora, ElastiCache, OpenSearch), because there’s no code to change at all.

Worth a staging experiment. Existing containerized workloads with mostly standard dependencies. Java, Go, Python, and Node services usually move in days. The experiment costs a t4g or m7g in staging for a week; if it passes, the savings compound for years.

Stay on x86. Windows anything. Vendor software without Arm builds. Workloads licensed per physical core where the license cost exceeds the discount. Single-thread-bound processes that need maximum clock speed today.

Bottom line: Graviton’s discount is real, sits around 15 to 19% depending on generation, and usually grows to 25% or more once you factor in what each vCPU actually delivers. The blocking question is never the price. It’s whether every component in your stack runs on arm64, and whether your licensing model survives the move. Check those two things and the decision makes itself.