Should I use AWS Savings Plans or Reserved Instances in 2026?

For most modern workloads, Compute Savings Plans (CSP) are the right answer. CSP applies to EC2, Fargate, and Lambda simultaneously across all regions and instance families, saving 17-28%. Reserved Instances (Standard) save more (up to 66%) but lock you to a specific instance type, region, and tenancy — making them risky as workloads evolve. The simple rule: use CSP for general compute baseline, use Standard RI only for genuinely predictable EC2 workloads where you know the exact instance type for the next 1-3 years. Avoid Convertible RIs entirely; CSP replaces them with better flexibility.

What is the difference between Compute Savings Plans and EC2 Instance Savings Plans?

Compute Savings Plans (CSP) apply across EC2, Fargate, and Lambda, regardless of instance family, region, OS, or tenancy. Discount: 17-28% depending on term and payment. EC2 Instance Savings Plans apply only to a specific instance family in a specific region (e.g., 'm5 family in us-east-1'). Discount: 20-32%. The 4-5 percentage point savings difference comes at the cost of flexibility. For workloads where you might change instance families (cloud-native scaling, multi-tier services), CSP is worth the small discount premium. For locked-in steady workloads, EC2 Instance SP is fine.

Are Convertible Reserved Instances worth buying in 2026?

No. Convertible RIs are essentially dead in 2026. Compute Savings Plans replaced their use case with better mechanics: CSP automatically applies to your usage without requiring active 'exchange' actions, applies to Lambda and Fargate (Convertible RIs don't), and has no exchange rules. AWS still sells Convertible RIs but actively pushes Compute Savings Plans for new customers. We have not recommended Convertible RIs to a single client in 2025-2026. Standard RIs remain useful for very specific workloads; Convertible RIs do not.

How much should I commit to AWS Savings Plans?

The 75th percentile rule: calculate your hourly compute spend over the last 90 days, find the 75th percentile of that distribution, and commit at that level. This typically captures 60-75% of total spend in commitments while leaving room for variability. Going higher (e.g., 90th percentile) maximizes savings but risks underutilization if workloads shift. Going lower (e.g., 50th percentile) leaves savings on the table. Reassess every 6 months as your baseline grows. The biggest mistake is committing to projected growth that doesn't materialize, leaving 30-40% of commitment unused.

Should I buy 1-year or 3-year AWS Savings Plans?

For most companies, 1-year SP at 17% discount is the right starting point because it limits commitment risk. 3-year SP at 28% discount is significantly better for stable workloads but locks you in for 36 months — risky if your business changes (acquisition, migration off AWS, major architecture pivot). Our rule: buy 1-year for the upper layer of your steady-state, buy 3-year for the bottom 50% (the truly long-term baseline). Most companies should mix, not choose. All upfront vs partial upfront vs no upfront only changes savings by 1-2 percentage points; pick whichever matches your cash flow preference.

Back to Engineering Insights

Cloud Cost Optimization

May 21, 2026

By Ravi Kanani

AWS Savings Plans vs Reserved Instances 2026: Pick Wrong, Lose 60% (Real Commitment Decision Framework)

Key Takeaway

Compute Savings Plans (CSP) save 17-28% with maximum flexibility (apply to EC2 + Fargate + Lambda across regions, OS, and instance families). EC2 Instance Savings Plans save 20-32% but lock you to instance family + region. Standard RIs save 25-66% but lock you to specific instance type. Convertible RIs save 18-54% with mid-flexibility (can exchange within commitment). For most workloads in 2026, Compute Savings Plans are the right answer because they apply to Lambda, Fargate, and EC2 simultaneously. Convertible RIs are dead. Standard RIs only win for predictable steady-state EC2 with long horizons.

We Optimized 47 AWS Commitment Portfolios. Most Teams Were Losing 40-60% In Savings Or Flexibility.

A growth-stage SaaS company we worked with in early 2026 had $2.1 million committed to Standard Reserved Instances. Their cloud architect had purchased them in 2023 based on workload assumptions that no longer held. By 2026:

40% of the RIs were locked to m5 family, but their workloads had migrated to m6i and m7g (Graviton)
25% were in regions they had abandoned during a multi-region consolidation
35% applied to instances they were running, but at lower utilization than expected

Effective utilization: 35%. They were paying for 65% of capacity they couldn't use. Annual waste: ~$840,000.

We migrated them to a mixed Compute Savings Plans portfolio (1-year CSP for the variable layer, 3-year CSP for the bottom baseline). After 6 months:

Commitment utilization rose to 91%
Total savings increased from "advertised 40% on RI but really 14% net" to "real 24% across all compute"
Savings increased $720,000 annually

This pattern is consistent across 47 commitment portfolios we optimized in 2025-2026: most teams pick the wrong AWS commitment type, then either lose flexibility or lose savings to underutilization. The 2-3 percentage points of "extra savings" from Standard RIs over Compute SP almost always evaporate to underutilization within 12 months.

This post is the actual decision framework: when each commitment type wins, when each one is wrong, the math behind 1-year vs 3-year, and how to size commitments without overpaying for capacity you won't use.

If you have AWS commitments and haven't reviewed them in the last 12 months, you are very likely in a similar trap.

The Four AWS Commitment Types in 2026

Commitment Type	Discount Range	Flexibility	Best For
Compute Savings Plans	17-28%	Highest (EC2 + Fargate + Lambda, any region, any family)	Modern workloads with evolution
EC2 Instance Savings Plans	20-32%	Medium (locked to family + region)	Stable EC2 workloads
Standard Reserved Instances	25-66%	Lowest (locked to instance type, region, OS, tenancy)	Steady-state predictable EC2 only
Convertible Reserved Instances	18-54%	Medium (exchangeable)	Effectively dead — use CSP instead

Plus specialized commitments:

SageMaker Savings Plans: 17-28% on SageMaker compute (separate from compute SP)
DynamoDB Reserved Capacity: 53-77% on DynamoDB read/write capacity
Redshift Reserved Instances: Up to 75% on Redshift cluster nodes

We're focusing on the four general compute commitment types because they cover the bulk of most teams' compute spend.

Why Compute Savings Plans Replaced Convertible RIs

The biggest 2024-2026 shift in AWS commitment strategy: Compute Savings Plans replaced Convertible RIs for almost every use case. Here's why:

Feature	Compute Savings Plans	Convertible RIs
Apply to EC2	Yes	Yes
Apply to Fargate	Yes	No
Apply to Lambda	Yes	No
Cross-region	Yes	Yes (after exchange)
Cross-family	Yes (automatic)	Yes (manual exchange)
Cross-OS	Yes	Yes (after exchange)
Action required to remap	None (automatic)	Manual exchange
Discount	17-28%	18-54%

The 4-26 percentage point higher discount on Convertible RIs comes with significant operational burden: exchanges require active management, can fail under specific scenarios, and don't apply to Fargate or Lambda. In practice, the additional savings rarely materialize because most teams don't actively manage exchanges, leading to underutilization.

Recommendation: Don't buy Convertible RIs in 2026. If you have existing Convertible RIs, let them expire and replace with CSP.

Real-World Cost Modeling: Three Commitment Strategies

We modeled three actual portfolios. May 2026 pricing.

Workload A: Modern Cloud-Native SaaS ($50K/month compute baseline)

Mix of EC2 (40%), Fargate (35%), and Lambda (25%). Workloads evolve every 6-12 months as services migrate to Fargate or Lambda.

Strategy 1: All Standard RIs (Wrong Approach)

100% RI on current EC2 instances
1-year RI: $50K × 0.55 (45% discount on EC2 only) = $27,500/month savings on EC2 portion
But Fargate and Lambda not covered: full price
Underutilization risk: high (workloads shifting to Fargate)
Effective savings: 14-18% across total compute (low because RIs don't cover Fargate/Lambda growth)

Strategy 2: All Compute Savings Plans (Right Approach)

1-year CSP for $35K/month baseline (75th percentile of total compute spend)
Discount: 17%, applies across EC2 + Fargate + Lambda
Savings: $5,950/month
Above-baseline (variable): no commitment, full price
Effective savings: 12% across total compute, with zero underutilization risk

Strategy 3: Mixed CSP + Specific RIs (Optimal)

1-year CSP for $20K/month variable baseline (covers Fargate + Lambda + flexible EC2)
3-year Standard RI for $15K/month rock-solid EC2 baseline (specific m6i.xlarge running 24/7 for 3+ years)
CSP discount: 17% × $20K = $3,400/month
3-year RI discount: 50% × $15K = $7,500/month
Total savings: $10,900/month, 22% effective

Verdict at this profile: Mixed strategy wins. Pure CSP is safe but suboptimal. Pure RI is dangerous and unlikely to hit advertised savings.

Workload B: Legacy EC2-Heavy Enterprise ($200K/month compute, 95% EC2)

Predictable steady-state on m5 and r5 families. No Fargate, minimal Lambda.

Strategy 1: All Compute Savings Plans (Suboptimal)

$150K/month committed at 17% = $25,500/month savings
Effective: 12.75% on total compute

Strategy 2: EC2 Instance Savings Plans (Better)

$150K/month on m5/r5 EC2 Instance SP at 25% discount = $37,500/month savings
Slightly less flexible (locked to family + region) but workload is stable
Effective: 18.75% on total compute

Strategy 3: 3-Year Standard RIs On Stable Layer + 1-Year CSP On Variable (Optimal)

$80K/month on 3-year Standard RIs at 50% = $40K/month savings
$50K/month on 1-year CSP at 17% = $8,500/month savings
$20K/month variable: no commitment
Total savings: $48,500/month, 24% effective

Verdict at this profile: Standard RIs add real value when workload is genuinely stable. Mixed strategy with 3-year for the rock-solid baseline + 1-year CSP for the variable layer wins.

Workload C: AI/ML Heavy ($100K/month, 60% SageMaker, 40% EC2)

Modern AI infrastructure spending heavily on SageMaker for training.

Strategy 1: Compute Savings Plans Alone (Misses SageMaker)

$40K EC2 baseline on CSP at 17% = $6,800/month savings on EC2
$60K SageMaker: full price (Compute SP doesn't apply to SageMaker)
Effective savings: 6.8% on total compute

Strategy 2: SageMaker Savings Plans + Compute SP (Optimal)

$40K SageMaker SP at 28% (3-year all upfront) = $11,200/month savings
$30K EC2 on CSP at 17% = $5,100/month savings
$30K variable: no commitment
Total savings: $16,300/month, 16.3% effective

Verdict for ML workloads: SageMaker Savings Plans are a separate tier. Buy them for SageMaker baseline, then add Compute SP for everything else.

The Decision Framework: 5 Questions

Question 1: How modern is your compute mix?

Mostly EC2 with some Fargate (under 20%): EC2 Instance SP wins (better discount, workload-fit)
Mixed EC2 + Fargate + Lambda: Compute SP (only option that covers all three)
Mostly Fargate or Lambda: Compute SP (RIs don't apply)
Heavy SageMaker + other: SageMaker SP for ML + Compute SP for everything else

Question 2: How predictable is your workload?

Rock solid (will run same instance type for 3+ years): 3-year Standard RIs
Stable but evolving: 1-year EC2 Instance SP or Compute SP
Frequently changing (scaling up/down, migrating services): Compute SP only
Unpredictable / startup growth phase: Lower commitment ratio (50% vs 75%)

Question 3: What is your commitment risk tolerance?

Low (cash-strapped, uncertain runway): 1-year SP, no upfront
Medium (stable business): 1-year SP partial upfront or 3-year SP no upfront
High (cash-rich, certain trajectory): 3-year SP all upfront for maximum discount

Question 4: How well do you forecast?

Excellent (steady predictable growth): Higher commitment ratio (80-90% of baseline)
Good (some seasonality, manageable forecast): Standard 75th percentile
Limited (growing fast, unpredictable): Lower commitment ratio (50-65%)
Poor (constantly surprised by usage): Skip 3-year commitments entirely

Question 5: What is your business horizon?

Stable enterprise (7+ year horizon): 3-year commitments aggressive
Growth-stage SaaS: Mix 1-year + 3-year
Pre-revenue / experimental: 1-year only (preserve flexibility for pivot)
Acquisition-likely / pivot-likely: 1-year only (avoid sunk cost)

When Each Commitment Wins (Cheat Sheet)

Workload	Best Commitment	Discount	Why
Modern multi-tier SaaS (EC2 + Fargate + Lambda)	1-year Compute SP	17-19%	Cross-service flexibility
Stable 3-year EC2 baseline	3-year Standard RI	40-66%	Highest discount, workload-stable
Legacy EC2-heavy enterprise	3-year EC2 Instance SP	32%	High discount, family-locked OK
AI/ML training	3-year SageMaker SP	17-28%	Only thing that covers SageMaker
Bursty / variable workloads	No commitment + Spot	0% commit + 60-90% Spot	Don't commit to variability
Multi-region failover	Compute SP	17-28%	Region-flexible by design
Containerized microservices	Compute SP	17-28%	Family-flexible across migration
Database (RDS)	RDS Reserved Instances	30-69%	Different commitment program
DynamoDB high-throughput	DynamoDB Reserved Capacity	53-77%	Different commitment program
Redshift cluster	Redshift Reserved Instances	30-75%	Different commitment program
Lambda-only workloads	Compute SP	17-28%	Only thing that covers Lambda
Fargate-only workloads	Compute SP	17-28%	Only thing that covers Fargate

Sizing Your Commitment: The 75th Percentile Rule

The biggest commitment mistake: committing too high, then paying for capacity you don't use. The biggest opposite mistake: committing too low, leaving discount on the table.

The Right Methodology

Pull last 90 days of hourly compute spend (Cost Explorer + CSV export)
Calculate the distribution: minimum hour, p25, p50, p75, p90, p99, max
Commit at the p75 (75th percentile)

This means 75% of hours your usage is at or above commitment, leading to ~95% commitment utilization.

Why p75 Not p50 Or p90

p50 (median): You'd be over-committed half the time. Underutilization risk: 50%.
p75: You're under-committed 25% of hours but over-committed 75% of hours. Net utilization: ~95%.
p90: You're under-committed 10% of hours, over-committed 90%. But that 90% includes peak hours where commit doesn't add savings. Net utilization can drop to 85%.
p99: You're committing to peak only. Net utilization drops below 80%.

Real Example

A workload with hourly compute spend distribution:

p25: $30/hour
p50: $45/hour
p75: $60/hour
p90: $75/hour
p99: $90/hour

Commit at p75 ($60/hour):

Below $60: $30 × non-zero hours, you save the discount on what you're using up to $60
Above $60: $60 commitment hits, additional usage at full price (Spot or on-demand)
Net: ~95% of commitment utilized

Commit at p99 ($90/hour):

Below $90: most hours, lots of unused commitment (waste)
Above $90: rare, only some peak hours
Net: ~70% commitment utilized; you've paid for 30% of capacity you can't use

The math: p75 commitment captures 80-90% of available savings with 95% utilization. p99 commitment captures 95% of savings with 70% utilization, netting less actual savings.

Hidden Costs Most Commitment Strategies Miss

Hidden Cost 1: Non-Compute Commitment Sprawl

AWS has separate commitment programs for RDS, DynamoDB, Redshift, ElastiCache, OpenSearch, SageMaker. Each requires its own analysis. Teams commit to compute via SP and assume non-compute is "covered." It's not.

Mitigation: Audit each major service. RDS RIs save 30-69%. DynamoDB Reserved Capacity saves 53-77%. These are huge missed savings if ignored.

Hidden Cost 2: Region Lock-In On Older RIs

Older Standard RIs are locked to specific AZs (Availability Zones) which is even more restrictive than region. As you scale into new AZs, your RIs don't apply.

Mitigation: Convert to regional-scope RIs (free conversion) immediately on any RI you still hold.

Hidden Cost 3: OS Lock-In On RIs

Standard RIs are locked to OS (Linux vs Windows vs SUSE). If you change OS during the term, the RI doesn't apply.

Mitigation: Compute SP doesn't have OS lock-in. If you use Windows or might switch OS, prefer Compute SP.

Hidden Cost 4: Tenancy Lock-In On RIs

Default RIs are shared tenancy. Dedicated tenancy RIs are separate. Mixing creates underutilization.

Mitigation: Standardize on shared tenancy unless compliance requires dedicated. Don't mix.

Hidden Cost 5: Account-Level Application

In Organizations, RIs and SPs apply across linked accounts by default but have specific rules. Misconfigurations leave commitments idle in one account while another pays full price.

Mitigation: Verify Cost Explorer shows commitments applying across all accounts. Use Consolidated Billing properly.

Hidden Cost 6: ProsperOps and Similar Optimization Tools Charging % of Savings

Tools like ProsperOps automate commitment ladder management for 7.5-15% of savings achieved. The savings are real, but at scale the tool fee can rival the savings.

Mitigation: For commitment spend over $1M/month, build internal commitment management practice. ProsperOps fees compound at scale.

Hidden Cost 7: Cancellation Limitations

You cannot cancel a Savings Plan or Reserved Instance once purchased. Standard RIs can be sold on the Reserved Instance Marketplace (US accounts only). SPs cannot be sold. If you over-commit, you eat the cost.

Mitigation: Always buy conservatively. Better to under-commit and add later than over-commit and waste.

A 30-Day Commitment Audit

If your AWS commitment portfolio is over $500K/year, run this audit.

Week 1: Inventory

Pull all active commitments from AWS Cost Explorer (RIs + SPs)
Document term, type, instance family, region for each
Calculate utilization rate for last 90 days per commitment
Identify under-utilized commitments (under 80% utilization)

Week 2: Workload Analysis

Pull last 90 days of compute spend by service
Categorize: EC2 vs Fargate vs Lambda vs SageMaker
Calculate hourly distribution (p25, p50, p75, p90)
Identify the steady-state baseline at p75

Week 3: Strategy Reset

For under-utilized RIs: identify which can be converted (Convertible) or sold
For renewals: switch from RI to Compute SP unless workload is rock-solid
Calculate target commitment level using p75 rule
Plan upcoming purchases (1-year vs 3-year mix)

Week 4: Execute and Document

Purchase appropriate Compute SP for upcoming gaps
Document commitment strategy for ongoing review
Set up quarterly review cadence
Build cost allocation showing committed vs on-demand spend

After 30 days, expect 5-15% incremental savings on previously committed workloads, plus 15-25% savings on previously on-demand baseline.

When To NOT Buy Commitments

Avoid commitments when:

Pre-revenue / startup phase: Preserve cash flow. Commit only after 6+ months of revenue stability.
Acquisition or major pivot likely: 12-month commitments are minimum; major business changes break the math.
Aggressive cost optimization in progress: If you're rightsizing or migrating workloads, don't lock in current spend.
Workload is genuinely unpredictable: Some businesses have 5-10x usage swings; commitments waste capacity.
Heavy Spot reliance: Spot doesn't combine with commitments well; if 80% of workload is Spot, the 20% on-demand isn't worth committing.

For about 20% of teams we audit, the right answer is "don't buy commitments yet" or "reduce existing commitments."

When To Use ProsperOps Or Similar Automation Tools

Commitment management automation tools (ProsperOps, Spot.io commitment optimization) automate the buy/ladder/exchange cycle. They charge 7.5-15% of savings achieved.

Use them when:

Compute commitment spend exceeds $200K/month
Internal team lacks bandwidth for monthly commitment optimization
Workload changes frequently (more than quarterly)
You're managing multi-account commitment portfolios

Don't use them when:

Spend under $100K/month (fees exceed savings)
Stable workloads (manual management is enough)
Internal FinOps team has time for commitment management

ProsperOps' percentage-of-savings model means they charge more as you save more. For very large teams, this fee can hit $200K-$500K/year. Calculate carefully.

The Bottom Line

AWS commitment strategy in 2026 is dominated by Compute Savings Plans for most workloads, with Standard RIs only for rock-solid stable EC2 baselines and 3-year horizons. Convertible RIs are effectively dead. EC2 Instance SP fills a narrow niche. SageMaker SP is mandatory for ML-heavy teams.

The discipline most teams skip: quarterly commitment portfolio review. Workloads evolve faster than 1-year commitments. Without active review, commitments drift into underutilization within 12 months.

If you have AWS commitments and haven't reviewed them in the last 12 months, you are very likely losing 20-40% to underutilization. Our cloud cost optimization team runs free commitment audits and typically captures 15-30% additional savings within 60 days. Run a free Cloud Waste Scorecard to find your biggest commitment leaks first.

Further reading:

Frequently Asked Questions

Stop Overpaying for Cloud Infrastructure

Our clients save 30-60% on their cloud bill within 90 days. Get a free Cloud Waste Assessment and see exactly where your money is going.

Free Cloud Waste Assessment Our Services

Related Insights

View All

Cloud Cost Optimization

May 21, 2026

10 Ways Teams Overpay On AWS Fargate in 2026 (And How To Fix Each One This Week)

AWS Fargate is the second-most-overprovisioned compute service on AWS after Lambda. We audited 64 production Fargate deployments in 2025-2026 and found the average bill was 50% higher than necessary due to 10 specific waste patterns: missed ARM/Graviton, oversized task definitions, no Spot usage, missing Compute Savings Plans, unused capacity providers, and more. This is the fix list with real cost math for each.

Cloud Cost Optimization

May 21, 2026

Cold Storage Showdown 2026: S3 Glacier vs Google Archive vs Azure Archive vs Wasabi vs B2 (Decision Framework)

Most teams pick cold storage based on per-GB-month price, then get blindsided by retrieval fees, minimum durations, and access latency. We stored over 12 petabytes across 5 cold storage tiers (S3 Glacier Deep Archive, S3 Glacier Flexible/Instant Retrieval, Google Cloud Archive, Azure Archive, Wasabi, Backblaze B2) and modeled total cost across realistic compliance and DR scenarios. This is the decision framework that goes beyond storage price.

Cloud Cost Optimization

May 20, 2026

Cast AI vs Spot.io 2026: Automated Kubernetes Cost Tools Compared (We Saved a Client $720K/Year)

Cast AI and Spot.io are the two leading automated Kubernetes cost optimization platforms in 2026. We deployed both on production EKS clusters across 12 clients and found the cost gap for identical workloads averaged 40%. This is the head-to-head decision framework based on real production deployments, including pricing transparency that vendor pages obscure.

View All Insights