If you've spun up a server on AWS in the last six months and didn't reach for the dropdown, you probably ended up on Graviton. That's not by accident. ARM-based server chips went from "exotic option for cost optimizers" to "the default that hyperscalers steer you toward" in about four years. Most engineers I work with didn't notice the shift until their existing autoscaling groups started returning unfamiliar instance types.
The story of how ARM got here tells you a lot about how the cloud actually makes decisions about hardware, and why the memory bottleneck that drove RAMageddon hasn't broken the ARM ramp the way some predicted.
What changed for the chip architecture
For decades, x86 dominated servers because Intel and AMD had the manufacturing scale, the instruction set stability, and the enterprise relationships. ARM was the phone chip. The interesting bit of context is that ARM doesn't actually make chips. It licenses the architecture, and companies like AWS (Annapurna Labs), Ampere, and others design their own server CPUs around it.
AWS launched Graviton 1 in 2018. It was fine. Graviton 2 in 2019 was a real step. Graviton 3 in 2022 was competitive with Intel and AMD on most workloads. Graviton 4 in late 2024 is fast enough that AWS pushes it as the default for most general-purpose workloads.
The architecture itself comes with advantages that x86 historically couldn't match on the same power budget:
- Lower power draw per core. ARM's design philosophy started in phones where every milliwatt matters, and that discipline carried over.
- Higher core counts at lower power. A single Graviton 4 instance can have 192 cores. An equivalent Intel Sapphire Rapids instance tops out around 56 cores per socket under similar TDP.
- Better price-to-performance. AWS lists Graviton 4 instances at roughly 30% lower cost per compute unit than comparable x86 instances.
That last point is the one that actually moves cloud bills.
Why the price gap exists
ARM licenses are cheaper than Intel's per-chip licensing, and ARM-based silicon is generally cheaper to manufacture at the same node because the designs are simpler. Hyperscalers don't pay retail for chips anyway; they negotiate.
But the bigger savings come from power and density. A rack full of Graviton instances draws 40% to 60% less power than an equivalent x86 rack at similar compute output. In a data center where power and cooling are the binding constraints, that translates into more usable compute per square foot.
For AWS, this matters more than the chip margin. They have to keep adding capacity somewhere, and a more efficient chip means more revenue per existing data center before they have to break ground on a new one. The ARM cost advantage isn't really an accident. It's the hyperscaler business model taking advantage of an architecture that fits it.
What breaks when you migrate
Most code that's already compiled to a generic target runs fine on ARM. Python, Node.js, Ruby, JVM-based languages, Go, Rust — they all have solid ARM support and your existing binaries or source code usually work without changes.
The friction shows up in a few places:
- Go binaries compiled for amd64 won't run on arm64. You need to recompile, which is usually a five-minute CI fix, but it touches your build pipeline.
- Docker images built on x86 hosts that don't have a multi-arch manifest will fail to start on Graviton. You'll need either
--platform linux/arm64in your build, or a multi-arch manifest list. - Native dependencies sometimes lag. Older versions of some C libraries don't have ARM CI coverage and break during installation. Most major projects fixed this by 2024, but you still find it in random internal libraries.
- Assembly hot paths are rare in modern code but if you have them, they need rewriting. The
GOATand similar projects now have ARM generators but older hand-rolled assembly still trips some teams.
For most teams, the migration is a CI config change and a smoke test pass. For some teams running specialty scientific code, it's more involved.
The hyperscalers' ARM bets beyond AWS
Google Cloud started offering Axion-based VMs in 2024, partnering with Ampere for the underlying silicon. Axion is Arm Neoverse-based and shows similar price-performance to Graviton. Google's marketing leans into it as the default for AI inference and big-data workloads.
Microsoft Azure announced Cobalt 100 in late 2024. It's custom silicon built around ARM, and at the time of writing it's now serving a meaningful chunk of Azure internal workloads, including parts of Teams infrastructure and Azure SQL.
Apple's contribution is harder to quantify but matters. The M-series chips normalized ARM as a credible client platform, which made it much easier to recruit developers who'd already been burned by ARM toolchain issues once. By 2023, an engineer whose dev laptop was ARM-based didn't see ARM in production as risky anymore.
Even Oracle Cloud has Ampere A1 instances that have been ARM-only for years. The technology isn't the issue anymore. The ecosystem is.
Where x86 still makes sense
Not every workload is a good Graviton fit. The areas where ARM still loses:
- x86-only licensed software. Enterprise tools (older SAP, legacy finance software, certain database engines) only ship x86 binaries. Vendor support contracts often forbid unofficial ports.
- Single-threaded performance ceilings. ARM chips excel at throughput but the per-core frequency is usually lower than the equivalent Intel SKU. If your workload is bound to a single thread and can't parallelize, you might still want a high-clock-rate x86 instance.
- GPU-heavy AI training. The GPU is the bottleneck, not the CPU. The host CPU still matters for data loading. Neither ARM nor x86 wins cleanly here.
- Windows workloads. Microsoft's Windows-on-ARM has come a long way, but it's still less mature than x86 Windows. Most enterprise Windows shops run x86 VMs.
If you're unsure, AWS publishes instance-by-instance benchmarks that compare Graviton 4 to Intel and AMD equivalents. The pattern is usually ARM wins on web servers, microservices, databases. ARM ties or loses on legacy enterprise.
The deeper systems question
The shift to ARM in hyperscale clouds is also a story about post-quantum crypto migration timelines and what happens when you have to recompile half the world's code anyway. Most teams I talk to are putting off the ARM migration until they need to do other infrastructure work that forces a rebuild.
But this is also why the cloud pricing story keeps shifting in confusing ways. The instance you used last year may not exist next year, or it may exist but cost more because the discount tier changed. The hyperscalers don't publish a single instance price list that stays stable. Pricing is now a moving target across architecture generations, and ARM is one of the reasons that target is moving faster.
If your team is mid-migration, the practical advice is to think of ARM as a default and x86 as the exception. Set up multi-arch container builds now, validate your CI matrix covers both, and stop paying the x86 premium unless you have a concrete workload that needs it. The cloud bill drop is large enough that the migration pays for itself in a quarter at most workloads.
