Graviton vs Axion vs Ampere: what actually differs

Published August 19, 2026

Four clouds now sell Arm compute as the default rather than the curiosity, and the marketing for all four sounds the same. So we ran the same benchmark suite on the same Ubuntu 24.04 LTS arm64 image, at matched vCPU counts, on AWS Graviton, Google Axion and Ampere Altra, Oracle Ampere Altra and AmpereOne, and — new to this update — Microsoft Azure's Cobalt 100. The interesting results are not about which vendor's core is fastest — they are about two clouds charging very different money for literally the same chip, about how many of these instance families turn out to be the same machine wearing a different name, and now about an efficiency-line Arm core landing level with two performance-line ones.

How this was measured

One benchmark script, twelve test units, run unmodified on every instance: single-thread and all-core integer work, 7-Zip LZMA, OpenSSL AES and SHA, STREAM memory bandwidth, a pointer-chase latency sweep, zstd and gzip on a fixed corpus, a real compile of a pinned zstd release, Redis over loopback, nginx behind wrk, fio for disk, a mixed Python workload, and an iperf3 network test that needs a second instance and so did not run everywhere. Same flags, same durations, same corpus — whose sha256 is recorded in every result — on Ubuntu 24.04 LTS arm64 from each cloud's own first-party image. Steal time was sampled around every test: 0.00% on every AWS, GCP and Azure instance, below 0.7% on the OCI shapes, and 35% on the one burstable shape.

The index column below is a composite of 13 metrics drawn from 10 of those 12 test units, normalised so that c8g.4xlarge = 100. The two units that contribute nothing to it are the disk test and the network test — which matters, because further down this article we explain that the disk test measured the attached volume rather than the instance. If fio were in the index, every index figure here would be partly a measurement of a provisioned storage ceiling. It is not. Graviton, Axion, Ampere and Azure's Cobalt 100 are all one thread per core, and an Oracle Ampere OCPU on the A1 shape is one physical core, so 16 vCPU means 16 real cores on all four clouds. That is not true of an x86 comparison, where 16 vCPU usually means 8 cores, and it is the reason a straight vCPU-for-vCPU table is defensible here.

Read the caveats at the bottom before quoting any of this. The most important one: placement was only varied on AWS. All three clouds have network numbers, but GCP and OCI contribute one shape each at default placement, so there is no three-way placement comparison in this data. This article keeps network figures out entirely and leaves them to the placement and streams article.

The whole result set

Sixteen vCPU unless the row says otherwise. Prices are Linux on-demand from the InstanceFinder dataset for us-west-2 (AWS), us-central1 (GCP), us-ashburn-1 (OCI) and westus3 (Azure), read on 2026-08-13, 2026-08-18 and 2026-08-20.

Index per dollar is only comparable between rows with the same vCPU count. The two 4-vCPU rows look like bargains because AWS prices c8g.xlarge at exactly a quarter of c8g.4xlarge ($0.1595 × 4 = $0.638 against $0.6381) while the composite only rises from 47 to 100 for four times the cores. That is the metric behaving as designed, not a discount.

Azure is new to this dataset as of this update, with one clean data point at exactly this article's comparison size: Standard_D16ps_v6, on Microsoft's Cobalt 100 Arm core. It earns its own sentence rather than a silent row in the table above, because Cobalt 100 is Arm's Neoverse N2 — the N-series, built for scale-out efficiency — while Graviton4 and Axion are both Neoverse V2, the performance-line design. Landing at a composite of 98 against the V2-based c8g.4xlarge baseline of 100 means an efficiency-line core matched a performance-line core's score on this suite — not a repeat of the Axion-vs-Graviton4 result above, where both cores are the same V-series design. That tie is on the average, not on the workload: Cobalt 100 reaches the same composite by a completely different route — roughly a fifth faster on integer throughput, SHA-256 and aggregate memory bandwidth, and roughly 15% to 26% slower on Redis, nginx and AES-256-GCM. A same-composite headline hides that spread; do not read "matched" as "identical on every test", because it is not, in either direction. At $0.5620/hr that is 174 index per dollar — second, among the shapes with a complete 13-metric composite, only to OCI's Ampere Altra at 285 among all four clouds at this size, level with AWS's c9g at 173 on a difference this single sample cannot resolve, and clearly ahead of AWS's c8g at 157 and GCP's c4a-standard-16 at 145.

Treat this as one data point, not a verdict on Azure Arm generally: it is a single sample — though the cleanest one Azure has produced so far, with zero flagged outliers and all 13 composite metrics present, unlike the D2, D4 and D96 runs. Azure benchmarking in this campaign is still in progress — 6 of 8 planned sizes have landed cleanly (D2, D4, D8, D16, D32 and, from a separate later run, D96), with D48 and D64 still outstanding — and Standard_D16ps_v6 is the only one of them relevant to this article. The rest feed a separate, still-gated article about how these cores scale with size. Do not read this article as covering the full Azure Arm range.

The same chip, 2.4× apart on price

This is the clearest finding in the set, and it has nothing to do with silicon design. Oracle's VM.Standard.A1.Flex and Google's t2a-standard-16 are both Ampere Altra (Neoverse N1). At 16 vCPU they scored a composite index of 73 on both, identical to within 0.7%. Oracle charges $0.2560 an hour for it. Google charges $0.6160. That is 285 index per dollar against 119 — 2.4× the price-performance for the same chip.

There is no performance story to argue about here. Same core, same image, same test suite, same score. The gap is entirely a pricing decision. If your workload is a fit for Altra-class cores — and plenty of web, API and general server work is — then t2a is very hard to justify against Oracle's A1, and it is also hard to justify against Graviton: c8g.4xlarge is 37% faster on the composite (100 against 73) for $0.6381 against t2a's $0.6160, a price difference of about 3.6%.

The honest caveat is that this is a compute-price comparison, not a bill. Egress, support, managed services and the cost of running in a cloud your team does not know are all outside these numbers, and any of them can swallow a 2.4× compute saving. What the data does settle is that the compute line item is not close.

Axion is Graviton4, in performance and in price

Google's Axion is a Neoverse V2 design, the same generation as Graviton4, and it behaves like it. The two comparable pairs land almost on top of each other:

The general-purpose pair is separated by three index points and three hundredths of a cent an hour: $0.7184 against $0.7181. The compute-optimised pair is closer still — a tie on the composite once rounded to this table's convention, 100 against 100, though the full-precision figures (99.5 against 100.0) put GCP a hair behind rather than dead level — with GCP the cheaper of the two at $0.6061 against $0.6381. Nobody should choose between AWS and GCP for Arm compute on the strength of these numbers, in either direction — the difference is inside the noise a reader should care about, and it is certainly smaller than the difference between two adjacent Graviton generations.

That is the useful conclusion, and it cuts against both vendors' marketing. Axion is not a step change over Graviton4 and Graviton4 is not a moat against Axion. Choose on region, quota, managed services and what your team already runs.

Three Graviton generations, cleanly separated

AWS is the only one of the four clouds with enough Arm history to show a generational curve, and the curve is real:

Roughly a fifth faster each time, twice in a row, with no overlap between generations. Price-performance improved at each step too — 145 to 157 to 173 index per dollar — which is worth stating because it is not guaranteed. Vendors routinely price a new generation to capture its own gain. AWS did not here: c9g costs 9% more than c8g ($0.6955 against $0.6381) for 20% more composite performance.

The generational jump is not uniform across the tests, though. At 16 vCPU, c9g.4xlarge has less memory bandwidth than c8g.4xlarge — 164 GB/s against 310 GB/s, so the older shape delivers about 1.9× as much — alongside substantially better idle DRAM latency, 91 ns against 128 ns. Those are means: 164.2 GB/s across two c9g.4xlarge samples that agree within 1.4%, and 310.2 GB/s across three c8g.4xlarge samples spanning 6.6% from lowest to highest. A gap of 1.9× is far wider than either spread, so the effect is not in doubt. c9g still wins the composite comfortably, because most of the index is latency- and IPC-sensitive rather than bandwidth-bound.

It would be easy to write that up as "Graviton5 has less memory bandwidth", and it would be wrong about the core. The single-threaded STREAM figures point the other way:

One Graviton5 core gets 8.4% more bandwidth than one Graviton4 core. Sixteen of them get about half the aggregate. That is not a microarchitectural regression, it is a statement about how much of the socket a 16-vCPU slice can reach. The core is slightly better fed; the slice has a lower ceiling. Our own scaling data shows the same effect within one generation — a 16-vCPU c8g gets 19.4 GB/s per vCPU where a 1-vCPU c8g gets 24.1, and a 96-vCPU one gets 4.3 — so the amount of a socket a given slice can reach is a real variable independently of which core is in it.

Hold that 8.4% loosely. It rests on two c9g samples against three c8g samples; the two c9g single-core readings are themselves 4.4% apart, and one of those runs varied 4.6% across its own three repeats — the noisiest single-thread measurement in the set, and it is on the shape carrying the claim. So the effect is about twice the size of its own measurement scatter: real but modest. It is also a claim about these two shapes rather than about Graviton5 the design, since we measured only one c9g size. What is not in doubt is the aggregate gap, at 1.9×.

If you run something that is genuinely bandwidth-bound — large in-memory analytics, sparse linear algebra, a columnar scan that does not fit in cache — that is a case where the newer generation could be the slower choice, and you should measure your own workload rather than trust the composite. For pointer-heavy code, databases and interpreted runtimes, the latency improvement is the more relevant half of the trade.

Every Graviton4 family is the same machine at a given vCPU count

AWS sells c8g, m8g, r8g, i8g and c8gn as five different products. At 16 vCPU they are one CPU with different amounts of RAM bolted on. On the sysbench integer test, single-core results spread by 0.1% across the families and all-core by 0.05%, and memory bandwidth spreads by 3%. Treat those first two as one metric rather than the whole test set: the 7-Zip figures from the same five runs scatter by 26% single-thread, though much of that is measurement noise rather than hardware, since m8g alone recorded 5321, 5005 and 5018 MIPS across three runs of the same shape. The 3% bandwidth figure needs a word of explanation too, because three instances of a single one of these shapes spread by 6.6%. The gap between the families is smaller than the gap between two instances of the same family. That is not a small difference between five products; it is no detectable difference at all.

Note what the Triad column does not do: it does not track RAM size or price. r8g.4xlarge costs 48% more than c8g.4xlarge and delivers the same compute and the same GB/s per vCPU. You are buying capacity, not bandwidth. The practical rule is to size on memory footprint alone: if 31 GiB fits, the memory-optimised family buys you nothing at all except a larger bill. In fairness, the label delivers what it claims — 124 GiB against 31 GiB at the same vCPU count — but it is commonly misread as promising faster memory, and it does not.

Two exceptions in that table are real and worth knowing. c8gn is the network-optimised member, and its advantage is genuine but conditional: it needs multiple parallel streams to appear at all, and it only reaches its advertised ceiling inside a cluster placement group. Our placement and parallel-streams article has the measurements. It also had the lowest DRAM latency in the group, 118 ns. i8g is the storage-optimised member. Its result file records a 3.4 TB local NVMe device present on the instance, and our fio test ran against the EBS root volume instead — so the storage that justifies its premium was sitting there unbenchmarked. Judge i8g on storage behaviour we did not measure, not on the CPU numbers above.

Where the four clouds genuinely differ

Not in core speed — the sections above show the two current-generation V2 designs are interchangeable, the Altra parts score identically, and Azure's single Cobalt 100 data point lands close enough to that V2 pair that it is not a speed story either. The differences that will actually cost you money or a weekend are in how each cloud counts, prices and provisions the machine around the core: the subsections below cover GCP and OCI specifically, on top of the AWS-specific findings above — Azure has one clean data point so far, not yet the range of measurements needed to say where its own billing or provisioning quirks are.

Oracle: an OCPU is not always a core

Oracle bills Ampere shapes per OCPU, and the mapping from OCPU to vCPU is not constant across its own Arm families. On the A1 shape (Ampere Altra) one OCPU is one vCPU. On A2 (AmpereOne) and A4 (AmpereOne M) one OCPU is two vCPUs. We measured A2 and A4 twice for exactly this reason: once at 32 vCPU (16 OCPU) and again at 16 vCPU (8 OCPU).

This is the single easiest way to misprice an OCI Arm instance. Every shape we measured runs one thread per core, so on A2 and A4 one OCPU is two vCPUs and therefore two physical cores. A cost model that assumes "one OCPU is one core" everywhere — which is true on A1 — understates A2 and A4 core counts by half, and so overstates their cost per core by a factor of two. Check the family before you divide.

The A2 run at 8 OCPU / 16 vCPU is missing its CPU and disk metrics because of a transient package-install failure during the run. That gap is why this article does not put AmpereOne in the main 16-vCPU index table.

AmpereOne: one benchmark disagrees with seven others

AmpereOne is where careful reading matters most, and where a lazy article would go badly wrong. On sysbench, AmpereOne comes out at 0.23× Altra per core — a catastrophic-looking result. Nothing else in the suite agrees. At matched 16 vCPU, the other tests put AmpereOne within roughly 15% either side of Altra:

Nine measurements across eight tests scattered within roughly ±15% in both directions, and one test saying "about a quarter the speed", is a story about the one test rather than about the chip. Sysbench's integer loop is a narrow, highly specific workload, and nothing else here reproduces its verdict — A2's L1 cache latency is also identical to Altra's, at 1.342 ns against 1.341 ns. We publish the outlier because hiding one is worse than explaining one, and because plenty of published Arm comparisons rest on sysbench alone. If you have seen AmpereOne described as several times slower than Altra, this is very likely why.

The practical consequence: the composite index drags AmpereOne down, because sysbench is one of its 13 inputs. Runs with flagged outliers also carry a compositeExOutliers figure in summary.json — but do not expect it to rescue AmpereOne, because it does not. On the 32-vCPU runs it goes slightly down rather than up, since the outlier list contains an unusually strong SHA-256 result pulling the opposite way to the weak sysbench one, and excluding both roughly cancels. The honest position is not that some other number redeems AmpereOne; it is that no single number should be carrying the verdict here at all — not sysbench, and not our composite either.

Two precisions on the above. The L1 result is specific to A2: A4 (AmpereOne M) measured 1.119 ns, 17% faster than Altra, so "AmpereOne's L1 matches Altra's" would be wrong as a family claim. And AmpereOne is the one part where the composite in the main table above would mislead badly, which is why no AmpereOne shape appears in it.

Google: the two Arm families cannot be given the same disk

This is a structural difference rather than a benchmark result, and it constrains any GCP Arm comparison including ours. C4A (Axion) is Hyperdisk-only — it will not launch with Persistent Disk at all — while t2a requires Persistent Disk. There is no disk class the two GCP Arm families can share, so a like-for-like storage comparison between Axion and GCP's Altra is impossible in principle, not merely unmeasured.

It also means our own storage numbers are close to useless for choosing a shape, and we would rather say so than dress them up. Every AWS shape returned about 3,000 read IOPS and 125 MB/s: exactly the provisioned ceiling of the gp3 volume attached to it. GCP C4A on hyperdisk-balanced returned 140 MB/s, which is that tier's own floor. The disk test measured the volume, not the instance. Treat it as a rough comparison of default storage tiers between providers, never as a comparison between shapes on one provider.

Fit summary

Only rows this data can actually support. Where we did not measure something, the cell says so rather than guessing. Azure has no column here: one clean data point at one size cannot support fit judgements on cost, generations, placement and disk the way three clouds with multiple shapes, sizes and repeat runs can — see the note above.

✓ strong fit  ·  ~ workable, or available with caveats  ·  × poor fit  ·  n/a not available to us  ·  n/m not measured

Reading the rows that are not obvious from the tables above. Cost: the row grades the cheapest shape each cloud offers per unit of work, not its worst. OCI wins on compute price alone and wins by a lot. AWS is mid-pack but consistent. GCP is marked down because its best Arm shape on this measure (c4a-highcpu-16 at 165) trails AWS c9g at 173, and because t2a at 119 is the worst value in the dataset — but its Axion shapes are level with AWS, and nobody should read that cell as "GCP Arm is expensive". Fastest core: OCI's mark refers to Altra, its only complete 16-vCPU Arm result; its AmpereOne shapes score higher on the composite but that is the figure this article has just told you not to trust for AmpereOne, so we are not ranking on it. Generations: AWS is the only cloud where you can pick between three measured Arm generations and where the newest is also the best value. Placement control: AWS supports cluster, partition and spread on c8g, c8gn and c9g; we measured the effect of cluster and spread, and did not measure partition. GCP creates a COLLOCATED placement policy fine and we measured it: throughput did not move, but round-trip time more than halved, to the lowest figure in the whole campaign. The caveats are that --max-distance is missing from gcloud 580.0.0 (the beta REST API does accept maxDistance), and that compact placement requires onHostMaintenance=TERMINATE, so you forfeit live migration to get it. On OCI, oci cpg cluster-placement-group exists but returned 404 NotAuthorizedOrNotFound, consistent with limited availability that Oracle has to enable per tenancy — so it is not a control you can assume you have. All three checked on 2026-08-18.

What this data does not tell you

The reason to trust the numbers above is that we are willing to be specific about their limits.

• Placement was only varied on AWS. All three clouds now have throughput and latency numbers, but AWS was measured across two shapes and three placement modes while GCP and OCI contribute one shape each at default placement only, one sample apiece, in three different regions. So there is a three-way single-stream-versus-parallel comparison and there is no three-way placement comparison — distrust anyone who presents the latter from this dataset. We have deliberately kept every network figure out of this article and put them, with their limits, in the placement and streams article.
• Regions differ: AWS us-west-2, GCP us-central1, OCI us-ashburn-1. Fine for comparing silicon, not for comparing latency.
• Most shapes have two samples, some only one, and they were same-day runs rather than runs on different days. Placement luck is real and two samples do not eliminate it.
• The burstable result describes a throttled machine. t4g.xlarge hit up to 35.2% steal time when its CPU credits ran out mid-run (35.16% and 35.05% across two runs). That is a real measurement of a real condition, not a broken test, but it is not what a t4g does in its first two minutes.
• Memory bandwidth varies by 6.6% between instances of the same shape. Three c8g.4xlarge instances returned 298.3, 313.4 and 318.8 GB/s. That is the single most useful number for calibrating your scepticism about this article and about any other bandwidth comparison: an argument resting on a bandwidth difference smaller than about 3% is not supportable, ours included. It is why the 3% spread across the Graviton4 families is presented above as evidence that they are one machine rather than as a ranking, and why the Graviton4-against-Graviton5 comparison uses means (310.2 and 164.2 GB/s) rather than single readings. Individual figures quoted from the tables are single samples and carry that 6.6% uncertainty.
• Older bandwidth results are not comparable at all. Runs before 2026-08-13 22:08Z used a smaller working set. Every bandwidth figure quoted in this article uses the fixed 3 GiB working set. The composite index is a separate matter: it is normalised against one specific baseline run of c8g.4xlarge that predates the fix, which shifts every index by roughly 0.3 points and changes none of the conclusions here. A fourth c8g.4xlarge measurement of 325.7 GB/s exists and is deliberately excluded from the mean above for that reason — we mention it so the exclusion is visible rather than silent. If you go into the raw data, check stream_bytes_total in runs-index.csv before comparing across runs.
• Storage numbers measure the volume, not the instance, as described above.
• The OCI runs started on a Free Tier account that refused every Ampere launch with "out of host capacity" across all three availability domains. That is account state rather than a statement about Oracle's capacity; the OCI numbers here come from launches that later succeeded.
• Azure is one data point, not a size curve. Only Standard_D16ps_v6 at 16 vCPU is used in this article, from a single sample. Azure benchmarking in this campaign has landed 6 of its first 8 planned sizes, with D48 and D64 still outstanding; the rest feed a separate, still-gated article about size-scaling, not this one — do not read this article as covering the full Azure Arm range.
• Prices are Linux on-demand from the InstanceFinder dataset, read on 2026-08-13, 2026-08-18 and 2026-08-20 (Azure). OCI Flex shape prices are computed from the per-OCPU and per-GB rates. Prices move; the aggregator stamps the price it used into summary.json.

The short version

If you are choosing an Arm instance today: the current-generation cores from AWS and Google are the same core and priced the same, so pick on everything else. AWS's newest generation is genuinely 20% faster than its previous one for 9% more money, which is unusually good value for a refresh. Oracle sells the same Ampere Altra chip Google sells, for 2.4× better price-performance, and if your workload fits an older Arm core that is the biggest single number in this whole dataset. Within AWS, ignore the family names and size on memory footprint: at a given vCPU count they are one machine, and the memory-optimised badge costs 48% more for the same compute and the same bandwidth per core. Azure's Cobalt 100 is the newest entrant, and on one sample it lands level with the V2 pair on the composite while getting there by a completely different per-test profile — a data point worth watching, not yet a verdict.

You can compare the underlying instance types and current on-demand prices for AWS, GCP, OCI and Azure, or line up every provider at once in Compare all.