Reserved Instances vs. Spot Instances vs. Savings Plans: Which Saves More?

A practical 2026 decision guide to every AWS compute pricing model — exact discount levels, commitment rules, real workload matching, and the optimal purchasing stack for startups and SMBs.

There is no single winner. Reserved Instances, Spot Instances, and Savings Plans each deliver maximum savings for different workload types. Using the wrong model for a workload is one of the most common causes of missed savings.

The right answer: most AWS accounts should use all three simultaneously — Savings Plans for the stable compute baseline, Spot for interruption-tolerant jobs, and Reserved Instances for specific database or legacy workloads. The prerequisite: none of these models should be purchased before 4+ weeks of stable production data. Committing too early, or to the wrong baseline, turns a savings tool into a waste source.

TL;DR

• No single winner – use all three. Savings Plans for stable compute baseline, Spot for interruptible jobs, RIs for databases.
• Savings Plans (up to 66% off): Broadest coverage – EC2, Fargate, Lambda. No instance management. Commit 65-75% of stable baseline, not peak.
• Reserved Instances (up to 72% off): Highest discount, but instance-family locked. Critical: Savings Plans don't cover RDS, Aurora, or ElastiCache – those need RIs.
• Spot (up to 90% off): Deepest savings, 2-min interruption notice. Use for CI/CD, batch, ML training, dev/test. Never for production databases or stateful workloads.
• Rule: Wait 4+ weeks of stable data before committing.
• Most overlooked: RDS Reserved Instances – $15K/mo database spend can save $6K-$10K/mo with zero changes.

1. The Problem with On-Demand Pricing

On-Demand is AWS's default pricing model. You provision a resource, you pay the listed hourly rate, you terminate it when you're done. No commitment, no risk, maximum flexibility.

It is also the most expensive way to run stable, predictable workloads on AWS — by a significant margin. AWS prices On-Demand to cover the cost of unused capacity that must be available instantly. You pay for that optionality whether you need it or not.

For workloads that run continuously and predictably — your production database, your core API servers, your data pipeline — that optionality has zero value. You are paying 40–72% more than necessary to maintain flexibility you will never use.

The three alternative purchasing models exist to convert that flexibility premium into savings — each optimized for a different workload pattern.

2. The Three Pricing Models: How Each One Works

Reserved Instances (RIs)

Spot Instances

Savings Plans

3. Side-by-Side Comparison: Every Dimension That Matters

4. Reserved Instances: Standard vs. Convertible vs. Scheduled

Standard Reserved Instances

Standard RIs offer the highest discount — up to 72% for a 3-year, all-upfront commitment on a specific instance family, size, OS, tenancy, and region. The trade-off: zero flexibility. If you change instance family (e.g. from m5 to m6i) or move to a new region, the RI does not follow.

Standard RIs are appropriate for workloads where the instance configuration will not change over the commitment term. A production PostgreSQL RDS instance that has been stable for 12 months is a good Standard RI candidate. A compute fleet that you plan to modernize or migrate in 18 months is not.

Convertible Reserved Instances

Convertible RIs sacrifice some discount (typically ~54% vs. 72% for 3-year Standard) in exchange for the ability to change instance family, OS, and tenancy during the term. You cannot cancel the term, but you can exchange the RI for a different configuration of equal or greater value.

Convertible RIs make sense when you expect to upgrade to newer instance generations (e.g. m6i → m7i) during the commitment term — which is common over a 3-year window as AWS regularly releases new generations that offer better price/performance.

Standard vs. Convertible: the decision rule

Payment options and their discount impact

5. Spot Instances: Making Interruptions Work for You

Spot Instances are misunderstood in both directions: some teams avoid them entirely due to interruption fear, while others try to run production workloads on Spot and suffer reliability consequences.

The reality: Spot interruption rates are lower than most teams expect — historically under 5% per instance-hour for most instance types and regions. But the 5% that do get interrupted can cause real damage if the workload is not designed for it.

Workloads that are ideal for Spot

Spot best practices for reliability

• Use Spot Fleet or EC2 Auto Scaling with mixed instances policy: specify multiple instance types and sizes across multiple AZs. If one type is interrupted, AWS launches from the pool.
• Set capacity-optimized allocation strategy: AWS chooses the instance type from your pool with the lowest interruption probability rather than lowest price. Reduces interruption rate significantly.
• Use Spot Instance Advisor before purchasing: shows historical interruption frequency and savings by instance type. Choose types with <5% interruption rate.
• Implement graceful shutdown hooks: use the 2-minute interruption notice (via EC2 metadata or EventBridge) to drain connections, save state, and notify orchestrators before termination.
• Never run Spot without fallback capacity: always maintain a minimum On-Demand or RI baseline for critical capacity. Spot augments the baseline; it does not replace it.

6. Savings Plans: The Recommended Default for Most Teams

AWS Savings Plans are the most recently introduced commitment model (2019) and have become the recommended default for compute commitments at most startups and SMBs. The reason: they offer near-RI-level discounts with dramatically less management overhead.

Instead of committing to specific instance configurations, you commit to a minimum $/hour spend level. AWS automatically applies the Savings Plan discount to the most expensive eligible usage in your account — no instance-level matching required.

Compute Savings Plans vs. EC2 Instance Savings Plans

How to size a Savings Plan correctly

This is where most teams make their most expensive Savings Plan mistake: committing too aggressively based on peak usage rather than stable baseline usage.

1. Pull 30 days of On-Demand spend data from Cost Explorer, filtered to EC2, Fargate, and Lambda usage only
2. Identify your consistent minimum $/hour spend across that period — the floor of your usage, not the average or peak
3. That floor is your Savings Plan commitment level — the amount you are confident you will spend every hour for the next 1 or 3 years
4. Leave peaks, growth, and variable loads to be covered by On-Demand (which the Savings Plan automatically supplements)
5. Target coverage of 65–75% of stable baseline; keep 25–35% On-Demand for flexibility and growth
6. Review and potentially increase commitment every quarter as usage grows — Savings Plans can be added but not cancelled

7. The Optimal Purchasing Stack: Using All Three Together

The question in the article title — 'which saves more?' — has a better answer than picking one: use all three in a structured stack, each covering the workloads it is best suited for.

EaseCloud applies this layered approach in every cost optimization engagement. Here is the model:

8. Workload-by-Workload Decision Guide

Apply this guide to each workload in your AWS account to determine the right purchasing model:

14 workload scenarios, one decision guide. Still not sure which model fits your specific workload? We'll run the numbers.

9. The Most Expensive Purchasing Mistakes

1. Committing before establishing a usage baseline. Standard RIs cannot be cancelled and have limited resale value. Committing too early — before production usage patterns are stable — results in unused commitments. Wait 4+ weeks of stable production data.
2. Assuming Savings Plans cover everything. RDS, Aurora, ElastiCache, Redshift, and OpenSearch are NOT covered by Savings Plans. These services require their own Reserved Instance commitments. The gap is common and expensive.
3. Committing to peak usage rather than stable baseline. If your baseline is 50 instances and you spike to 200 on campaign days, commit to 50. The spike is covered by On-Demand automatically. Committing to 200 means paying for 150 instances of idle commitment on non-spike days.
4. Never reviewing existing commitments. RIs purchased 18 months ago may be for instance families you've since migrated away from. Quarterly RI/SP reviews catch underutilized commitments before they become sunk costs. Unused Standard RIs can be listed on the Marketplace.
5. Running Spot without instance diversity. Specifying a single Spot instance type means interruption when that type's capacity is exhausted. Spot Fleet with 6–10 diverse instance types maintains capacity even when individual types are interrupted.
6. Using Spot for stateful production workloads. Customer-facing applications with session state, database connections, or in-memory caches do not tolerate 2-minute interruptions gracefully. Spot for production is appropriate only for stateless, highly available services with proper instance diversification.

Conclusion

There is no single "best" AWS purchasing model – each is optimized for different workload patterns. Savings Plans are the recommended default for compute commitments due to their flexibility and low management overhead. Reserved Instances deliver the highest discounts but require instance-family lock-in, making them ideal for stable databases and legacy workloads.

Spot Instances provide the deepest savings for interruption-tolerant jobs but require workload design for resilience. The optimal approach for most AWS accounts is a layered stack: Compute Savings Plans for the stable baseline, RDS Reserved Instances for databases, Spot for batch and CI/CD, and On-Demand as a 25-35% safety buffer for peaks and growth.

The single most common missed savings opportunity is assuming Savings Plans cover databases – they do not. RDS RIs on stable database workloads deliver 40-69% savings with no code changes. The foundation of effective commitment purchasing is data: wait 4+ weeks of stable production usage before committing to any model.

Frequently Asked Questions

Can I cancel a Reserved Instance if I don't need it anymore?

Standard RIs cannot be cancelled. However, they can be sold on the AWS Reserved Instance Marketplace — typically at 50–90% of remaining value. Convertible RIs cannot be sold or cancelled but can be exchanged for a different RI configuration of equal or greater value. Savings Plans cannot be cancelled or sold.

What happens if my Savings Plan commitment exceeds my actual usage?

You still pay the committed $/hour amount even if your actual compute usage falls below it. This is the risk of over-committing. The unused commitment is pure waste — which is why committing only 65–75% of stable baseline (rather than 100%) and leaving a buffer is essential. If you over-commit, the lesson is to wait for more usage data before the next purchase.

Do Savings Plans automatically apply, or do I need to configure them?

Savings Plans apply automatically. Once purchased, AWS applies the discount to the most expensive eligible On-Demand usage in your account — no instance-level configuration required. You see the savings reflected in your Cost Explorer as 'Savings Plans covered usage' vs. 'On-Demand usage.' Nothing to configure after purchase.

Should I buy 1-year or 3-year commitments?

For most startups and SMBs, 1-year commitments are the right default. The additional discount on 3-year terms (roughly 10–15% more than 1-year) is attractive but comes with real risk: your usage patterns, instance preferences, and business needs over 3 years are genuinely uncertain. Start with 1-year, establish the pattern, then evaluate 3-year at renewal if the workload is demonstrably stable.

How do I know how much of my bill is currently On-Demand vs. committed?

AWS Cost Explorer shows this directly. Navigate to Cost Explorer → Coverage reports → Savings Plans coverage or Reserved Instance coverage. These reports show what percentage of your eligible usage is covered by commitments, and what percentage is still running On-Demand — the uncovered On-Demand is your savings opportunity.

Get a Free AWS Cost Analysis from EaseCloud

EaseCloud's cost optimization team analyzes your actual AWS usage data and identifies exactly how much you can save through the right mix of Reserved Instances, Savings Plans, and Spot Instances — with specific commitment recommendations before any engagement begins.

Most clients discover $3,000–$25,000/month in recoverable savings from purchasing model optimization alone — before touching instance types, storage, or data transfer.