March 13, 2026 · 12 min read

AWS Savings Plans vs Reserved Instances (2026): Which Should You Choose?

AWS offers two main ways to reduce compute costs through commitment-based discounts: Savings Plans and Reserved Instances. Both require you to commit to a certain level of usage in exchange for lower rates. Both can save you 30-72% compared to on-demand pricing. And both will cost you money if you commit to the wrong thing.

This guide explains the practical differences, when to use each, and how to avoid the mistakes that turn discounts into waste.

Quick Answer: Which Should You Choose?

Scenario	Recommendation	Why
First time buying commitments	Compute Savings Plans	Most flexible, hardest to get wrong
Stable EC2 workloads, single instance type	EC2 Instance Savings Plans or zonal RIs	Deepest discounts
RDS, ElastiCache, OpenSearch, Redshift	Reserved Instances	Savings Plans don’t cover these
Rapidly changing architecture	Compute Savings Plans	Applies across instance families
Multi-region deployments	Compute Savings Plans	Region-flexible
Serverless (Lambda, Fargate)	Compute Savings Plans	Only option that covers these
Mixed workloads (EC2 + Fargate + Lambda)	Compute Savings Plans	Single commitment covers all

If you’re unsure, start with Compute Savings Plans. They’re the safest default.

What Are Savings Plans?

Savings Plans launched in November 2019 as a simpler alternative to Reserved Instances. You commit to a consistent amount of compute usage (measured in $/hour) for 1 or 3 years, and AWS gives you a discount.

Three Types of Savings Plans

1. Compute Savings Plans (most flexible)

Applies to EC2, Fargate, and Lambda
Any instance family, size, OS, tenancy, or region
Discount: Up to 66% (3-year, all upfront)
Automatically applies to your highest-cost usage first

2. EC2 Instance Savings Plans (moderate flexibility)

Applies to EC2 only
Locked to a specific instance family and region (e.g., m6i in us-east-1)
Flexible on size, OS, and tenancy within that family
Discount: Up to 72% (3-year, all upfront)

3. SageMaker Savings Plans

Applies to SageMaker only
Any instance family, size, or region
Discount: Up to 64%

How Savings Plans Work

You commit to spending $X/hour on compute. For example, a $10/hour Compute Savings Plan means you’re committing to $7,200/month ($10 x 24 x 30) in compute spend.

AWS automatically applies the discount to your usage, starting with the highest-discount resources first. If your actual usage exceeds your commitment, the excess is billed at on-demand rates. If your usage is less than your commitment, you still pay the committed amount.

Example:
- Commitment: $10/hour Compute Savings Plan
- Actual hourly usage at on-demand rates: $15/hour
- Savings Plan covers first $10/hour at ~40% discount = you pay ~$6/hour
- Remaining $5/hour billed at on-demand rates
- Total: ~$11/hour instead of $15/hour

What Are Reserved Instances?

Reserved Instances (RIs) predate Savings Plans and work differently. Instead of committing to a dollar amount, you commit to a specific instance configuration.

Types of Reserved Instances

Standard RIs

Locked to instance type, region, OS, and tenancy
Can be modified (within same instance family) or sold on RI Marketplace
Discount: Up to 72% (3-year, all upfront)

Convertible RIs

Can be exchanged for different instance types, OS, or tenancy
Cannot be sold on RI Marketplace
Discount: Up to 66% (3-year, all upfront)

Zonal vs Regional RIs

Zonal RIs: Reserved for a specific AZ; includes capacity reservation
Regional RIs: Applies across all AZs in a region; more flexible but no capacity guarantee

Services That Still Require RIs

Savings Plans only cover compute (EC2, Fargate, Lambda). For these services, Reserved Instances are your only commitment option:

Amazon RDS (including Aurora)
Amazon ElastiCache (Redis, Memcached)
Amazon OpenSearch Service
Amazon Redshift
Amazon DynamoDB (Reserved Capacity)
Amazon MemoryDB

If you run production RDS databases, you should evaluate RDS Reserved Instances. A 1-year no-upfront RI typically saves 30-40% on RDS.

Key Differences: Savings Plans vs Reserved Instances

Flexibility

This is the biggest practical difference.

Dimension	Compute SP	EC2 Instance SP	Standard RI	Convertible RI
Instance family	Any	Locked	Locked	Exchangeable
Instance size	Any	Any	Locked (or modified)	Exchangeable
Region	Any	Locked	Locked	Exchangeable
OS	Any	Any	Locked	Exchangeable
Tenancy	Any	Any	Locked	Exchangeable
Fargate/Lambda	Yes	No	No	No
Capacity reservation	No	No	Yes (zonal)	No

Compute Savings Plans automatically adjust when you change instance types, move regions, or shift workloads to Fargate. You don’t need to manage anything.

Reserved Instances require active management. When you change instance types, your RI may not apply anymore, and you keep paying for unused reservations.

Discount Depth

More commitment = deeper discount. Here’s a representative comparison for m6i.xlarge in us-east-1 (Linux):

Commitment Type	1-Year No Upfront	1-Year All Upfront	3-Year All Upfront
On-Demand	$0.192/hr	$0.192/hr	$0.192/hr
Compute SP	~$0.121/hr (37%)	~$0.112/hr (42%)	~$0.073/hr (62%)
EC2 Instance SP	~$0.115/hr (40%)	~$0.107/hr (44%)	~$0.065/hr (66%)
Standard RI	~$0.113/hr (41%)	~$0.104/hr (46%)	~$0.062/hr (68%)

The discount difference between Compute Savings Plans and Standard RIs is typically 3-6 percentage points. For most teams, the flexibility of Compute Savings Plans more than compensates for the slightly shallower discount.

Management Overhead

Savings Plans: Set it and forget it. AWS applies discounts automatically. No modifications, no marketplace selling, no capacity management.

Reserved Instances: Require ongoing management. You need to:

Track utilization (are your RIs being used?)
Modify RIs when instance sizes change
Sell unused RIs on the marketplace (Standard only)
Exchange Convertible RIs when architecture changes
Renew or re-evaluate at expiration

For teams without a dedicated FinOps function, the management overhead of RIs often negates the extra discount.

When to Use Savings Plans

Compute Savings Plans: The Safe Default

Choose Compute Savings Plans when:

You’re new to commitments. Start conservative. Commit to 50-60% of your steady-state compute spend. You can always add more later.
Your architecture is evolving. Migrating from EC2 to Fargate? Moving from x86 to Graviton? Compute Savings Plans apply regardless.
You use Lambda or Fargate. These are only covered by Compute Savings Plans, not RIs.
You run workloads across multiple regions. Compute Savings Plans are region-flexible.
You don’t want to manage commitments. No modifications, no exchanges, no marketplace.

EC2 Instance Savings Plans: The Middle Ground

Choose EC2 Instance Savings Plans when:

You’ve stabilized on an instance family. If you know you’ll run m6i instances in us-east-1 for the next year, the extra 3-4% discount adds up.
You want size flexibility within a family. You can freely move between m6i.large, m6i.xlarge, and m6i.2xlarge.
You want a better discount than Compute SP but more flexibility than Standard RIs.

When to Use Reserved Instances

For Non-Compute Services

RIs are the only commitment option for:

# Check your RDS spend - good RI candidate if stable
aws ce get-cost-and-usage \
  --time-period Start=2026-02-01,End=2026-03-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Relational Database Service"]}}' \
  --query 'ResultsByTime[0].Total.UnblendedCost.Amount'

# Check ElastiCache spend
aws ce get-cost-and-usage \
  --time-period Start=2026-02-01,End=2026-03-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon ElastiCache"]}}' \
  --query 'ResultsByTime[0].Total.UnblendedCost.Amount'

If you’re spending $500+/month on RDS or ElastiCache with stable workloads, Reserved Instances are worth evaluating.

For Capacity Reservations

Zonal RIs provide a capacity guarantee. If you need assured availability of specific instance types during peak events, zonal RIs are the only commitment that reserves actual capacity.

When You Want Maximum Discount

If you’ve done the analysis, confirmed workload stability, and have the operational discipline to manage RIs, Standard RIs offer the deepest discounts available.

Common Mistakes (and How to Avoid Them)

Mistake 1: Over-Committing

The most expensive mistake. If you commit to $20/hour in Compute Savings Plans but only use $12/hour of compute, you’re wasting $8/hour ($5,760/month).

How to avoid it:

# Check your last 90 days of hourly compute spend
aws ce get-cost-and-usage \
  --time-period Start=2025-12-13,End=2026-03-13 \
  --granularity DAILY \
  --metrics UnblendedCost \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Elastic Compute Cloud - Compute"]}}' \
  --query 'ResultsByTime[].Total.UnblendedCost.Amount' \
  --output text

Start by committing to your minimum sustained usage, not your average. If your daily compute spend ranges from $200-$400, commit based on $200, not $300.

Mistake 2: Buying RIs for Volatile Workloads

If your workloads change frequently (new instance types, new regions, architecture migrations), RIs will underperform.

How to avoid it: Use Compute Savings Plans for volatile workloads. Only use RIs for services where Savings Plans don’t apply (RDS, ElastiCache).

Mistake 3: Ignoring Expiring Commitments

Both Savings Plans and RIs expire. When they do, your costs jump back to on-demand rates overnight. A 3-year RI expiring on a production RDS instance can increase your monthly bill by 40% with no warning.

How to avoid it:

# Check RI expirations
aws ec2 describe-reserved-instances \
  --filters Name=state,Values=active \
  --query 'ReservedInstances[].{Type:InstanceType,End:End,Count:InstanceCount}' \
  --output table

# Check Savings Plans expirations
aws savingsplans describe-savings-plans \
  --query 'SavingsPlans[?state==`active`].{Type:savingsPlanType,End:end,Commitment:commitment}' \
  --output table

Mistake 4: Stacking RIs and Savings Plans Incorrectly

RIs apply first, then Savings Plans cover the remainder. If you have both, you might be double-covering some instances while leaving others on-demand.

How to avoid it: Check your coverage reports:

# View Savings Plans utilization
aws ce get-savings-plans-utilization \
  --time-period Start=2026-02-01,End=2026-03-01 \
  --query 'Total.{Utilization:UtilizationPercentage,Used:UsedCommitment,Unused:UnusedCommitment}'

If utilization is below 90%, you’re over-committed. If it’s 100% with significant on-demand spend remaining, you might benefit from additional coverage.

Mistake 5: Not Accounting for Architecture Changes

Planning to migrate from EC2 to Fargate? Moving to Graviton ARM instances? These changes can strand your RIs.

How to avoid it: If you have any migration planned in the next 12 months, use Compute Savings Plans for the portion of spend that might change.

A Practical Strategy

For most teams, the optimal commitment strategy follows a layered approach:

Layer 1: Compute Savings Plans (50-70% of stable compute) Cover your baseline compute spend with Compute Savings Plans. Start conservative and increase over time.

Layer 2: RDS/ElastiCache RIs (for stable databases) Buy 1-year no-upfront RIs for production databases that will run for at least 12 months.

Layer 3: On-Demand for everything else Keep variable, experimental, and short-lived workloads on-demand. The flexibility premium is worth it.

Total monthly compute spend:     $10,000
Layer 1 (Compute SP, 60%):       $6,000 → pays ~$3,600 (40% savings)
Layer 2 (RDS RIs):               $1,500 → pays ~$1,050 (30% savings)
Layer 3 (On-demand):             $2,500 → pays $2,500
                                 --------
Total:                           $7,150 (vs $10,000 on-demand)
Monthly savings:                 $2,850 (28.5%)

How CostPatrol Helps

Analyzing commitment coverage manually is tedious. CostPatrol’s optimization scanner includes rules that identify Savings Plans and Reserved Instance opportunities:

EC2-004: Detects on-demand instances running 500+ hours/month without reservation coverage
RI-O001: Identifies Reserved Instance gaps where existing coverage has expired or doesn’t match current usage
SP-O001: Analyzes Savings Plans utilization and flags underutilization or expansion opportunities

The scanner checks your actual usage patterns against commitment coverage and estimates potential savings for each recommendation. Instead of manually running AWS CLI queries across every account, you get a prioritized list of commitment opportunities with dollar estimates.

Summary

Factor	Savings Plans	Reserved Instances
Best for	Compute flexibility	Database services, capacity guarantees
Risk level	Low (auto-applies)	Medium (requires management)
Discount depth	Good (37-66%)	Best (41-72%)
Management effort	Minimal	Significant
Coverage	EC2, Fargate, Lambda	EC2, RDS, ElastiCache, OpenSearch, Redshift
Our recommendation	Start here	Add for databases and stable workloads

Start with Compute Savings Plans at 50-60% of your baseline compute spend. Add database RIs for stable production workloads. Leave 30-40% on-demand for flexibility. Review quarterly.

The best commitment strategy is the one you actually understand and manage. A well-utilized 40% discount beats a poorly managed 70% discount every time.