Graviton migration — 20–40% better price-performance, often for a config flag.

IWhat Graviton actually is — and why the savings are structural, not promotional

Graviton is AWS's own line of 64-bit ARM (Arm Neoverse-based) server processors, designed by Annapurna Labs inside AWS. Because AWS designs the silicon, controls the supply chain, and runs it at hyperscale, it can price Graviton instances below the Intel and AMD equivalents while delivering more performance per watt. The discount is structural — it's baked into the on-demand rate card — not a temporary promotion that expires.

There are three generations in broad service as of 2026. Graviton2 is the mature, everywhere-available generation. Graviton3 adds roughly 25% more compute performance, higher memory bandwidth, and meaningfully better floating-point and crypto throughput than Graviton2. Graviton4 is the current top end — more cores, more memory bandwidth again, and the best price-performance of the three — rolling out across the newer instance families (the R8g, M8g, C8g and successors). When this page says "Graviton," assume you'll land on Graviton3 or Graviton4 depending on the family and Region you pick.

The headline AWS publishes is "up to 40% better price-performance versus comparable current-generation x86 instances." That is a real, repeatedly-benchmarked figure for the right workloads, but the honest framing is a range, not a guarantee: most teams see somewhere in the 20–40% band depending on how memory-bound, compute-bound, or I/O-bound the workload is. A latency-sensitive Java service that fits the cores well lands high in the band; a workload pinned on a specific x86-only native library may see no benefit until the dependency is replaced. Treat 20–40% as the planning range and confirm with a benchmark on your own traffic.

Two things make the savings compound beyond the per-hour rate. First, Graviton instances draw up to roughly 60% less energy for the same work, which AWS passes through partly as price and which matters directly if you have a carbon/sustainability mandate. Second, the per-vCPU performance is high enough that teams frequently right-size DOWN a tier when they migrate — a workload that needed an 8-vCPU x86 instance often runs comfortably on a 4- or 6-vCPU Graviton instance, stacking a right-sizing win on top of the rate win. (See the companion lever, EC2 right-sizing, for how to confirm that headroom with Compute Optimizer.)

Crucially for cost work: Graviton is not a niche. It runs the same Linux you already run (Amazon Linux 2023, Ubuntu, Debian, RHEL, AL2 all ship ARM64 builds), the same containers (multi-arch images), the same managed databases and caches. The ARM ecosystem in 2026 is mature — the days of "ARM might not have a build" are largely behind you for mainstream stacks. That maturity is exactly why Graviton has moved from "experiment" to "default first choice" in most FinOps playbooks.

IIWhere Graviton runs — it's far more than EC2

Most people first meet Graviton as an EC2 instance choice. But the largest, lowest-effort savings usually come from the managed services, because AWS already did the porting work — you just pick the Graviton-backed instance class and the engine runs identically.

Here is the practical coverage map as of 2026. For each, the question to ask is "is this a flag, or a rebuild?" — and for everything except self-managed compute on EC2, it's a flag.

• Amazon EC2 — The full self-service surface. Graviton instance families span general purpose (M-series, e.g. M7g/M8g), compute-optimized (C-series, C7g/C8g), memory-optimized (R-series, R7g/R8g, plus X-series for very large memory), burstable (T4g), storage, HPC, and accelerated families. This is the one place you may need to recompile and test — covered in section IV.
• Amazon RDS & Aurora — MySQL, PostgreSQL, MariaDB on RDS, and both Aurora MySQL- and PostgreSQL-compatible editions run on Graviton-backed db.*g instance classes (e.g. db.r7g, db.m7g). The database engine is unchanged — your schema, queries, and drivers don't know or care. This is the single biggest flip-a-flag win for most data-heavy apps. Pair it with a Reserved Instance and the savings compound (see rds-cost-optimization).
• Amazon ElastiCache & MemoryDB — Redis/Valkey and Memcached on ElastiCache, plus MemoryDB, all offer Graviton node types. Caches are throughput machines, and they tend to show strong Graviton gains. Flipping the node type is a configuration change with a brief failover.
• Amazon OpenSearch Service — Data and master nodes run on Graviton instance types. Search and log-analytics clusters are often large and always-on, so the percentage saving translates into a big absolute number — frequently one of the highest-dollar single moves on the whole bill.
• AWS Lambda — Functions can run on the arm64 architecture with a single setting. Lambda on Graviton is billed at a lower per-GB-second price AND typically runs faster, so you save on both the rate and the duration. For pure-runtime languages (Python, Node.js, Ruby, Java, .NET, Go) it's usually a one-line switch; only functions with compiled native dependencies need an arm64 build.
• AWS Fargate (ECS & EKS) — Fargate tasks can run on ARM64 by setting the CPU architecture in the task definition (ECS) or node/pod spec (EKS). The only prerequisite is that your container image is multi-arch (or arm64-native). This is the bridge between "managed flag" and "container rebuild" — easy once your image pipeline produces arm64.
• Other managed surfaces — EMR (Spark/Hadoop) supports Graviton instance groups; AWS Batch and managed Kubernetes node groups can schedule onto Graviton; CodeBuild offers ARM compute for your CI itself (which conveniently is also where you'll build your arm64 images). The pattern repeats: managed = pick the instance type.

IIIThe easy wins (flip a flag) vs the app recompile

Every credible Graviton plan sorts the estate into two buckets on day one: workloads where AWS already did the ARM port for you, and workloads where you own the binary and therefore own the rebuild. Confusing the two is how migrations stall — teams treat a one-flag RDS change like a risky platform migration, or treat a gnarly C-extension-heavy app server like a one-flag change.

The strategic takeaway for a cost program: the two buckets have completely different ROI-per-hour. Bucket 1 is near-free money — you should default new managed resources to Graviton and migrate the existing ones almost unconditionally. Bucket 2 is genuine project work, and the right answer is to prioritize the largest, longest-running, most homogeneous fleets first (a big stateless web tier behind a load balancer is the ideal first recompile target) and leave the long tail of small, weird, rarely-changed services for last — or never, if the saving doesn't justify the test burden.

IVWhat a Graviton migration actually takes (the EC2/container path)

For the managed-service flags there's little to plan beyond a maintenance window. For the self-managed compute path, here is the real checklist a partner (or your team) works through — it's methodical, not heroic, and almost all of the uncertainty is removed in the first two steps.

Run these in order. Steps 1–2 are discovery and tell you the true size of the job before you commit; steps 3–5 are the build, test, and rollout.

• 1. Dependency audit — Inventory every component that could be architecture-specific: base container images (is there an arm64/multi-arch tag?), language packages with native extensions (compiled wheels, node-gyp modules, JNI libraries), vendored or statically-linked binaries baked into images, and operational agents (monitoring, security, log shippers — confirm each ships an arm64 build). This audit converts "will it work on ARM?" from a question into a short, finite exceptions list.
• 2. Benchmark on your own traffic — Stand up a representative Graviton instance and replay real load. Measure latency (p50/p95/p99), throughput, and cost-per-unit-of-work — the last number is the one that justifies the project. This is also where you discover the right-size-down opportunity: if the Graviton box is loafing, drop a tier and bank a second saving. Never migrate on the brochure number alone; confirm the band on your workload.
• 3. Multi-arch build pipeline — Make your CI emit images that run on both amd64 and arm64 — typically a multi-arch manifest via Docker Buildx (often using arm64 CI runners, e.g. CodeBuild ARM, so you build natively rather than emulate). Multi-arch is what lets you cut over and roll back instantly: the SAME image tag runs on either architecture, so a Graviton node and an x86 node can sit in one fleet during the transition.
• 4. Functional + load testing on ARM — Run the full automated test suite against the arm64 build, then a soak/load test at production-like volume. You're hunting for two classes of issue: correctness (almost always a missed native dependency from step 1) and performance regressions (rare, but worth catching). Most well-tested services pass with zero code changes; the failures are dependency exceptions, not logic bugs.
• 5. Staged rollout with a rollback path — Introduce Graviton capacity gradually behind the load balancer or in the ASG/node group — start with a small percentage of mixed-architecture capacity, watch error rates and latency, then ramp. Because the image is multi-arch, rollback is just shifting the instance/capacity weighting back toward x86. Decommission the x86 capacity only once Graviton has held steady at full traffic.

VWhat the savings look like by service

Graviton savings come in two parts: a lower on-demand rate for the Graviton instance, and more work per dollar (so you sometimes also right-size down). The combined effect is the 20–40% price-performance band. Below is how that tends to land service by service — directional ranges, not quotes; always confirm against current AWS pricing and your own benchmark in Cost Explorer.

Two multipliers stack on top of everything below. (1) Commitments: a Graviton instance covered by a Savings Plan or Reserved Instance discounts again on top of the Graviton rate — for steady-state managed databases, Graviton + a 1- or 3-year RI is the deepest single discount available (see aws-savings-plans and aws-reserved-instances). (2) Right-sizing down: when the Graviton instance has spare headroom, dropping a size compounds the saving. The ranges below are the architecture switch alone, before those multipliers.

VIA rollout approach that captures the savings fast and de-risks the hard part

The optimal sequence is not "migrate everything." It's "take the free money immediately, then work the recompile fleet in priority order with a rollback path." Done this way, most of the dollar savings land in the first few weeks, while the engineering-heavy work proceeds at a safe pace.

A practical four-phase rollout:

• Phase 0 — Set the default — Make Graviton the default for all NEW resources from today: new RDS/ElastiCache/OpenSearch instances launch on *g classes, new Lambda functions deploy as arm64, new Fargate services target ARM64. This stops the problem from growing while you address the existing estate — a one-time policy decision with ongoing payoff.
• Phase 1 — Flip the managed services — Migrate existing RDS/Aurora, ElastiCache/MemoryDB, OpenSearch, and runtime-language Lambdas to Graviton. These are instance/architecture flags with brief maintenance windows and near-zero behavioral risk. This phase typically captures the majority of the total dollar savings and needs no application changes.
• Phase 2 — Build the multi-arch pipeline — Stand up arm64 CI and emit multi-arch images for the services you intend to move. This is the enabling investment for everything in Phase 3; once it exists, each subsequent service is cheaper to migrate. Move Fargate services to ARM64 here as their images go multi-arch.
• Phase 3 — Recompile the EC2 fleets, largest first — Work the self-managed compute in priority order: biggest, longest-running, most homogeneous fleets first (a large stateless web/API tier is the ideal lead). For each, run the dependency audit, test on ARM, and do a staged mixed-architecture rollout with rollback. Leave the small, weird, rarely-changed long tail for last — or skip it if the saving doesn't justify the test effort.

VIIA partner runs the migration — and it's frequently AWS-funded

The savings are real and durable, but the recompile path is a project, and most teams don't have a spare engineering quarter to run it cleanly. This is exactly the kind of well-scoped, measurable optimization that AWS funds through its partners — which is why a CloudRoute-matched partner is usually the fastest path to the savings, and frequently at no net cost to you.

CloudRoute routes you to a vetted AWS partner who has done Graviton migrations before. The partner runs the whole arc: a cost audit to size the prize, the dependency audit and benchmark, the multi-arch build pipeline, the staged cutover with a rollback plan, and the post-migration verification that the savings actually showed up in Cost Explorer. You get the price-performance gain without pulling your own team off the roadmap to build ARM CI and chase native-dependency exceptions.

The honest funding picture: AWS funds partner-led cost-optimization and Well-Architected engagements through its partner programs, and a Well-Architected Review can unlock remediation credits — so for qualifying, credit-eligible engagements you frequently cut the bill for $0: AWS funds the partner, the partner pays CloudRoute, and you never see an invoice. Where an engagement doesn't qualify for funding, it's a vetted-partner referral that pays for itself — a 20–40% price-performance gain on a meaningful slice of compute and database spend typically recovers the cost in the first month and compounds every month after. We won't pretend every engagement is free; we will make sure the math works before you commit.

If you want the broader cost picture, Graviton is one lever among several and works best alongside the others: commitments (aws-savings-plans, aws-reserved-instances) on the steady-state Graviton capacity, EC2 right-sizing to capture the drop-a-tier headroom, Spot for the interruptible portion of the fleet (ec2-spot-instances), and database-specific work (rds-cost-optimization). A Well-Architected Review (see /devops/aws-well-architected-review) is the usual front door, and if you're also early-stage and credit-hungry, the same partner motion overlaps with AWS credits — see /aws-credits/100k-aws-credits and the startup track at /for/startup.