ARM servers against x86: what an instance family saves on one workload

The 20% is a ceiling, not a quote

AWS states that Graviton-based instances cost up to 20% less than comparable x86-based Amazon EC2 instances. That sentence is the whole of the published saving on the Graviton page, and it is a comparison against a comparable instance, which is a judgement the buyer has to make rather than a number the vendor hands over. The same page claims up to 60% less energy than comparable EC2 instances for the same performance, which is a datacentre argument until someone puts it against a power or sustainability budget.

What is missing is the hourly rate. The EC2 instance-types page describes seven families by purpose, general purpose through high-performance computing, and names no price at all; the Graviton page names no price either. The EC2 pricing page that appears in the supplied material renders its figures from a pricing endpoint and shows placeholders rather than amounts, so no on-demand rate for a Graviton instance or its x86 counterpart can be read off the pages here.

That absence is the finding, not a gap to paper over. A team pricing a migration should ask AWS or its account team for the on-demand and Savings Plan rate of the specific Graviton instance and the specific x86 instance it would replace, in the region the workload runs in, because the 20% ceiling applies to a comparison the buyer defines. Until those two numbers are in hand, the saving is a range with an unknown floor.

What Graviton5 changes about the shortlist

The Graviton page describes Graviton5 as carrying 192 cores, a cache five times larger and up to 33% lower inter-core latency, and ties those numbers to agentic AI workloads: real-time reasoning, code generation and multi-step task orchestration that need continuous, high-throughput CPU compute at scale. That is a different pitch from the one ARM instances carried when the argument was cheap web servers, and it puts the family against x86 instance types that a buyer would previously have shortlisted without thinking about instruction sets.

The comparison the buyer actually runs is between a Graviton instance and an x86 instance of the same shape, and AWS's own family taxonomy is where that starts. The instance-types page splits EC2 into general purpose, compute optimised, memory optimised, accelerated computing, storage optimised and HPC, and says general purpose instances suit web servers, code repositories and small-to-medium databases. A team that knows which of those six buckets its workload sits in knows which Graviton instance to price against which x86 instance, and a team that does not will compare the wrong pair and get a saving that does not survive contact with production.

Graviton is also available inside managed services. The Graviton page states that Graviton-based instances are available in Amazon Aurora, Amazon RDS and Amazon EKS, which matters because a workload that runs on RDS is not a recompile project at all. The database is managed, the instance family is a setting, and the decision collapses to whether the engine version and extensions in use are supported on the ARM build.

Where the migration actually breaks

The published guidance divides workloads by how they are built. Applications in Python, Node.js, Ruby, PHP and Java generally run on ARM without code modification, provided the runtime and native libraries support ARM64. Go, Rust and C/C++ applications need recompiling for aarch64. That split is the first thing to check against an estate, because a service written in Go is a build pipeline change and a service written in Java is often nothing at all.

Container images are the second check. Multi-architecture images tagged for both linux/amd64 and linux/arm64 let one registry entry serve a mixed Kubernetes node pool, so a team can move a service to Graviton without forking its deployment. A team whose images are built for amd64 only has to rebuild and republish before the first Graviton node joins the pool, and that work lands on whoever owns the CI pipeline rather than on whoever owns the cloud bill.

The third check is the one the vendor pages do not price: native dependencies inside interpreted applications. A Python service is portable until one of its packages ships a compiled extension, and a Java service is portable until a library carries native components. Neither case is fatal, but each one turns a configuration change into an engineering ticket, and the count of those tickets is what decides whether the 20% ceiling is reachable this quarter or next year.

AWS offers a way to size the prize before committing. The Graviton Savings Dashboard is described as a visualisation tool that shows the impact of current and future Graviton usage, and the page claims it can evaluate potential savings in as little as one hour. That is the cheapest step in the sequence and the one to run first, because it prices the estate as it is rather than as the migration plan imagines it.

The free trial and what it does not cover

The Graviton page offers Amazon EC2 t4g.small instances, powered by Graviton2, free for up to 750 hours per month until 31 December 2026, with the FAQ carrying the detail. A t4g.small is a general purpose burstable instance, so the trial is enough to stand up a service, run its test suite and watch it under load on ARM. It is not enough to reproduce the behaviour of a memory optimised database or a compute optimised batch job, and a team that treats the trial as a benchmark for those workloads will draw the wrong conclusion.

The trial also says nothing about the price of the instance the workload will actually run on. A t4g.small at zero cost for 750 hours is a way to find out whether the software builds and runs, not a way to find out what the estate costs after migration. The number that matters is still the on-demand or committed rate of the production instance, and that number is unpublished on the pages supplied.

The date is worth putting in a calendar for a second reason. A trial that ends on 31 December 2026 is a deadline for the evaluation, not for the migration, and a team that starts in the fourth quarter has one quarter to finish the build work before the free capacity stops being free. The FAQ is the place to confirm the terms, including which regions and operating systems the offer covers.

What to ask before the family changes

Ask for the hourly rate of the Graviton instance and the x86 instance it would replace, in the same region, on the same operating system, with the same commitment. The 20% ceiling is measured against a comparable instance, and comparable is the word that decides whether the saving is real. A team that compares a Graviton general purpose instance against an x86 compute optimised instance will produce a number that flatters ARM and does not survive a capacity review.

Ask which managed services in the estate already run on Graviton, because Aurora, RDS and EKS are named on the page and a workload inside them needs no recompile. The saving there is a configuration change with a support matrix attached, and the support matrix is the thing to read before the change window rather than during it.

Ask the engineering team for a count of services by language and a count of container images without an arm64 tag. Those two numbers, not the 20%, decide the timeline. A Java estate with multi-architecture images can move a service in an afternoon; a Go estate with amd64-only images has a pipeline project in front of it, and the saving arrives after that project ships.

Ask what the energy claim is worth to the organisation, if anything. Up to 60% less energy for the same performance is a published figure, but it only changes a decision where a sustainability target or a power budget is already a constraint on the estate. For everyone else it is context, and the cost comparison stands on the hourly rate alone.

Who should walk away

Walk away if the workload is a legacy proprietary binary with no ARM build and no vendor commitment to one. The published guidance is explicit that x86 remains the fit for legacy proprietary binaries and for workloads that depend on x86-specific kernel modules, and no discount on the hourly rate pays for a rewrite that has no owner or no date.

Walk away if the workload depends on AVX-512 vector maths or on a native library that has not been ported. The saving is a percentage of an instance rate, and a workload that cannot run on the instance has no rate to discount. The same applies to a team that cannot rebuild its container images, because the image is the deployment unit and an amd64-only registry entry will not schedule onto an ARM node.

Choose Graviton for a service written in an interpreted language, built into a multi-architecture image, and already running in a general purpose family, because that is the case where the 20% ceiling is reachable without an engineering project. Choose it for a database on Aurora or RDS where the engine version is supported, because the change is a setting. Wait if the estate is Go or C/C++ with a build pipeline nobody has touched this year, and run the Graviton Savings Dashboard first so the size of the prize is known before the work is scheduled.