AWS Graviton Migration: A Pragmatic 2026 Guide
Graviton instances are 20-40% cheaper than x86 at equal or better performance. The hard part isn't technical — here's how to actually do the migration without breaking things.
By Andrii Votiakov on
Graviton is the easiest 20-40% cost cut available on AWS today. The technical work is real but small; the political work is bigger. Most teams know they should migrate but never get past "we'll look at it next quarter". Here's how to actually finish the job.
Quick answer
Graviton (*g, e.g. m7g, c7g, r7g) is AWS's ARM-based instance family. It's typically 20% cheaper than equivalent x86 and 10-40% faster on most modern workloads. Migration is straightforward for Node, Python, Go, .NET 7+, Java 11+, and most container-based services. The real work is rebuilding container images for linux/arm64 and updating any binaries that ship as x86-only.
What actually runs on Graviton today
Works without changes:
- Node.js (since v15)
- Python (CPython 3.6+, PyPy 7.3+)
- Go (any modern version)
- Java 11+ (OpenJDK, Corretto, Temurin)
- .NET 6 and 7+
- Most managed services: RDS, ElastiCache, OpenSearch, MSK, Lambda
Needs work:
- Native dependencies (numpy, Pillow, lxml, Postgres extensions) — usually fine but rebuild required
- Custom-built C/C++ binaries — recompile
- Closed-source vendor binaries — may not exist for ARM64 (this is the most common blocker)
- Some database drivers and ML libraries with x86-specific SIMD optimisations
Rarely an issue in 2026, but always worth a 15-minute audit before committing.
The migration sequence
Step 1: Pick a low-risk service first
Don't start with the database or auth service. Start with something stateless: a worker, a background job processor, an internal API. Run it on Graviton in staging for a week.
Step 2: Multi-arch images
Build container images for both architectures during the transition:
docker buildx build \
--platform linux/amd64,linux/arm64 \
-t myrepo/myapp:1.0 \
--push .
Most modern base images (python:3.12-slim, node:20-alpine, golang:1.22) already have ARM64 variants. CI runners often need an ARM64 builder pool — GitHub Actions has free ARM runners now, or use BuildKit on a Graviton EC2 host.
Step 3: Benchmark
For each candidate service, run a real load test on Graviton vs the x86 equivalent. Look at:
- Throughput at fixed P99 latency
- Memory usage (often 5-15% lower on Graviton)
- Cold start time (Lambda especially)
Most services come out 10-30% faster on Graviton at the same instance size. Some (heavy SIMD floating-point workloads) come out slightly slower — those stay on x86.
Step 4: Roll incrementally
Mixed ASGs work fine. Run a 10/90 Graviton/x86 split for a week, then 50/50, then 100/0. Watch error rates and latency at each step.
Step 5: Don't forget managed services
The biggest single line item is often RDS or ElastiCache. RDS on Graviton (db.m7g.*, db.r7g.*) is 20% cheaper at the same size and ships with Aurora optimised for ARM. ElastiCache Redis on Graviton is identical from the application side.
These are the easiest wins of the entire migration: change one parameter, restart, save 20%.
The political part
The reason most teams stall isn't technical — it's that engineers are nervous about "will my service still work?" Three things help:
- Set a target. "By end of Q2 we run 60% of compute on Graviton." Without a number, it doesn't happen.
- Show the numbers. Pull last month's compute spend, multiply by 0.8 for the Graviton portion, show the saving in real money. Annualised, it's usually a six-figure number.
- Make it the default for new services. Once a team has Graviton in production for one service, defaulting new ones to Graviton becomes trivial.
Common pitfalls
- CI/CD builds are slow on a single x86 builder doing emulation. Set up a real ARM64 builder.
- Docker images explicitly tagged with x86 in their FROM line. Audit your Dockerfiles for
FROM linux/amd64/...lines. - Old AMIs. EKS-optimised AMIs, ECS-optimised AMIs and bottlerocket all have ARM64 variants — use them.
- Spot pools. Some niche instance types have thinner Spot pools. Use the Spot placement score before betting on capacity.
- Forgetting to switch RDS. This is the single highest-ROI move and is often skipped.
Realistic timeline
For a typical mid-sized SaaS:
- Week 1: Audit + build pipeline updates
- Weeks 2-3: Migrate stateless services
- Weeks 4-5: Migrate managed services (RDS, ElastiCache)
- Week 6: Migrate Lambda functions
- Week 7: Buy Compute Savings Plans on the new baseline
Total saving: 20-25% of compute and managed services spend, locked in.
If you want a Graviton migration plan tailored to your stack — including what stays on x86 — book a call.