Savings Plans vs Reserved Instances in 2026: When to Use Each

AWS commitment discounts can take 30-72% off your bill. The question is which type to buy and for how long. Here's the framework I use on every audit.

By Andrii Votiakov on 2026-03-07

Commitment discounts are the single biggest lever after right-sizing. Done well, they take 30-50% off compute and managed-service spend. Done poorly, you've locked yourself into a fleet you don't actually need for three years. The decision tree is simple once you've seen it. Always right-size first — the EC2 right-sizing 14-day method gives the exact procedure. For database spend, RDS Reserved Instances follow their own rules, and Graviton migration should usually be done before committing so you're buying discounts on the cheaper architecture. If you're on Azure, the equivalent guide is Azure Reservations and Savings Plans.

Quick answer

For most teams in 2026, 1-year Compute Savings Plans are the right default for EC2/Fargate/Lambda. Buy EC2 Instance Savings Plans only if you're locked into a specific instance family. Buy RDS Reserved Instances for steady-state databases. Don't buy 3-year anything unless your business is extremely stable.

What's available

Type Covers Discount range Flexibility
Compute Savings Plan EC2, Fargate, Lambda (any region, any family, any size) 30-66% Highest
EC2 Instance Savings Plan EC2 in one family, one region 35-72% Locked to family
RDS Reserved Instance RDS in one engine, family, region 40-60% Locked to engine + family
ElastiCache RI ElastiCache in one node type 35-55% Locked to node type
OpenSearch RI OpenSearch instances 30-50% Locked to type
Redshift RI Redshift nodes 20-75% Locked to node type

Compute SP and EC2 SP cover Lambda and Fargate regardless of family choice. RIs are still the only commitment vehicle for RDS, ElastiCache, OpenSearch and Redshift.

The decision tree

1. Are you fully right-sized?

If no, stop. Don't commit to a fleet you're about to shrink. Right-size first, run the new shape for two weeks, then commit.

2. How stable is your usage?

Pull the last 90 days of compute hours. Look at the floor — the lowest you ever ran. That's your safe commitment level.

  • Floor stable within ±10% over 90 days → safe to commit to that floor
  • Floor swinging ±25% → commit to a more conservative number, say 60-70% of the floor
  • Floor changing rapidly because product is growing → commit to a smaller fraction; you'll buy more later

3. 1-year or 3-year?

3-year buys you another 7-15% on the discount. The cost: you can't easily walk away. My rules:

  • Pre-revenue or rapid-growth startup: 1-year only. Things change too fast.
  • Stable mid-market SaaS: mostly 1-year, maybe 3-year on rock-solid steady-state databases.
  • Mature enterprise with predictable workloads: 3-year is fine on the deepest base layer.

4. All-upfront, partial-upfront, or no-upfront?

All-upfront gets you the deepest discount but ties up cash. Partial-upfront is a sensible middle. No-upfront still beats on-demand by 25-50% with no cash impact.

For most clients I recommend partial-upfront — small enough cash hit to be approved without escalation, deepest practical discount.

5. Compute SP or EC2 Instance SP?

Compute SP is the safe default. It moves with you across regions and families. EC2 Instance SP is 5-10 percentage points cheaper, but only if you're certain you'll keep using that family for the entire term.

Buy EC2 Instance SP when:

  • You're committed to Graviton (m7g/c7g/r7g) and there's no reason to leave
  • The instance type is for a stable known workload (e.g., legacy app on m5.large)

Otherwise, Compute SP.

Practical buying rules

  1. Buy in tranches. Don't commit your whole fleet on day one. Start with 50-60% of your 90-day floor, leave headroom.
  2. Always-on workloads only. SP/RI economics break for workloads you turn off at night.
  3. Spot fills the volatile top. Spot doesn't get RI/SP discounts but gets 60-90% off on-demand directly.
  4. RDS is always 1-year for me. Database fleet shapes change. 3-year RDS RI is too long for most companies.
  5. Buy RIs for ElastiCache and OpenSearch only after you've right-sized them. Same logic as EC2.
  6. Convert standard RIs to convertible only if you're uncertain. Convertible RIs can be exchanged but at a smaller discount. Worth it for unstable shapes.

Common mistakes

  • Buying SP based on current fleet, not floor. If you've grown 30% in the last quarter, buying SP at current usage means you've under-committed. Use the floor.
  • Stacking SP on top of RI. RIs apply first, SP fills the gap. If you have RIs, only buy SP for the uncovered portion.
  • 3-year SP on a startup that pivots. Seen it more than once. Six months later the fleet looks completely different and the SP is being wasted.
  • Forgetting Lambda and Fargate. Compute SP covers both. If your Lambda bill is over a few hundred a month, this matters.

What it looks like on a real bill

Recent example (~$48k/month before commitments):

  • Right-sized fleet: $36k/month on-demand
  • 1yr Compute SP partial-upfront covering 65% of floor: −$8.4k/month
  • 1yr RDS RI partial-upfront covering 80%: −$3.6k/month
  • 1yr ElastiCache RI: −$700/month

Final: $23.3k/month, 51% reduction vs the starting bill.


If you want help running the buy plan for your account — including a coverage report and tranche schedule — book a call.