AWS Savings Plans vs Reserved Instances: Which Saves More?

If you run steady compute on AWS, committing to it instead of paying on-demand is the single biggest lever on your bill, discounts reach up to roughly 72%. The question is how to commit: Savings Plans or Reserved Instances? For most teams in 2026, the answer is Savings Plans, but not always. Here's how to choose.

Short answer: Use a Compute Savings Plan for flexible, broad coverage of your steady-state compute. Consider Reserved Instances mainly for specific managed services (like RDS/ElastiCache/Redshift) or when you want capacity reservation.

The two commitment models

Savings Plans

You commit to a steady dollars-per-hour of usage for 1 or 3 years. In return you get discounted rates.

Compute Savings Plans, the most flexible. The discount automatically applies across EC2, Fargate, and Lambda, regardless of instance family, size, OS, tenancy, or Region. Up to ~66% off.
EC2 Instance Savings Plans, deeper discount (up to ~72%) but locked to a specific instance family in a Region.

Reserved Instances (RIs)

You commit to specific instance attributes (family, Region, sometimes size) for 1 or 3 years. Standard RIs give the deepest discount but little flexibility; Convertible RIs trade some discount for the ability to change attributes. RIs can also provide a capacity reservation in a specific AZ, something Savings Plans don't do.

Side by side

	Compute Savings Plan	Standard RI
Max discount	~66%	~72%
Flexibility	High (family, size, Region, Fargate, Lambda)	Low (locked attributes)
Capacity reservation	No	Optional (zonal RIs)
Covers Fargate/Lambda	Yes	No
Management overhead	Low	Higher (track expiries/usage)

How to decide

Find your steady-state baseline. Look at the floor of your compute usage over the last 30 to 90 days, the amount that's always running. Commit to that, not your peak. Burst above the baseline stays on-demand.
Default to a Compute Savings Plan for that baseline. The flexibility means you keep the discount even as you change instance types or shift to Fargate/Lambda, which most teams do over a 1 to 3 year horizon.
Use RIs for managed databases. Savings Plans don't cover RDS, ElastiCache, OpenSearch, or Redshift, those use Reserved Instances/Nodes. If you run steady databases, reserve them.
Reach for zonal RIs only when you need guaranteed capacity in a specific AZ (e.g., for failover headroom).
Prefer 1-year to start. Three-year terms discount more but assume you can predict usage that far out. Many teams ladder commitments instead.

The most common mistake

Over-committing. Teams commit to peak usage, then pay for a commitment they don't fully use. Commit conservatively to your baseline; you can always add more coverage later. Aim for high utilization of whatever you buy.

A right-sized Compute Savings Plan on a steady fleet typically trims 20 to 30% off compute spend with almost no operational change, just a purchase decision.

Not sure what your baseline is?

That's exactly what a cost review surfaces. The free AWS Cost Checkup reads your cost export and flags commitment gaps; or book a free consultation and we'll size it together.

Discount percentages are approximate and vary by term, payment option, and Region, confirm current numbers in the AWS Cost Management console.