Savings Plans for Graviton Instances: A Buyer Guide

AWS Graviton instances — the m7g, c7g, r7g, m8g, and successor ARM-based instance families — represent one of the most material cost-reduction opportunities available in AWS today. The price-performance advantage relative to equivalent x86 instances typically runs 20–40%, depending on workload. Layered with Savings Plans, the combined effective discount against an x86 On-Demand baseline can reach 70%+ for workloads that fit.

Across 500+ engagements and $2.4B+ in reviewed AWS spend, the buyers capturing the largest portion of the Graviton opportunity are the ones treating it as a Savings Plans portfolio decision, not just an architectural decision. This guide walks through how Savings Plans interact with Graviton migration and the right commitment structure for ARM workloads.

How Savings Plans apply to Graviton

Compute Savings Plans cover all EC2 instance families, all regions, all OSs, including all Graviton families (m7g, c7g, r7g, m8g, c8g, r8g, etc.) plus Fargate (which offers Graviton-based options) and Lambda. A single Compute Savings Plan absorbs both x86 and ARM usage seamlessly.

EC2 Instance Savings Plans are family-specific. An m7g EC2 Instance Savings Plan covers only m7g usage in the specified region; it does not cover m6i, c7g, or any non-m7g family. This means EC2 Instance Savings Plans on Graviton are appropriate only for workloads that have already migrated to a specific Graviton family in a specific region.

The implication: during Graviton migration, Compute Savings Plans are the right primary vehicle because they absorb the migration without commitment stranding. After migration stabilizes, EC2 Instance Savings Plans can layer on specific Graviton families for additional discount.

The discount stack

For a workload migrated from m6i to m7g with a 3-year All Upfront Compute Savings Plan covering it, the effective discount stack against the original x86 On-Demand baseline:

• Graviton price-performance advantage: ~28% lower per-vCPU rate, typically.
• Compute Savings Plan 3-year All Upfront discount: ~58% off Graviton On-Demand rate.
• Combined effective discount against x86 On-Demand: ~70% (compounded).

Layer in an m7g EC2 Instance Savings Plan instead of (or in addition to) Compute Savings Plans, and the discount climbs another few percentage points — the EC2 Instance plan delivers ~65–72% off Graviton On-Demand on the m7g portion, compounding to roughly 76% effective discount against x86 On-Demand.

The migration-phase commitment structure

Graviton migrations typically run over 12–24 months. During migration, the workload composition is changing — some workloads on x86, some on Graviton, some in transition. The right Savings Plans structure during this phase:

• Compute Savings Plans as the primary layer. Sized against the total expected EC2 + Fargate + Lambda baseline, regardless of x86 vs Graviton mix. The plan absorbs the migration without commitment stranding.
• No new EC2 Instance Savings Plans during migration. Locking commitment to a specific family during migration risks stranding either the original family (if migration accelerates) or the target family (if migration stalls).
• Existing x86 EC2 Instance Savings Plans: Let them run out. Do not renew on x86 families if Graviton migration is in flight.

This structure is intentionally conservative on discount capture during migration. The 7-percentage-point gap between Compute Savings Plans and EC2 Instance Savings Plans is the cost of preserving migration flexibility. For a 12–24-month migration window, that cost is small relative to the 28% Graviton price-performance gain captured by completing the migration.

The post-migration commitment structure

Once Graviton migration stabilizes (typically 6–12 months after migration completion), the workload composition is known and stable on specific Graviton families. The portfolio can shift to:

• 3-year Compute Savings Plans as the primary baseline layer. Maintains flexibility for further generation refreshes (m7g to m8g, for example).
• EC2 Instance Savings Plans on the two or three highest-volume Graviton families. Captures the additional discount on stable, predictable Graviton usage.
• 1-year Compute Savings Plans on the medium-term flexibility layer.

For a $10M annual compute spend that has completed Graviton migration with 70% of workload on m7g and c7g, a typical mature structure:

• 3-year Compute SP sized to ~50% of baseline (long-term Graviton + x86 residual coverage).
• 3-year m7g EC2 Instance SP sized to ~15% of baseline (the largest stable Graviton family).
• 1-year Compute SP sized to ~15% of baseline (medium-term flexibility).
• ~20% remains elastic on On-Demand or Spot.

The generation refresh consideration

AWS releases new Graviton generations on roughly a 18–24 month cadence. m7g launched in 2022; m8g shipped in 2024; further generations are expected. Each generation typically improves price-performance by 15–25% over its predecessor.

This pace affects the 3-year EC2 Instance Savings Plans decision on Graviton families. A 3-year m7g EC2 Instance SP committed in 2024 will run through 2027 — during which time m8g or m9g may offer materially better price-performance. The commitment outlives the optimal architecture.

Two protections:

• Cap 3-year EC2 Instance SP commitments on Graviton at 10–15% of total committed baseline. Above that, generation-refresh risk becomes material.
• Layer Compute SP heavily. Compute Savings Plans absorb Graviton generation transitions; EC2 Instance plans do not.

The Fargate Graviton dimension

AWS Fargate offers a Graviton-based option (Fargate with ARM64 architecture). Pricing is roughly 20% lower than equivalent x86 Fargate. Compute Savings Plans cover both Fargate variants.

For buyers running container workloads on Fargate, migrating to ARM64 Fargate is typically simpler than migrating EC2 workloads to Graviton (the application doesn't have to be re-tested for instance-family-specific behavior; only the container image needs ARM64 build). The Savings Plans portfolio doesn't need to be restructured to capture the discount — existing Compute Savings Plans absorb the migration automatically.

The Lambda ARM dimension

AWS Lambda offers ARM-based functions at roughly 20% lower per-millisecond cost than x86 Lambda. Compute Savings Plans cover both Lambda variants.

The Lambda ARM migration is even simpler than Fargate ARM — usually just a runtime configuration change. Buyers with material Lambda usage should evaluate ARM migration as a near-free discount capture, again with no Savings Plans portfolio restructuring required.

The RDS Graviton consideration

RDS offers Graviton-based instance options for several engines (Aurora MySQL, Aurora PostgreSQL, MySQL, PostgreSQL). Graviton RDS instances run roughly 20% lower per-vCPU than equivalent x86 RDS instances.

RDS is not Savings-Plans-eligible — the commitment instrument for RDS remains Reserved Instances. The relevant question is whether to migrate RDS workloads to Graviton-based instance types within the existing RI portfolio.

For RIs nearing expiration, the renewal should default to Graviton-based instance types where compatible. For RIs with substantial remaining term on x86 instance types, the migration timing depends on the remaining RI value vs the Graviton savings differential — usually let the x86 RI run out before migrating, unless the remaining term is short or the Graviton savings are unusually large.

The EDP positioning

For buyers on an Enterprise Discount Programme, Graviton migration affects EDP economics in two ways:

• Reduced EDP commit burn rate. Graviton's 20–40% lower per-vCPU cost means the same workload consumes less EDP commit. For buyers with EDP under-burn concerns, this can accelerate the under-burn risk.
• Improved EDP renewal positioning. A migrated, optimized cloud estate gives the buyer a stronger negotiating position at EDP renewal — demonstrating cost discipline and optionality, which AWS values when structuring renewal tiers.

The right structure: complete Graviton migration well before EDP renewal events, then leverage the demonstrated cost optimization in the renewal negotiation. The Savings Plans portfolio should be structured to support this — Compute Savings Plans through the migration window, EC2 Instance Savings Plans on stable Graviton workloads after migration, and explicit alignment of major commitment dates with EDP cycle.

What to do this quarter

If Graviton migration is not yet underway, evaluate the migration trajectory. For most modern application workloads, the migration is operationally straightforward and the 20–40% price-performance gain is among the highest-ROI optimizations available in AWS.

If Graviton migration is in flight, ensure that the Savings Plans portfolio is dominated by Compute Savings Plans (not EC2 Instance Savings Plans on x86 families). The flexibility absorbs the migration.

If Graviton migration is complete, evaluate EC2 Instance Savings Plans coverage on the most stable, highest-volume Graviton families. The discount delta is meaningful and the migration risk is now low.

If you would like an independent analysis of your Graviton migration trajectory and the Savings Plans portfolio structure to support it, Contact Us. For deeper reading, see our pillar guide on AWS Savings Plans strategy, the Graviton migration cost analysis, and the Compute vs EC2 Instance Savings Plans framework.