AWS Reserved Instances vs Savings Plans — Save 30-72% on Compute (2026 Decision Guide)
AWS gives you two ways to save on compute: Reserved Instances (RIs) and Savings Plans. Complete 2026 guide to AWS Reserved Instances vs Savings Plans — Standard RI vs Convertible RI vs Compute Savings Plan vs EC2 Savings Plan. Real cost calculations, decision flowchart, common mistakes, and exactly what to buy based on your workload. Save 30-72% on compute. Both offer up to 72% discount over On-Demand pricing in exchange for a 1-year or 3-year commitment. The problem? Most teams buy the wrong one, over-commit, or buy before right-sizing — and end up wasting money instead of saving it. This guide gives you a clear decision framework.
What Are Reserved Instances?
Reserved Instances are a billing discount, not actual instances. When you purchase an RI, AWS automatically applies the discount to any running instance that matches the RI’s attributes (instance type, region, OS, tenancy). There are two types:
- Standard RI — locked to a specific instance family, size, region, and OS. Highest discount (up to 72%). Can be sold on the RI Marketplace.
- Convertible RI — can change instance family, size, OS, and tenancy during the term. Lower discount (up to 66%). Cannot be sold.
What Are Savings Plans?
Savings Plans are a commitment to a dollar amount per hour of compute usage. Instead of committing to a specific instance, you commit to spending (e.g., $10/hour). Two types:
- Compute Savings Plan — most flexible. Applies to any EC2 instance (any family, any region, any OS), plus Fargate and Lambda. Discount up to 66%.
- EC2 Instance Savings Plan — locked to a specific instance family in a specific region (e.g., m5 in us-east-1). Discount up to 72%. More restrictive but cheaper.
Comparison Table
| Feature | Standard RI | Convertible RI | Compute Savings Plan | EC2 Instance Savings Plan |
|---|---|---|---|---|
| Max discount | 72% | 66% | 66% | 72% |
| Change instance family | No | Yes | Yes | No (locked to family) |
| Change region | No | No | Yes | No |
| Applies to Fargate/Lambda | No | No | Yes | No |
| Commitment type | Instance attributes | Instance attributes | $/hour spend | $/hour spend |
| Can sell unused | Yes (Marketplace) | No | No | No |
| Size flexibility | Within family (Linux) | Yes | Yes | Within family |
When to Use Standard RIs
Use Standard RIs only when:
- You are 100% certain of the instance type (e.g., you’ve been running the same m5.xlarge for 6+ months)
- The workload is steady 24/7 (databases, core API servers)
- You want the absolute maximum discount
- You’re comfortable with the risk — if you need to change, you can try selling on the Marketplace, but it’s not guaranteed
When to Use Convertible RIs
Honestly? Almost never in 2026. Compute Savings Plans offer the same discount with more flexibility. The only edge case is if you want to lock to a specific instance and later convert to a more expensive one (Convertible RIs allow “upgrading” mid-term).
When to Use Compute Savings Plans
This is the default choice for most teams:
- You have steady compute spend but might change instance types
- You use a mix of EC2, Fargate, and Lambda
- You operate across multiple regions
- You want flexibility without much analysis
When to Use EC2 Instance Savings Plans
Use this when:
- You’re committed to a specific instance family (e.g., m5 or c6i) in a specific region
- You want higher discounts than Compute Savings Plans
- You’re OK with size flexibility within the family (m5.large and m5.2xlarge both covered)
How to Calculate What to Buy
Do NOT guess. Use data.
- Open AWS Cost Explorer
- Go to Reports → EC2 Usage
- Set time range to last 3 months
- Group by Instance Type
- Look for the steady-state baseline — the minimum number of instances running 24/7
- Only commit to that baseline, not peaks
# Quick check: find your On-Demand spend baseline
# AWS CLI — get last 30 days EC2 spend
aws ce get-cost-and-usage \
--time-period Start=2026-03-01,End=2026-04-01 \
--granularity MONTHLY \
--metrics "UnblendedCost" \
--filter '{
"Dimensions": {
"Key": "SERVICE",
"Values": ["Amazon Elastic Compute Cloud - Compute"]
}
}' \
--group-by Type=DIMENSION,Key=INSTANCE_TYPE
AWS also provides Savings Plans recommendations in Cost Explorer under Recommendations → Savings Plans. Use it as a starting point, but verify against your actual usage patterns.
Real Example
Here’s what I did for a production environment running a multi-tenant SaaS platform:
- 3x m5.xlarge running 24/7 for core API — bought EC2 Instance Savings Plan for m5 family (72% discount)
- 2x t3.medium running 24/7 for background workers — covered by the same Compute Savings Plan
- Variable Fargate tasks for batch processing — partially covered by Compute Savings Plan
- Peak hours had 2 additional m5.xlarge — left these On-Demand (don’t commit to peaks)
Result: $1,400/month saved on a ~$4,000/month compute bill. 35% reduction.
1-Year vs 3-Year Term
| Factor | 1-Year | 3-Year |
|---|---|---|
| Discount | ~40% (varies) | ~60-72% (varies) |
| Risk | Lower — easier to adjust | Higher — locked for 3 years |
| Best for | First-time buyers, evolving workloads | Stable workloads you’ve run 1+ years |
| Recommendation | Start here | Graduate to this once confident |
My rule: Buy 1-year commitments first. After your first renewal, if the workload is still the same, switch to 3-year for the bigger discount.
Payment Options
No Upfront
Pay monthly. Smallest discount but no capital required. Best for most teams.
Partial Upfront
Pay ~50% upfront, rest monthly. Middle ground. Better discount than No Upfront.
All Upfront
Pay 100% upfront. Maximum discount. Only if you have the cash and certainty.
Recommendation: Start with No Upfront. The difference between No Upfront and All Upfront is usually only 3-5% additional savings — not worth the cash outlay risk for most teams.
Common Mistakes That Waste Money
- Buying before right-sizing — if your m5.xlarge is only using 20% CPU, right-size to m5.large first, then commit. Otherwise you’re locking in waste. See our EC2 right-sizing guide.
- Over-committing — only commit to your steady-state baseline, never your peak usage. Peaks should stay On-Demand or use Spot.
- Forgetting region locks — Standard RIs and EC2 Instance Savings Plans are region-locked. If you move to a different region, the commitment doesn’t follow.
- Not checking utilization — go to Cost Explorer → Reservations → Utilization to see if your existing RIs are actually being used.
- Buying Convertible RIs in 2026 — Compute Savings Plans are almost always the better choice now.
- Letting commitments auto-renew without review — set a calendar reminder 30 days before expiry. Check if your workload still matches.
Decision Flowchart
- Have you right-sized your instances? No → Do that first
- Do you have 3+ months of steady usage data? No → Wait and collect data
- Are you certain of instance family + region? Yes → EC2 Instance Savings Plan
- Do you use Fargate/Lambda/multiple regions? Yes → Compute Savings Plan
- Do you need absolute maximum discount on a single type? Yes → Standard RI
- Not sure? → Compute Savings Plan, 1-year, No Upfront
Savings Plans for Fargate and Lambda
One of the most overlooked features of Compute Savings Plans — they apply to Fargate and Lambda, not just EC2. If you run containers on ECS Fargate or serverless functions on Lambda, a Compute Savings Plan covers those costs too. EC2 Instance Savings Plans and Reserved Instances do NOT cover Fargate or Lambda.
This is the single biggest reason Compute Savings Plans are the default recommendation in 2026. Most modern AWS architectures use a mix of EC2, Fargate, and Lambda. A Compute Savings Plan covers all three with one commitment. Three separate commitment types (RI for EC2, nothing for Fargate, nothing for Lambda) would leave money on the table.
When NOT to Buy Any Commitment
Commitments are wrong in these situations:
- You have not right-sized yet. If your EC2 instances are over-provisioned (and they almost certainly are), committing to them locks in the waste. Right-size first, then commit.
- Your workload is less than 3 months old. Usage patterns are not stable yet. Wait until you have at least 3 months of CloudWatch data before committing.
- You are planning a migration. Moving from EC2 to Fargate? From one region to another? From one instance family to another? Do the migration first, stabilize, then commit.
- Your total compute spend is under $500/month. The savings are real but small in absolute terms. Spend your time on NAT Gateway optimization or scheduling dev resources first — those have higher ROI at small scale.
- You are on a startup credits program. AWS credits cover On-Demand usage. If you buy a commitment, you pay real money for the commitment while your credits sit unused. Wait until credits expire.
The Commitment Stacking Strategy
The smartest teams don't buy one big commitment. They stack small ones over time:
- Month 1: Buy a Compute Savings Plan covering 50% of your steady-state compute spend. Conservative. Safe.
- Month 3: Review actual usage vs commitment. If your commitment is fully utilized (100% utilization in Cost Explorer), add another 20%.
- Month 6: Review again. Stack another small commitment if usage grew.
- Ongoing: Never let total commitments exceed 70-80% of your average compute spend. The remaining 20-30% stays On-Demand to absorb traffic spikes and workload changes.
This approach avoids the #1 mistake — over-committing based on peak usage and then paying for unused commitment during off-peak months.
Frequently Asked Questions
How much can I save with AWS Reserved Instances?
Standard RIs offer up to 72% savings with 3-year All Upfront. Typical real-world savings: 30-40% for 1-year No Upfront, 50-60% for 3-year Partial Upfront. Exact percentage depends on instance type, region, and payment option. Use the AWS Cost Explorer RI recommendations to see your specific numbers.
What is the difference between Compute and EC2 Instance Savings Plans?
Compute Savings Plans apply across ALL instance families, regions, OS, and even Fargate + Lambda — maximum flexibility, up to 66% discount. EC2 Instance Savings Plans lock you to a specific instance family in a specific region but offer up to 72% discount. Choose Compute for flexibility (recommended for most teams), EC2 Instance for maximum savings on guaranteed-stable workloads.
Should I buy Reserved Instances or Savings Plans in 2026?
Compute Savings Plans for most teams. They offer similar discounts to Convertible RIs but apply across instance families, regions, Fargate, and Lambda. Only choose Standard RIs if you are 100% certain of your instance type for the full term and want the absolute maximum discount.
Can I get a refund on AWS Savings Plans?
No. Savings Plans are non-refundable. You pay the committed $/hour for the entire term. Right-size your instances BEFORE buying commitments — never commit based on unoptimized usage.
Can I sell unused Reserved Instances?
Yes, you can list Standard RIs on the AWS Reserved Instance Marketplace. Convertible RIs and Savings Plans cannot be sold. There is a 12% service fee on sales.
What happens if I stop using the instance I reserved?
You still pay the commitment. RIs and Savings Plans are billing constructs — the discount applies automatically to matching usage, but if nothing matches, you pay anyway. This is why you should only commit to your baseline.
Savings Plans vs Reserved Instances — which is better overall?
For most teams in 2026, Compute Savings Plans are the best starting point. Same discount as Convertible RIs but with more flexibility (cross-region, cross-family, covers Fargate and Lambda). Only choose Standard RIs if you want maximum discount and are certain of your instance type.
Is there a minimum commitment for Savings Plans?
The minimum is $0.001/hour (essentially nothing). Start small, see how it works, then scale up.
Can I combine Reserved Instances and Savings Plans?
Yes. AWS applies RIs first, then Savings Plans to remaining eligible usage. A valid strategy: use Standard RIs for known database instances, Compute Savings Plans for everything else.