AWS Savings Plans vs Reserved Instances - Discounts Without Lock-In Risk
Your AWS bill grows month on month. At some point someone on the team asks: “Should we buy Reserved Instances?”. That is the right moment to stop and think about what you are actually buying and what commitment you are taking on.
The problem is that AWS now has two discount mechanisms that overlap in scope but differ in flexibility. The wrong choice means either wasting money (committing to infrastructure you will not need next year) or leaving savings on the table (being too cautious when the data clearly shows a stable baseline).
How Reserved Instances Work
Reserved Instances are the older of the two mechanisms. They have existed since 2009 and for years were the only way to get discounts on AWS.
The Principle
You purchase a commitment for a specific configuration:
- Instance type (e.g. m5.xlarge)
- Region (e.g. eu-west-2)
- Term (1 year or 3 years)
- Payment option (All Upfront, Partial Upfront, No Upfront)
In return you receive a discount from 30% (1 year, No Upfront) to 72% (3 years, All Upfront) compared to on-demand pricing.
Types of Reserved Instances
| RI Type | Flexibility | Discount (1Y / 3Y) | Use Case |
|---|---|---|---|
| Standard RI | None - exact instance type + region | ~40% / ~60% | Stable production, known configuration |
| Convertible RI | Can change instance type (exchange) | ~33% / ~54% | When you anticipate generation changes (e.g. m5 → m6i) |
Important Feature: Size Flexibility
Standard RI within the same instance family (e.g. m5) automatically distributes across different sizes. One RI for m5.2xlarge covers:
- 2× m5.xlarge
- 4× m5.large
- 8× m5.medium
This is normalisation via a size factor. It works automatically within the same region and family.
Where RI Still Makes Sense
- RDS Reserved Instances - Savings Plans do not cover RDS. If you have stable databases, RI is the only discount mechanism.
- ElastiCache Reserved Nodes - similarly, no Savings Plans coverage.
- OpenSearch Reserved Instances - same situation.
- Redshift Reserved Nodes - the only discount option.
For these services there is no alternative. RI is the only mechanism available.
How Savings Plans Work
Savings Plans (introduced in 2019) are the newer mechanism. Instead of committing to a specific instance, you commit to a minimum spend level per hour (expressed in USD/h).
The Principle
You declare: “For the next 1 (or 3) years I will spend at minimum X USD per hour on compute”. Everything up to that level is billed at the discounted rate. Everything above - at on-demand pricing.
Types of Savings Plans
| SP Type | Scope | Flexibility | Discount (1Y / 3Y, All Upfront) |
|---|---|---|---|
| Compute Savings Plans | EC2, Fargate, Lambda | Any family, size, region, OS, tenancy | ~33% / ~54% |
| EC2 Instance Savings Plans | EC2 only | Any size within family + region | ~40% / ~60% |
| SageMaker Savings Plans | SageMaker only | Any SageMaker instance type | ~20% / ~64% |
The Key Difference: Compute SP vs EC2 Instance SP
Compute Savings Plans are the most flexible option:
- Change regions? Discount still applies.
- Move workload from EC2 to Fargate? Discount still applies.
- Migrate from m5.xlarge to m6i.2xlarge? Discount still applies.
- Shift some compute to Lambda? Discount still applies.
EC2 Instance Savings Plans give a higher discount but lock you to an instance family and region. If you are confident that for the next year you will not change either region or family, this is the better option.
Comparison: Savings Plans vs Reserved Instances
| Dimension | Reserved Instances (Standard) | Compute Savings Plans | EC2 Instance SP |
|---|---|---|---|
| Discount (3Y All Upfront) | ~60-72% | ~54% | ~60% |
| Lock-in: region | Yes | No | Yes |
| Lock-in: instance family | Yes | No | Yes |
| Lock-in: size | No (Size Flex) | No | No |
| Covers Fargate | No | Yes | No |
| Covers Lambda | No | Yes | No |
| Covers RDS | Yes (separate RDS RI) | No | No |
| Marketplace (resale) | Yes (Standard RI) | No | No |
| Modification mid-term | Convertible: yes, Standard: no | No (but unnecessary) | No (but unnecessary) |
Real-World Calculation
Scenario: UK SaaS Company, Infrastructure in eu-west-2 (London)
Stable production infrastructure:
- 3× m6i.xlarge (EC2, application) = 3 × $0.192/h = $0.576/h
- 2× r6i.large (EC2, caching layer) = 2 × $0.126/h = $0.252/h
- 1× db.r6g.xlarge (RDS PostgreSQL) = $0.348/h
- Fargate tasks (average usage) = ~$0.15/h
Total on-demand: ~$1.326/h = ~£770/month = ~£9,240/year
Option A: Reserved Instances Only
- EC2 RI (1Y, All Upfront) for m6i.xlarge × 3 and r6i.large × 2: ~40% discount
- RDS RI (1Y, All Upfront) for db.r6g.xlarge: ~40% discount
- Fargate: no discount (RI does not cover Fargate)
Savings on EC2 + RDS: ~£3,350/year Cost after discount: ~£5,890/year
Option B: Compute Savings Plans + RDS RI
- Compute SP at $0.978/h (covers EC2 + Fargate): ~33% discount (1Y)
- RDS RI for db.r6g.xlarge: ~40% discount
Savings on compute: ~£2,250/year (lower % but covers Fargate) Savings on RDS: ~£970/year Total savings: ~£3,220/year Cost after discount: ~£6,020/year
Option C: EC2 Instance SP + RDS RI (Recommendation)
- EC2 Instance SP at $0.828/h (covers EC2, m6i + r6i family, eu-west-2): ~40% discount
- Compute SP at $0.15/h (covers Fargate separately): ~33% discount
- RDS RI for db.r6g.xlarge: ~40% discount
Total savings: ~£3,500/year Cost after discount: ~£5,740/year
The difference between options is ~£280/year. On a ~£9,200/year budget that is less than 3%. Flexibility matters more than a few extra percentage points.
Purchase Strategy - The Layered Approach
Do not buy commitments covering 100% of your infrastructure. The optimal approach is covering 60-80% of stable baseline and leaving 20-40% on-demand (flexibility for peak load, experiments, changes).
Step 1: Identify Your Baseline
In AWS Cost Explorer navigate to Savings Plans > Recommendations. AWS analyses the last 7/30/60 days and suggests the optimal commitment level.
Alternatively, in Cost Explorer set granularity to “Hourly” and find the minimum spend level that holds steady over the past 30 days. That is your safe baseline.
Step 2: Choose Your Commitment Layers
| Layer | Mechanism | Coverage | Purpose |
|---|---|---|---|
| 1 (stable) | EC2 Instance SP (3Y) | 40-50% of baseline | Maximum discount on certain infrastructure |
| 2 (flexible) | Compute SP (1Y) | 20-30% of baseline | Cover Fargate/Lambda + buffer for changes |
| 3 (databases) | RDS / ElastiCache RI | Production DBs 24/7 | Only discount option for managed databases |
| 4 (on-demand) | No commitment | 20-40% peak | Flexibility, autoscaling, dev/test |
Step 3: When 1 Year, When 3 Years?
3 years (higher discount, higher risk):
- Production databases (engine/size rarely changes)
- Core infrastructure that has existed for >12 months without significant changes
- Organisation does not plan migration to another cloud or to containers within 3 years
1 year (lower discount, minimal risk):
- Infrastructure growing rapidly (startup in growth phase)
- Planning architecture changes within 12-18 months
- Uncertainty about future requirements
Rule of thumb: if you are torn between 1Y and 3Y, choose 1Y. The cost of getting it wrong at 3Y is three times higher.
Pitfalls and Common Mistakes
1. Buying Commitments for Dev/Test
Development environments should be shut down outside working hours. If dev runs 10h/day × 5 days/week (30% utilisation), a 24/7 commitment wastes 70% of the discount.
Better approach: Instance Scheduler (automatic shutdown) + on-demand or Spot Instances.
2. Ignoring Spot Instances
Before buying any commitment, check whether your workload can run on Spot. Spot gives 60-90% discount with zero commitment. For batch processing, CI/CD, ML training - Spot is cheaper than 3-year RI.
3. Committing to an Old Generation
AWS regularly introduces new generations (m5 → m6i → m7i). Each new generation delivers better performance at a lower price. If you buy 3-year RI on m5, you lock yourself to an older generation.
Solution: Compute Savings Plans, which automatically cover new generations.
4. Not Monitoring Utilisation
After purchasing RI/SP, check regularly:
- Savings Plans Utilization Report - what percentage of your commitment is actually used?
- Savings Plans Coverage Report - what percentage of spend is covered by discounts?
- RI Utilization - are all RI actively used?
Target: utilisation >90%. If it drops below 80%, you have over-committed.
5. All Upfront Without Necessity
Paying upfront (All Upfront) gives an additional 5-8% discount. But it freezes cash. For a startup with limited liquidity, No Upfront (slightly lower discount, zero frozen capital) is often the better choice.
Calculation: 3Y All Upfront at $1/h = ~$15,000 upfront. With No Upfront you pay $0.95/h (5% more expensive), but you do not freeze £12k.
Decision Matrix - When Savings Plans, When RI
| Situation | Recommendation | Rationale |
|---|---|---|
| EC2 + Fargate + Lambda (mix) | Compute Savings Plans | Covers everything with one commitment |
| EC2 only, stable family and region | EC2 Instance SP | Higher discount than Compute SP |
| RDS, ElastiCache, OpenSearch, Redshift | Reserved Instances | SP does not cover these services |
| Dynamic infrastructure (frequent changes) | Compute SP (1Y, No Upfront) | Minimal risk, flexibility for changes |
| Startup in growth phase (>50% YoY) | Short SP (1Y) covering 40-50% baseline | Baseline is growing, avoid over-commitment |
| Stable business (growth <10% YoY) | Mix of 3Y SP (60%) + 1Y SP (20%) | Maximum savings with low risk |
| Migration planned within 2 years | 1Y SP only or no commitments | Do not lock in before migration |
AWS Cost Explorer - Using the Recommendations
AWS automatically generates Savings Plans recommendations based on your usage history. Find them at:
Cost Explorer → Savings Plans → Recommendations
Parameters worth adjusting:
- Lookback period: 30 days (default) or 60 days (better for seasonal workloads)
- Term: 1 year (safer) or 3 years (if infrastructure is stable)
- Payment option: No Upfront (preserve cash flow) or All Upfront (maximum discount)
- Plan type: Compute (flexible) or EC2 Instance (higher discount)
AWS will show:
- Recommended commitment amount ($/h)
- Estimated monthly and annual savings
- Estimated coverage (%)
Treat these recommendations as a starting point, not a final decision. AWS does not know about your migration plans, architecture changes, or seasonality.
Savings Plans and Multi-Cloud Strategies
If you are considering moving part of your workload to Azure or GCP within the next 2-3 years, a 3-year commitment on AWS is risky. Even Compute Savings Plans with all their flexibility do not transfer to another cloud.
Recommendation for organisations with multi-cloud plans:
- Maximum 1-year commitments
- Coverage of maximum 50% baseline (rest on-demand)
- Regular review every 6 months
For organisations certain they will stay on AWS:
- 3-year commitment on stable baseline is a safe decision
- 54-60% savings vs on-demand significantly impact the IT budget
UK-Specific Considerations
Region Selection: eu-west-2 (London)
For UK organisations, eu-west-2 is typically the primary region. When purchasing EC2 Instance Savings Plans, this region lock is usually acceptable because:
- Data residency requirements (UK GDPR, FCA regulations) keep workloads in London anyway
- Latency to UK users is optimal (<5ms vs 15-25ms from Ireland)
- Most organisations will not move production workloads out of eu-west-2
However, if you use eu-west-1 (Ireland) for disaster recovery or cost reasons, a Compute Savings Plan covers both regions without issue.
Currency Considerations
AWS bills in USD. For UK organisations budgeting in GBP, exchange rate fluctuation adds an invisible cost layer. The GBP/USD rate has moved 10-15% year-on-year in recent periods.
Options to manage this:
- Set budget alerts in both USD (actual) and GBP (estimated at current rate + 10% buffer)
- Consider All Upfront payments when GBP is strong relative to USD (locks in a favourable rate)
- Some organisations use currency hedging for large 3-year commitments
Summary - Recommendation
For most UK organisations using AWS, the optimal strategy in 2026 looks like this:
- Compute Savings Plans (1Y) as the main commitment - covers EC2 + Fargate + Lambda, gives full flexibility to change region and instance family
- RDS Reserved Instances (1Y or 3Y) for production databases - no alternative exists
- Spot Instances for batch processing, CI/CD, ML training - 60-90% discount with zero commitment
- On-demand for dev/test + peak load - flexibility without waste
This combination delivers 35-50% reduction in total AWS spend without the risk of paying next year for infrastructure you no longer need.
How We Can Help
At Devopsity we design FinOps strategies for organisations on AWS. A typical engagement includes:
- Cost audit (1 day) - identify quick savings and establish baseline for commitments
- SP/RI recommendation (1-2 days) - analyse usage history, select optimal commitment combination
- Monitoring setup (1 day) - utilisation dashboards, alerts on unused RI, budget controls
- Quarterly review (ongoing) - adjust commitments as infrastructure evolves
Overpaying for AWS?
Book a free 30-minute technical consultation. No pitch - a conversation about your environment and potential savings.
Frequently Asked Questions
Can Savings Plans be cancelled before the term ends?
No. Savings Plans are a 1 or 3-year commitment and cannot be cancelled. If your usage drops below the commitment level, you still pay the minimum amount. This is why you should only commit to a stable baseline, never to peak.
Do Savings Plans cover RDS?
No. Savings Plans cover only compute (EC2, Fargate, Lambda, SageMaker). For RDS, ElastiCache, OpenSearch, and Redshift, the only discount option is Reserved Instances.
Can I have both RI and Savings Plans at the same time?
Yes. AWS applies RI first (more specific), then SP (more general), then bills the rest at on-demand. This is the standard approach: RI for databases + SP for compute.
What is the minimum Savings Plans amount?
The minimum is $0.001/h (~$0.73/month). In practice, purchasing SP below ~$0.10/h (~$73/month) makes little sense because savings are minimal while administration overhead remains the same.
When is Spot better than Savings Plans?
Spot gives 60-90% discount with zero commitment, but the instance can be interrupted at any moment. Spot is better for workloads that tolerate interruptions: CI/CD, batch processing, ML training, rendering. For production servers that must run 24/7 without interruption, SP/RI is the right choice.
