Reserved Instances vs. Savings Plans in AWS
For companies operating at scale in AWS, compute commitments are one of the biggest levers for reducing cloud spend. But with multiple commitment models - Reserved Instances (RIs) and Savings Plans (SPs) - teams often struggle to find the right choices, leading to wasted coverage, inflexibility, or savings that never materialize.
At Absolute Ops, we help customers evaluate these models every week. This guide breaks down the differences, pros, cons, service coverage, and when each option makes sense for your environment.
1. What Reserved Instances and Savings Plans Actually Are
Both RIs and SPs give you a discount on compute usage in exchange for a commitment - usually a 1-year or 3-year contract, with options for No Upfront, Partial Upfront, or All Upfront.
But they differ dramatically in flexibility, scope, and risk.
2. Reserved Instances (RIs)
Reserved Instances were AWS’s original commitment model and remain widely used, especially for predictable workloads.
Kinds of RIs
There are two main categories:
Standard RIs
- Provide the highest discount (up to ~72%)
- Locked to:
- a specific instance family (e.g., m5, r6g)
- specific OS (Linux/Windows)
- specific tenancy (default/dedicated)
- specific region
- Modifications are limited (instance size flexibility only within the same family)
Convertible RIs
- Slightly lower savings (~45–55%)
- You can exchange them to:
- another instance family
- another size
- another OS
- another tenancy
- Must maintain equal or greater value in the exchange
- Useful for evolving environments
Services Covered by RIs
RIs apply to:
- EC2 (primary use case)
- RDS (Reserved DB Instances)
- ElastiCache
- OpenSearch
- Redshift
Each of these has its own RI structure separate from EC2 RIs.
Pros of RIs
- Largest discount potential
- Capacity reservation available (optional)
- Ideal for steady, predictable workloads
- Option to buy/sell on the AWS Marketplace (Standard RIs)
Cons of RIs
- Less flexible than Savings Plans
- Risk of coverage gaps if usage changes
- Separate RI model for each service (EC2 vs RDS vs Redshift)
- Harder to manage at scale
- Convertible RIs still require active management
3. Savings Plans (SPs)
Savings Plans were introduced to solve the biggest RI pain point: inflexibility.
Instead of locking you to a specific instance family, Savings Plans commit you to a spend amount per hour, such as:
“I commit to $20/hour of compute for 3 years.”
AWS then applies Savings Plans discounts automatically to eligible usage.
There are two types:
Compute Savings Plans
The most flexible savings model AWS offers.
Works across:
- Any EC2 instance family (m5, c6g, r7a, etc.)
- Any region
- Any OS
- Any tenancy
- AWS Fargate
- AWS Lambda
This is the only commitment method that covers Lambda and Fargate, making it extremely useful for containerized or serverless workloads.
Pros
- Very high flexibility
- Automatically applies to the highest-ROI compute first
- Great for dynamic or multi-architecture environments
- Eliminates the “RI management tax”
Cons
- Slightly lower maximum savings than Standard RIs
- No capacity reservation
- Can be inefficient if you overcommit (spend is charged regardless)
EC2 Instance Savings Plans
A middle ground between Compute SPs and RIs.
Locked to:
- A single instance family (e.g., m6i)
- A single region
Flexible across:
- OS
- Size
- Tenancy
Pros
- Higher savings than Compute SPs
- More flexible than RIs
Cons
- More restrictive than Compute SPs
- Still possible to misalign coverage if your instance families change
4. Pros & Cons Summary
| Model | Best For | Pros | Cons |
|---|---|---|---|
| Standard RIs | Long-term, steady workloads | Max savings, capacity reservation, marketplace trading | Locked to type/family/region, highest management overhead |
| Convertible RIs | Evolving compute needs | Flexible exchanges | Lower savings, requires manual adjustments |
| Compute Savings Plans | Dynamic, modern workloads (EC2 + Fargate + Lambda) | Highest flexibility, lowest management | Slightly lower savings ceiling, no capacity reservation |
| EC2 Instance Savings Plans | Predictable EC2 usage within one family/region | Good savings + moderate flexibility | Can miss coverage if instance families change |
5. Which One Should You Use? (Practical Scenarios)
Scenario A: Stable production EC2 fleet
Use Standard RIs or EC2 Instance SPs.
If you know your workloads won’t change, Standard RIs give maximum discount.
Scenario B: Migrating, refactoring, or unpredictable workloads
Use Compute Savings Plans.
They adapt automatically when:
- you move from m5 → m7i
- you switch from EC2 → Fargate
- you introduce Lambda functions
- you change regions
- you adopt Graviton processors
Scenario C: Database-heavy applications
Use RDS Reserved Instances.
Savings Plans do not apply to:
- RDS
- Aurora
- ElastiCache
- OpenSearch
- Redshift
These services require their own RIs.
Scenario D: Multi-account organizations
Use a mix of:
- Compute SPs for flexibility
- RDS/Redshift RIs for stateful services
- Instance SPs for long-lived EC2 families
Organizations with 20–200 accounts benefit the most from blended strategies.
6. The Absolute Ops Recommendation
After evaluating hundreds of AWS environments, here is the approach we typically recommend:
For most organizations:
✔ Compute Savings Plans for broad, low-maintenance savings
✔ RDS/Redshift/OpenSearch RIs for stateful services
✔ Targeted EC2 Instance SPs or Standard RIs for extremely steady production instances
Avoid heavy reliance on Standard RIs unless your workloads have almost no architectural change expected for 2–3 years. RIs tend to fragment, leaving you managing multiple schedules, while trying to keep up on discounts.
Modern workloads change quickly - your commitment strategy should keep up.
Final Thoughts
Choosing between Reserved Instances and Savings Plans isn’t about the biggest discount - it’s about risk, flexibility, and operational reality.
- RIs reward stability
- Savings Plans reward agility
- The right mix cuts cost while reducing management overhead
