← Insights · July 2026 · 8 min read
Reserved Instances vs. Savings Plans: What to Buy in 2026
Commitment discounts are the biggest single lever on an AWS bill, and the most common place we find money left on the table. Here's how the options actually differ, and the buying order that keeps you flexible.
The menu
| Instrument | Flexibility | Max discount | Best for |
|---|---|---|---|
| Compute Savings Plan | Any family, region, OS; covers Fargate & Lambda too | ~66% | Your default commitment |
| EC2 Instance Savings Plan | Locked to family + region | ~72% | Stable, known fleets |
| Standard RI | Family-locked; resellable on the RI Marketplace | ~72% | Steady state + exit option |
| Convertible RI | Exchangeable across families | ~66% | Mostly superseded by Savings Plans |
For pure EC2/Fargate/Lambda compute, Savings Plans have largely won: same discounts as the RI equivalents with far less management overhead. But that's not the whole bill.
What Savings Plans still don't cover
This is the gap that costs mid-market companies real money. Savings Plans apply to compute only. If you run managed data services, you still need service-specific reservations:
- RDS / Aurora: Reserved Instances, bought separately per engine and instance class.
- ElastiCache, OpenSearch, Redshift: reserved nodes, each with its own purchase flow.
- DynamoDB: reserved capacity if you're on provisioned mode.
We routinely find accounts with a healthy Compute Savings Plan and zero coverage on a six-figure RDS footprint. The database reservations are less famous, and nobody owns buying them.
The buying order that matters more than the instrument
- Rightsize first, commit second. A commitment locks in your current shape. If you commit before rightsizing and generation upgrades, you're pre-paying for waste for one to three years.
- Target 70–80% coverage of the post-optimization baseline. Committing to 100% means paying for commitment you can't use the day traffic dips or an architecture changes.
- Ladder your purchases. Buy in quarterly tranches instead of one annual block. Your coverage tracks reality, and no single expiration date can fall off a cliff.
- Default to 1-year, no-upfront. The discount gap versus 3-year is real, but so is the optionality. Reserve 3-year commitments for the truly immovable core.
- Put expiration alerts on a calendar someone owns. Expired reservations silently revert to on-demand. We've seen bills jump 30% in a month because a 3-year RI block quietly lapsed.
The mistakes we see most
- Committing before rightsizing (locking in oversized instances at a discount is still waste).
- Compute covered, databases forgotten.
- One giant purchase with one giant expiration.
- Coverage nobody reviews: utilization reports exist in Cost Explorer, but only if someone reads them monthly.
Not sure what your coverage actually is?
Commitment analysis is a core part of our AWS cost audit. If we find nothing, you pay nothing.
How the Audit WorksWritten by Ruben Rivero, AWS Certified Solutions Architect – Professional. 12+ years running enterprise AWS environments.