All cheat sheets
Computecheat sheet

AWS Graviton-based Instances

Switch from x86 to AWS's ARM-based Graviton chips for up to 40% better price-performance — often a single config change. Lambda arm64 is a one-field flip; containers are a base-image swap; the savings compound every hour, forever.

Last reviewed: July 14, 2026

TL;DR: Graviton is AWS's ARM-based silicon delivering up to 40% better price-performance than comparable x86 — same workload, less money. Because AWS designs the chip and skips Intel's margins, it passes savings to you every hour, forever. The migration is far easier than the "won't I recompile everything?" fear suggests: interpreted/JIT languages (Python, Node, Java, Ruby) run unchanged, containers swap base images, and managed services (Lambda, RDS, ElastiCache) are literally a config flip. Unlike Reserved Instances, there's no lock-in — switch back anytime.

The numbers

  • Lambda arm64: one field (architecture: arm64) for up to 19% better price-performance, zero recompile for interpreted languages — the lowest-effort win in AWS cost optimization.
  • EC2 like-for-like: m5.xlarge → m6g.xlarge (same specs, Graviton2) is ~20% off immediately; families cover general (M/T), compute (C), memory (R/X), storage (Im/Is), and GPU (G5g).
  • Compounding: 50 m5.large ($4,380/mo) → m6g.large (~$3,504/mo) = $876/mo / >$10,500/yr on one instance type in one region.
  • Graviton3 uses up to 60% less energy for the same performance — a real sustainability lever.
  • Field examples: a SaaS cut $2,400/mo in under 3 weeks (Lambda → ECS → RDS replica); an enterprise saved $8,000/mo on one ML inference service (15% faster too), scaling to $500K+/yr org-wide.

Do this

  1. Flip one Lambda function to arm64 this week — a 5-minute config change and deploy; the savings start that day and build team confidence.
  2. Swap container base images to ARM64 variants — official Node/Python/nginx/postgres/redis images publish arm64; ECS/EKS run mixed clusters during transition, and you can A/B test at identical vCPU/memory.
  3. Migrate in phases: stateless workloads → managed services (Lambda + a Graviton RDS read replica to validate) → core app/cache/batch tiers → make Graviton the default for net-new.
  4. Recompile compiled-from-source binaries (Go, Rust, .NET Core) with one flag; audit dependencies for any x86-only proprietary binaries first.
  5. Stack with commitments — apply Compute Savings Plans on top of the Graviton discount for compounding savings.

Gotchas

  • Windows is x86-only on Graviton (Linux only) — check your stack.
  • x86-only proprietary binaries and hand-written x86 assembly/intrinsics are real blockers — identify them in a dependency audit before committing effort.
  • Native binaries need recompiling — trivial for Go/Rust/.NET, but not zero; interpreted languages skip this entirely.
  • Vendor licensing occasionally differs across architectures — confirm before migrating licensed software.

Skip this if

  • The workload is Windows, depends on x86-only proprietary binaries, or is heavily hand-optimized for Intel intrinsics — leave it on x86 rather than force it.
  • You haven't picked which workloads to move first — run Compute Optimizer to surface the highest-value candidates. Otherwise there's almost no downside: start with one Lambda function and let the data convince the team.

Run this audit with your AI assistant

Paste this into Claude, ChatGPT, or any agent that can run the AWS CLI with read-only credentials. It audits your account for exactly the waste this sheet describes — and changes nothing.

You are auditing an AWS account for Graviton (ARM) migration savings.
Use the AWS CLI with READ-ONLY credentials. Do not create, modify, or
delete anything — report findings and recommended (unapplied) fixes only.

1. Lambda: aws lambda list-functions — flag x86_64 functions (esp.
   Python/Node/Ruby — zero recompile) as one-field arm64 flips (~19%
   cheaper).
2. EC2: aws ec2 describe-instances — map current families to Graviton
   equivalents (m5->m6g/m7g, c5->c6g/c7g, r5->r6g/r7g, t3->t4g); estimate
   ~20% savings per like-for-like swap. Flag Windows and x86-only
   proprietary binaries as NOT eligible.
3. Managed services: aws rds describe-db-instances, elasticache
   describe-cache-clusters — flag Graviton-capable engine versions
   running on x86 (e.g. db.r5 -> db.r6g read replicas).
4. Migration order: containers (ARM64 base images), then Lambda, then
   stateless EC2, then databases; note native-binary recompiles.

Report a table: resource | current arch | Graviton target | est. $/mo
saved | effort (config flip / rebuild AMI / recompile) | blocker?
Change nothing.
Works with any assistant that can run shell commands.

Want the guided version?

The AWS Graviton-based Instances walkthrough covers this topic interactively — it asks about your setup, branches to what’s relevant, and quizzes you on the tricky parts. Free and anonymous.

Start the walkthrough