AWS Savings Plans vs Reserved Instances: the enterprise buyer's commitment guide.
Compute Savings Plans, EC2 Instance Savings Plans and Reserved Instances all cut EC2 spend, but they trade discount depth against flexibility in different ways. This note benchmarks the discount curves by term and payment, maps the flexibility trade-offs, and sets out a coverage and laddering strategy — including how these self-service instruments interact with an AWS EDP.
There is no single best instrument. Compute Savings Plans trade a few points of discount for flexibility across EC2, Lambda and Fargate; EC2 Instance Savings Plans and Standard RIs reach up to 72% but lock you to a family, OS and region; Convertible RIs sit in the middle. The disciplined play is to ladder commitments over a conservative baseline — and to test whether an EDP beats stacking instruments before you commit.
01 Key findings
Flexibility is bought with discount, not for free. Compute Savings Plans flex across EC2, Lambda and Fargate at up to 66% (3-year, all-upfront); EC2 Instance Savings Plans and Standard RIs reach up to 72% but only for a fixed family, OS and region.
Term and payment move the curve more than instrument choice. One-year plans deliver 30–40%; three-year plans 50–66%+. All-upfront is deepest; partial-upfront costs 3–5 points, no-upfront a further 10–15.
The commitment is a floor, not a cap. A $10,000/hour Compute Savings Plan is an $87.6M three-year obligation you owe in full even if usage falls to $8,000/hour. Underspend cannot be returned or carried forward.
Size on evidence, not on AWS's growth model. A minimum 13-month usage review plus a conservative 10–20% buffer beats AWS "natural growth" projections, which systematically justify larger commitments.
Savings Plans apply before RIs in the billing hierarchy. Savings Plans first, then RIs, then on-demand — so layering instruments without an explicit workload map leads to paying commitments for spend that has shifted or been optimised away.
For the largest estates, an EDP may beat stacking. Above roughly $25M committed spend, a negotiated EDP can outperform Savings Plans plus RIs plus on-demand. EDPs are negotiable; console Savings Plan rates are not.
02 Discount & flexibility
Maximum discounts assume all-upfront payment. The pattern is consistent: the narrower the scope you lock, the deeper the discount — and the more a workload shift can strand the commitment.
| Instrument | 1-year | 3-year | Flexibility | Best for |
|---|---|---|---|---|
| Compute Savings Plan | 30–40% | 50–66% | Highest — EC2, Lambda, Fargate | Diverse compute portfolios |
| EC2 Instance Savings Plan | 35–45% | 55–72% | Moderate — same family, OS, region | Stable EC2-only workloads |
| Standard Reserved Instance | 30–40% | 50–72% | None — exact instance locked | Fixed, unchanging infrastructure |
| Convertible Reserved Instance | 20–30% | 35–54% | Moderate — exchange family, OS, region | Evolving architectures, long runway |
| On-demand | 0% | 0% | Complete | Dev, test, unpredictable workloads |
03 Discount depth
Peak discount off on-demand at three-year, all-upfront terms. The 6-point gap between an EC2 Instance Savings Plan and a Compute Savings Plan is the price of cross-family flexibility.
All-upfront is the deepest tier. Partial-upfront (typically 50% at signature, remainder monthly) costs 3–5 percentage points; no-upfront monthly costs a further 10–15. All-upfront is optimal only where capital-planning certainty exists to commit the cash at signature.
04 Instrument profiles
- One hourly $ commitment spans EC2, Lambda and Fargate
- Discount follows workloads across families and regions
- Survives re-architecture without stranding the commitment
- Up to 66% — roughly 6 points below locked instruments
- Excess over commitment bills at on-demand rates
- Underspend still owed in full
- Up to 72% — deepest Savings Plan tier
- Retains flexibility on size within the family
- Suits dedicated DB servers and long-running batch
- Locked to one family, OS and region
- m6i in us-east-1 cannot move to m7i or us-west-2
- EC2 only — no Lambda or Fargate coverage
- Standard RIs reach up to 72% for fixed workloads
- Convertible RIs exchange family, OS or region
- Apply to excess above a Savings Plan in the hierarchy
- Standard RIs have no flexibility; changes force a new buy
- Convertible RIs cap at ~54%, 18 points below Standard
- Superseded by Savings Plans for most new commitments
Ladder over a conservative baseline: commit only to the always-on floor of compute — sized at the 13-month average plus a 10–20% buffer — using Compute Savings Plans, then layer EC2 Instance SPs or RIs on the stable, workload-specific tranches above it. Staggering 1-year and 3-year expiries prevents a single cliff and preserves the option to re-price as usage and architecture evolve.
05 Coverage & laddering
Coverage is the share of eligible compute sitting under commitment. Chase 100% and you convert flexibility risk into overspend risk; run too low and you leave discount on the table. A worked layering example:
| Tranche | Instrument | Term | Rationale |
|---|---|---|---|
| Always-on baseline | Compute Savings Plan | 3-year, all-upfront | Deep discount on spend that will exist under any architecture |
| Stable DB / app fleet | EC2 Instance SP or Standard RI | 3-year | Extra depth where family, OS and region are fixed |
| Growing / uncertain | Compute SP or Convertible RI | 1-year | Preserve exit and re-pricing as workloads evolve |
| Spiky / discretionary | On-demand | None | Absorb variability rather than commit to a floor |
Map every tranche to named applications, databases and environments, and revisit the map quarterly. Layering instruments without explicit workload mapping is the most common route to paying commitments for spend that has migrated, been optimised or decommissioned.
06 Commitment risk
The largest source of regret we observe is over-commitment relative to real usage. A $10,000/hour Compute Savings Plan is a $87.6M three-year obligation ($10,000 × 24 × 365 × 3). Optimise your infrastructure or grow slower than planned, and you still owe the full amount — the unused portion cannot be returned or carried forward.
Size at the 13-month average compute spend plus a conservative 10–20% buffer, not at AWS's "natural growth" projection — those models systematically overestimate need to justify larger commitments. Use Cost Explorer to pull month-by-month on-demand consumption by service, and build a 5–15% growth model tuned to your industry.
07 Selection framework
Four questions decide which instrument fits which tranche of spend. Answer them per workload group, not for the estate as a whole.
Usage predictability
Only baseline spend that will exist under any plausible architecture belongs on a 3-year commitment. Everything above the reliable floor should stay shorter-term or on-demand.
Architectural stability
Fixed family, OS and region favours EC2 Instance SPs or Standard RIs. Active re-architecture favours Compute SPs or Convertible RIs to keep the discount portable.
Payment posture
All-upfront is deepest but ties up cash at signature. Weigh the 3–5 and 10–15 point step-downs of partial and no-upfront against your capital-planning certainty.
Scale & deal authority
Above ~$25M committed spend, model an EDP against stacked instruments. Service-specific discounts can add 5–15 points on top for high-consumption services.
08 Our recommendation
Cover the always-on baseline of a diverse or evolving estate. Accept the ~6-point discount haircut in exchange for a commitment that survives re-architecture across EC2, Lambda and Fargate.
Layer EC2 Instance SPs or Standard RIs on stable, long-lived fleets where family, OS and region will not change, to capture the deepest 72% tier. Choose Convertible RIs when you need exchange rights on a long runway.
Above ~$25M, take the analysis off the console. A blended EDP across all services is negotiable where console rates are not — and may beat stacking Savings Plans, RIs and on-demand.
09 Interaction with EDP
AWS applies discounts in a fixed order — Savings Plans first, then Reserved Instances, then on-demand — which means a Savings Plan can pre-empt an EDP and leave you paying more than the EDP alone would have. The choice is not always to stack:
Coordinate Recommended
Model Savings Plans and RIs against a blended EDP before committing. For predictable baseline compute, commit; for discretionary spend, keep flexibility and let the EDP carry it. Negotiate a net-price cap so a fixed discount is not eroded by list-price rises.
Stack blindly Weaker
Buy Savings Plans, then RIs, then negotiate an EDP separately. The billing hierarchy can strand the EDP behind existing commitments, and uncoordinated layers pay for workloads that have already shifted.
Size and coordinate your AWS commitments
Our Cloud & FinOps practice benchmarks Savings Plan and RI sizing, ladders coverage, and coordinates them with EDP and private pricing.
The Licensing Edge
Weekly cloud and licensing intelligence for enterprise IT leaders. 3,000+ subscribers.