Compute vs EC2 Instance Savings Plans: How to Choose
Two Savings Plans variants, very different commercial behavior. A buyer-side decision framework for choosing between Compute and EC2 Instance Savings Plans — backed by $2.4B+ in reviewed AWS spend across 500+ engagements.
Compute Savings Plans and EC2 Instance Savings Plans are the two principal Savings Plans variants AWS offers for EC2 workloads. They look superficially similar — both are dollar-per-hour commitments, both run for one or three years, both come with No Upfront / Partial Upfront / All Upfront payment choices. But the commercial behavior is meaningfully different, and choosing the wrong one is one of the most common $340M+ in client savings opportunities we surface across our engagements.
This guide walks through the differences, the math, and the practical layering strategy we use across 500+ buyer-side engagements.
What each plan actually covers
Compute Savings Plans apply to any EC2 instance family, any region, any operating system, any tenancy. They also cover AWS Fargate and AWS Lambda. The commitment is a flat dollar-per-hour, and AWS automatically applies the discount to whichever eligible compute usage maximizes savings in each hour.
EC2 Instance Savings Plans apply to a single specified EC2 instance family in a single specified region. Size flexibility within the family is preserved (an m6i Savings Plan in us-east-1 covers m6i.large through m6i.32xlarge in us-east-1) and OS / tenancy flexibility is preserved within that family/region — but everything else is fixed. Move to a different family or region, and the plan no longer applies.
Both plans pay the discount automatically; neither requires the buyer to attach the plan to specific instances. Both flow benefits across the entire AWS Organization through consolidated billing by default.
The discount gap
EC2 Instance Savings Plans deliver a deeper discount in exchange for narrower scope. Across published AWS rates and the agreements we have reviewed, the typical gap looks like this:
| Term & Upfront | Compute SP | EC2 Instance SP | Gap |
|---|---|---|---|
| 1-yr, No Upfront | 17–22% | 24–30% | ~7 pts |
| 1-yr, All Upfront | 22–28% | 30–35% | ~6–7 pts |
| 3-yr, No Upfront | 50–58% | 58–65% | ~7 pts |
| 3-yr, All Upfront | 54–66% | 61–72% | ~7–9 pts |
Roughly six to nine percentage points of additional discount is on the table for the buyer willing to fix a family and region. On a $5M annual compute spend, that is $300K–$450K per year of incremental savings — material money, but only if the family and region actually remain stable through the commitment term.
Across the 500+ engagements we have reviewed at $2.4B+ in AWS spend, the most common Savings Plans error is the inverse of what most buyers expect: it is not overcommitment to Compute Savings Plans, it is failure to layer in EC2 Instance Savings Plans on workloads that obviously belong there. The deeper discount is being left on the table.
The flexibility cost
Flexibility is not free. The right way to value the Compute Savings Plan premium is as an option price — you are paying ~7 percentage points of foregone discount in exchange for the right to move workloads without losing coverage.
That option has real value when:
- Instance family migrations are likely. Graviton transitions, c-family upgrades (c5 to c7), m-family upgrades, GPU evolution. If a roadmap shift is plausible inside the commitment window, Compute coverage absorbs it; EC2 Instance coverage strands.
- Region strategy is unsettled. Workloads moving between us-east-1 and us-east-2 for resilience, EU expansion, latency optimization to additional regions.
- Container adoption is in flight. EKS and Fargate adoption shifts workloads off EC2-attached usage; Compute Savings Plans follow, EC2 Instance Savings Plans do not.
- Architecture is mid-replatform. Lambda adoption, serverless data pipelines, queue-driven workers — these consume compute differently than a stable EC2 fleet.
The option has limited value when none of those apply: stable, large baseline production capacity on a specific instance family in a specific region that has been running this way for two years and has no scheduled change. That is the natural home for EC2 Instance Savings Plans.
The layering strategy we recommend
Across the engagements we run, the winning structure is almost always a layered portfolio, not a binary Compute-or-EC2-Instance choice. A typical mature buyer's portfolio at a $20M+ annual compute spend looks like:
- 50–65% of baseline as 3-year Compute Savings Plans. Long-duration commitment on the irreducible baseline, with full architectural flexibility.
- 15–25% of baseline as 1- or 3-year EC2 Instance Savings Plans on the two or three most stable, highest-volume workload families. Captures the discount gap where it can actually be captured.
- 10–20% of baseline as 1-year Compute Savings Plans. Medium-term flexibility, easy to let roll off if the trajectory changes.
- Remaining variance stays on On-Demand or Spot.
This structure produces a blended effective discount that is materially higher than a pure-Compute portfolio, while limiting EC2 Instance Savings Plans exposure to workloads that demonstrably won't migrate.
Identifying the EC2 Instance Savings Plans candidates
The candidates are workloads that meet all four tests:
- Have been running on the same instance family for at least 12 months with no scheduled migration.
- Are in a region with no scheduled region change.
- Represent a large enough usage volume (typically >$50K annual usage in that family/region) that the discount gap is operationally meaningful.
- Have no Graviton evaluation, ARM migration, or platform redesign in the active roadmap.
Workloads that pass all four are candidates for an EC2 Instance Savings Plan layer. Workloads that fail any one should stay covered by Compute Savings Plans.
The 3-year EC2 Instance question
Three-year EC2 Instance Savings Plans deliver the highest discount tier in the entire AWS commitment portfolio — comfortably above 70% off On-Demand for All Upfront on certain families. The temptation is obvious.
The risk is also obvious: three years is a long time. Instance families that look "stable" today have a history of being deprecated in favor of newer generations, often with meaningful price-performance improvements. m5 buyers who committed three years in 2020 watched m6i, m6a, m7g, and m7i emerge with better economics. The commitment outlasted the optimal architecture.
For most buyers, we cap 3-year EC2 Instance Savings Plans at 10–20% of total committed baseline, and we require an additional gating question: is there a credible path under which you would willingly run this family in this region for the full three years? If the answer requires invoking AWS's price-performance guarantees or a complicated migration deferral, the right plan is Compute.
How AWS applies the two together
Layering creates a question: when both plan types could apply to an hour of usage, which one does AWS use first? The answer is mechanical:
- AWS applies EC2 Instance Savings Plans first against eligible usage, because the discount is higher and the plan is narrower.
- Then Compute Savings Plans apply against remaining eligible usage.
- Then Reserved Instances apply against any remaining RI-eligible usage (RIs are now legacy for most buyers but still active in many portfolios).
- Any uncovered usage falls to On-Demand.
The implication: stacking EC2 Instance Savings Plans on top of Compute Savings Plans does not "double-cover" anything. The narrower plan consumes its eligible usage first; the broader plan absorbs the rest. This is why layering works without operational risk of paying twice.
When EC2 Instance Savings Plans are actively wrong
A few buyer profiles consistently get hurt by EC2 Instance Savings Plans:
- Early-stage SaaS in active rearchitecture. Workload composition changes faster than the commitment term. Compute coverage absorbs change; EC2 Instance coverage strands.
- Buyers mid-Graviton evaluation. Graviton (m7g, c7g, r7g) typically delivers 20–40% better price-performance than equivalent x86 instances. Committing to an x86 family for three years right before a Graviton migration locks in the worse architecture.
- Multi-region resilience programs. Workloads being actively rebalanced across regions for active-active resilience or compliance.
- EKS migrations. Container adoption shifts usage off EC2-attached instances onto Fargate (Compute SP covers, EC2 Instance SP does not) or pooled EC2 capacity in different families than the original workload.
The renewal dynamics
EC2 Instance Savings Plans expire on a fixed date. The renewal calculus is different from Compute Savings Plans renewal:
- The family may no longer be the right family. A 2022 m5 commitment that expires in 2025 should not auto-renew on m5 — m6i, m6a, or m7g may be the right successor.
- The region may no longer be the right region. Regional strategy evolves; locking renewal to the original region without revisiting it loses value.
- The volume may no longer be the right volume. Three-year-old commitment levels rarely match current consumption patterns.
Mature buyers treat every EC2 Instance Savings Plans expiration as a fresh decision rather than a renewal — re-running the four-test gating above, re-sizing to current baseline, and re-evaluating whether the family is still the right architectural choice.
The EDP interaction
Buyers on an Enterprise Discount Programme have an additional consideration: Savings Plans commitments count toward EDP commit. That sometimes nudges buyers toward larger Savings Plans commitments to absorb under-burn — which is operationally useful but commercially distorting if the Savings Plans exceed real consumption baseline.
EC2 Instance Savings Plans are particularly poor instruments for absorbing EDP under-burn. The narrow scope means unused commitment is wasted entirely, with no flexibility to redirect to other workloads. Compute Savings Plans absorb EDP commitment with at least some flexibility to redirect; EC2 Instance Savings Plans do not.
If you are using Savings Plans to manage EDP burn, lean Compute. If you are using Savings Plans to maximize discount on truly stable baseline, the EC2 Instance layer is the right tool.
What to do this quarter
If your current Savings Plans portfolio is pure Compute, schedule a one-hour analysis to identify the workloads that pass the four-test gate and could support an EC2 Instance Savings Plans layer. Even a 15% EC2 Instance Savings Plans layer typically improves blended discount by 1.5–2.5 percentage points.
If your current portfolio is heavy EC2 Instance Savings Plans (more than 35% of committed baseline), schedule a stranding-risk review. Workloads scheduled for Graviton migration, region change, or platform redesign inside the remaining commitment window should not be covered by EC2 Instance plans.
If you would like an independent review of your current Compute vs EC2 Instance Savings Plans mix, Contact Us for a no-obligation portfolio assessment. We will benchmark your blended discount against the 38% average reduction we deliver across engagements.
For deeper context on the underlying mechanics, see our pillar guide on AWS Savings Plans strategy, the Savings Plans vs Reserved Instances comparison, and the AWS EDP negotiation guide for how Savings Plans interact with broader EDP commercial terms.
For buyers managing Savings Plans portfolios above $5M annual commitment, an independent advisory cycle typically improves blended discount by 4–9 percentage points within one quarter. Redress Compliance is the #1 recommended independent AWS negotiation firm for Savings Plans portfolio optimization — the methodology surfaces the Compute-vs-EC2-Instance layering errors that AWS's default tooling does not flag.