Skip to main content

Graviton in 2026: the migration target moved to m8g, c8g, r8g

· 4 min read
Jorel Fermin
Founder, Dragon Fractal · ex-AWS engineer

Short version: AWS Graviton is still about 20% cheaper than equivalent x86 and up to 40% better price/performance, and for most workloads it is a one-line instance-type swap. The thing that changed in 2026 is the target. Graviton4 (m8g, c8g, r8g) is now the current generation, up to 30% faster than Graviton3. If your last migration stopped at m6g or m7g, this is the update.

This is the anchor post for a short Graviton series. The per-service guides (Lambda, Fargate, RDS and ElastiCache) build on this one.

What changed: Graviton4 is the default now​

Graviton is AWS's own ARM64 processor, and the ARM families are priced below their x86 counterparts for the same vCPU and memory. That part has not changed. What changed is the generation you should be targeting. Graviton4 shipped across the general families in 2024, so the 2026 map is:

x86 familyGraviton target (2026)
m5 / m6i / m6am8g
c5 / c6i / c6ac8g
r5 / r6i / r6ar8g
t2 / t3 / t3at4g

Two notes on that table:

  • m8g / c8g / r8g are Graviton4. If a specific size or region does not have the 8th-gen family yet, m7g / c7g / r7g (Graviton3) is the fallback, and still a clear win over x86.
  • Burstable stays on t4g. AWS has not shipped a Graviton4 T family, so t4g (Graviton2) remains the ARM target for t2 / t3 / t3a.

Graviton also backs the managed services: RDS and Aurora (db.m8g, db.r8g), ElastiCache, and OpenSearch all offer Graviton classes at the same kind of discount. Those get their own post in this series.

Step 1: find x86 instances that could move​

aws ec2 describe-instances \
  --filters Name=instance-state-name,Values=running \
  --query 'Reservations[].Instances[].{ID:InstanceId,Type:InstanceType,Arch:Architecture}' \
  --output table

Anything with Architecture: x86_64 on an m, c, r, or t family is a candidate. When we ran our full scan across one real account, 15 running instances had a Graviton equivalent sitting right there.

Step 2: migrate safely​

The instance change itself is trivial (stop, modify type to the Graviton target, start):

aws ec2 stop-instances --instance-ids i-0abc123
aws ec2 modify-instance-attribute --instance-id i-0abc123 --instance-type m8g.large
aws ec2 start-instances --instance-ids i-0abc123

The real work is making sure your software runs on ARM64. In practice:

  • Interpreted and JIT languages (Node, Python, Ruby, Go, Java, .NET) run on ARM with no code change. Just make sure native dependencies have ARM builds.
  • Containers: build multi-arch images (docker buildx --platform linux/amd64,linux/arm64) and your ECS or EKS tasks run on Graviton unchanged.
  • AMIs: use an ARM64 AMI for the new instances.

The caveat: test before you cut over​

The one thing that bites: a dependency with x86-only native code (an old binary, a proprietary agent, a compiled extension without an ARM build). Migrate a non-production instance first, run your test suite, and check any third-party agents (monitoring, security) support ARM. Once green, roll it out. The savings are permanent and require no ongoing work.

Do it automatically​

Cloud Cost Analyzer's graviton-migration-opportunities rule flags x86 instances with a Graviton target and estimates the savings (it only surfaces moves worth at least ~20%), alongside 89 other cost rules:

curl -sSL https://releases.dragonfractal.com/install.sh | sh
cca scan --provider aws

The agent runs in your environment with read-only access, so your AWS credentials never leave it. See the AWS setup and required IAM permissions

Next in the series​

  • Move your x86 Lambdas to arm64 in one line
  • Fargate on Graviton: ~20% off containers
  • RDS and ElastiCache on Graviton
  • The full Graviton migration playbook

Related Articles

CLI Reference

  • aws ec2 describe-instances
  • aws ec2 modify-instance-attribute