Reserved Instances vs Savings Plans: Which Saves More in 2026?
If you run steady compute on AWS, paying On-Demand rates for it is leaving 30–70% on the table. The two ways to capture that discount are Reserved Instances (RIs) and Savings Plans. They sound interchangeable, and the AWS docs don’t make the choice obvious.
Here’s a plain comparison: how each works, which saves more, and how to commit without painting yourself into a corner.
The core trade
Both RIs and Savings Plans give you a discount in exchange for committing to a steady level of usage for 1 or 3 years. The deeper the commitment (longer term, more upfront payment), the bigger the discount. The risk is the same with both: commit to more than you use and you pay for capacity you don’t need.
The difference is flexibility.
How Reserved Instances work
An RI is a commitment to a specific instance configuration. There are two flavors:
- Standard RIs: biggest discount (up to ~72%), but locked to an instance family. You can modify some attributes but not switch families freely.
- Convertible RIs: smaller discount, but you can exchange them for different instance types later.
RIs apply to EC2 and also exist for RDS, ElastiCache, Redshift, and OpenSearch. The catch: they’re rigid. Change your instance family and a Standard RI can strand.
How Savings Plans work
Savings Plans commit you to a dollar amount of compute per hour (e.g. “$10/hour”) rather than a specific instance. Two types:
- Compute Savings Plans: most flexible. Apply across EC2, Fargate, and Lambda, any region, any instance family. Up to ~66% off.
- EC2 Instance Savings Plans: locked to an instance family in a region, slightly bigger discount (~72%).
Because Compute Savings Plans float across services and families, they keep saving even as your architecture changes.
Side-by-side
| Standard RI | Convertible RI | EC2 Savings Plan | Compute Savings Plan | |
|---|---|---|---|---|
| Max discount | ~72% | ~66% | ~72% | ~66% |
| Flexibility | Low | Medium | Medium | High |
| Covers Fargate/Lambda | No | No | No | Yes |
| Switch instance family | No | Yes (exchange) | No | Yes (automatic) |
| Best when | Stable, never-changing fleet | Slowly evolving fleet | Stable family, want simplicity | Changing or mixed workloads |
Which saves more?
At the same term and payment option, EC2 Instance Savings Plans and Standard RIs hit the deepest discounts, roughly the same. Compute Savings Plans give up a few points of discount for dramatically more flexibility.
So the honest answer: Standard RIs / EC2 Savings Plans save the most on paper, but Compute Savings Plans usually save more in practice because real fleets change, and the flexible option keeps applying its discount instead of stranding when you switch instance types.
How to commit without regret
The mistake teams make is over-committing. Avoid it:
- Cover only your baseline. Look at the last 30–60 days and find the floor of usage you’d run no matter what. Commit to that, not your peak.
- Start with 1-year, no-upfront. Lower discount, far lower risk. Graduate to 3-year only on rock-solid baselines.
- Default to Compute Savings Plans unless you have a large, genuinely static fleet that justifies squeezing the extra few points from Standard RIs.
- Layer commitments as confidence grows rather than making one big bet.
- Re-check coverage and utilization monthly. Unused commitment is just prepaid waste.
The decision in one line
- Static fleet you’ll never change → Standard RI / EC2 Savings Plan for max discount.
- Anything evolving, mixed, or serverless → Compute Savings Plan for flexibility that keeps paying off.
- Unsure → start with a conservative 1-year Compute Savings Plan on your baseline.
Know your baseline first
You can’t size a commitment you can’t see. Before buying anything, you need a clear read on steady-state usage, current coverage, and which resources are idle (committing to capacity that’s actually wasted is the worst outcome).
Graymole gives you that picture in a read-only pass, surfacing idle and oversized resources so you right-size before you commit, and quantifying each finding in dollars so you commit to real baseline usage rather than guesses. No agents, no write access. Clean up the waste first, then commit to what’s left: that’s how you actually maximize the discount. The first scan is free.