ARM (Graviton, Ampere, Axion) vs x86: when to actually switch

Every hyperscaler now ships an ARM core. AWS Graviton4 is on its second generation in production. GCP Axion launched in 2024 and the C4A family is generally available. Azure Cobalt 100 is in preview. The marketing says "20-40% better price-performance". Sometimes that's true. Sometimes the migration cost eats the savings for years.

Here's when ARM is actually worth the move, after running it across a few hundred production nodes.

The current state of pricing

Graviton is consistently ~20% cheaper than Xeon for the same vCPU/RAM on AWS. Axion and Cobalt are landing in the same band. The price advantage is real and structural — ARM cores are cheaper to fabricate at scale.

The performance side — workload dependent

This is where the marketing gets sloppy. Generic "Graviton is 25% faster" benchmarks usually use SPECint or a synthetic load. Real workloads:

• Stateless web servers (Go, Java, Node): Graviton3 / Axion match or beat Xeon for the same vCPU count. Java 17+ on Graviton with the OpenJDK ARM build is genuinely faster per dollar.
• Python/Ruby/PHP web apps: Roughly equivalent. Sometimes Graviton edges, sometimes Xeon, depending on the interpreter version.
• Database workloads (Postgres, MySQL): ARM is competitive on read-heavy. On write-heavy with lots of fsync, Xeon often wins by 10-15% due to better single-thread storage stack throughput.
• Memory bandwidth-bound (analytics, ClickHouse): Graviton4 with DDR5 is excellent. Often 30-40% better per dollar than Xeon.
• Vector / SIMD-heavy: Graviton3 / Graviton4 have SVE2 which is solid. Intel AVX-512 still wins on some specialised loads (HPC, codecs).
• ML inference (CPU-bound): Graviton with NEON outperforms x86 on quantised models. PyTorch and TensorFlow now have first-class ARM kernels.
• GPU adjacent (CPU is a shuttle for the GPU): Either, doesn't matter — the GPU is the bottleneck.

The migration cost reality check

The pricing is enticing. The migration cost is what kills most projects.

What you have to do

• Rebuild all your container images for linux/arm64. Multi-arch builds via Docker buildx, then push.
• Audit every native dependency. PyPI wheels, npm packages with native modules, Go cgo dependencies, JNI libraries — anything not pure Python/JS/Go needs ARM builds.
• Check your monitoring agent (Datadog, NewRelic, Dynatrace) for ARM support. All major vendors now have it; some smaller ones don't.
• Validate JIT warmup time on the JVM if you're running Java — initial ARM cold-start can be slower.
• Re-run your load tests. Per-thread performance and locking semantics differ enough to matter for high-contention workloads.

Engineering time, conservatively

• Greenfield service: ~zero. Pick ARM from day one.
• Single-service migration with a clean container build: 1-2 engineer-days.
• Migration of a fleet with 20-50 services and a custom build pipeline: 1-3 engineer-months.
• Migration of a legacy monolith with native plugins, lots of CGo, custom kernel modules: 3-12 engineer-months. Don't bother unless the compute spend is huge.

The decision

ARM payoff is high if compute spend is the dominant line item AND your workload is amenable AND your build pipeline can absorb the rebuild. Greenfield workloads should default to ARM in 2026 — pick Graviton4 on AWS, Axion on GCP, or Ampere on Azure / Linode / Hetzner / DigitalOcean / Vultr.

For brownfield, do the napkin math first. A team paying $50K/month on EC2 saves $10K/month moving to Graviton — easy ROI. A team paying $5K/month saves $1K and burns six months of engineer time. Often not worth it.

For an instance-level price comparison filter the cloudprice catalogue by architecture or open the AWS provider page and look at the m6g, m7g, c7g, r7g rows. Then compare against GCP's C4A family.

Further reading: AWS Graviton, GCP Axion, and benchmarks at Phoronix for unfiltered comparison data.