Back to blog
·6 min read

Reserved Instances vs Savings Plans: When to Use What

Both cut your AWS compute bill by up to 72% — but pick the wrong one and you're locked into something that doesn't fit. A concise breakdown of when to use Reserved Instances, EC2 Savings Plans, and Compute Savings Plans.

AWSCost OptimizationFinOpsDevOps

Both Reserved Instances and Savings Plans exist to do the same thing: reduce your AWS compute bill in exchange for a 1 or 3-year commitment. Both can cut costs by up to 72% compared to On-Demand. The difference is in what you're committing to — and that determines which one fits your workload.

The Core Difference

Reserved Instances (RIs) commit to a specific instance type in a specific region. You're saying: "I will run an m5.xlarge in us-east-1 for the next year." In return, AWS gives you the deepest possible discount.

Savings Plans commit to a spend amount per hour — not to a specific instance. You're saying: "I will spend at least $X/hr on compute for the next year." AWS applies the discount automatically to whatever compute you actually run.

The tradeoff: RIs are less flexible but can offer a slightly higher discount on EC2 and RDS. Savings Plans are more flexible and cover services RIs never will.

Reserved Instances vs Savings Plans — coverage comparison across EC2, RDS, Fargate, and Lambda
Reserved Instances vs Savings Plans — coverage comparison across EC2, RDS, Fargate, and Lambda

The Three Options Compared

Standard RIEC2 Savings PlanCompute Savings Plan
**Max discount**Up to 72%Up to 72%Up to 66%
**Commitment**Instance type + regionSpend/hr, one regionSpend/hr, any region
**Covers EC2**Yes (exact family)Yes (any family)Yes (any family)
**Covers RDS / Aurora**YesNoNo
**Covers Fargate**NoNoYes
**Covers Lambda**NoNoYes
**Can sell unused**Yes (Marketplace)NoNo
**Flexibility**LowMediumHigh

The key insight on RDS: Savings Plans do not cover RDS or Aurora. If you have predictable database workloads, Standard RIs are still the right tool — there is no Savings Plan equivalent for managed databases.

Decision Guide

RI vs Savings Plans Decision Guide — choose based on compute type and usage stability
RI vs Savings Plans Decision Guide — choose based on compute type and usage stability

Use Standard Reserved Instances when: - You have stable EC2 or RDS usage — same instance type, same region, 1+ years - You need the maximum possible discount and flexibility is not a concern - You run RDS or Aurora and want to reduce that specific cost

Use EC2 Instance Savings Plans when: - Your workload is EC2-only but you might change instance families (e.g., m5 to m6i) - You want near-RI discounts without being locked to a specific instance type - Your compute is region-specific but not instance-family-specific

Use Compute Savings Plans when: - Your stack includes Fargate, Lambda, or both - You run workloads across multiple regions - Instance types change frequently or traffic is unpredictable enough that you want flexibility over max discount - You're moving from EC2 to serverless — Compute SP covers the transition period

Stay On-Demand when: - Usage is genuinely unpredictable and short-lived (experiments, burst workloads) - You're in the first few months of a new product and don't know your baseline yet

How to Size Your Commitment

The most common mistake: buying RIs or Savings Plans to cover 100% of current usage. Don't.

Target 70–80% coverage. Your baseline steady-state usage should be commitment-covered. The remaining 20–30% — spikes, experiments, scaling events — stays On-Demand. This prevents over-committing on capacity you end up not needing.

Check your current coverage in Cost Explorer:

# Check Savings Plans coverage (last 30 days)
aws ce get-savings-plans-coverage \
  --time-period Start=2026-02-24,End=2026-03-26 \
  --granularity MONTHLY \

# Check RI coverage for EC2 aws ce get-reservation-coverage \ --time-period Start=2026-02-24,End=2026-03-26 \ --granularity MONTHLY \ --group-by Type=DIMENSION,Key=INSTANCE_TYPE `

If coverage is below 60%, you're leaving significant savings on the table. If it's above 85%, you may be over-committed.

Payment Options

Both RIs and Savings Plans offer three payment options:

  • All Upfront — highest discount, pay the full 1 or 3-year cost today
  • Partial Upfront — mid-tier discount, pay some now and the rest monthly
  • No Upfront — lowest discount, pay monthly (still cheaper than On-Demand)

The break-even for All Upfront vs No Upfront is typically 7–8 months. If you're confident about the commitment, All Upfront pays for itself before the year is out.

For 3-year terms: the discount jump from 1-year to 3-year is meaningful (~10–15% additional), but only commit to 3 years if you're certain about the workload. Architectures change.

Practical Starting Point

If you're new to this and don't know where to start:

  1. Run Cost Explorer for 30 days and look at your Savings Plans → Recommendations tab — AWS calculates exactly how much you'd save based on your actual usage
  2. Start with a Compute Savings Plan at No Upfront — lowest risk, most flexibility, still 40–60% cheaper than On-Demand
  3. After 2–3 months of stable usage, revisit with All Upfront or a mix of RI + Savings Plans
# Get AWS's own recommendation for Savings Plans
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days THIRTY_DAYS

This returns a specific hourly commitment amount and the estimated annual savings — no guesswork required.

Quick Reference

ScenarioUse
Steady EC2 + RDS, fixed instance typeStandard RI
EC2 only, might change instance familyEC2 Savings Plan
EC2 + Fargate + Lambda, mixed regionsCompute Savings Plan
Unpredictable or short-lived workloadsOn-Demand
Don't know yetCompute SP, No Upfront, 1 year

Commitments are not set-and-forget — review coverage quarterly. Usage patterns change, and what was optimal 6 months ago may not be today.