Commitment-based discounts are the single largest cost lever in cloud computing. Reserved Instances and Savings Plans can cut your compute bill by 30–72% compared to on-demand pricing. But buying the wrong one — or buying at the wrong time — locks you into a commitment that either underdelivers on savings or traps spend in coverage you can no longer use.
This article provides a practical decision framework for choosing between Reserved Instances and Savings Plans on AWS and Azure. Not theory — a sequence you can follow to build a commitment strategy that saves money without creating risk.
The fundamental difference
The distinction is simple, but it matters enormously:
Reserved Instances are a commitment to a specific instance type in a specific region. You're saying: "I will run this exact configuration for the next 1–3 years." If your workload changes — different instance family, different region, different operating system — your discount may no longer apply.
Savings Plans are a commitment to a dollar amount of compute usage per hour, regardless of instance type. You're saying: "I will spend at least £10/hour on compute for the next 1–3 years." The discount applies across instance families, regions, and even across services like Lambda and Fargate.
The simple version: Reserved Instances lock you to a configuration. Savings Plans lock you to a spend level. Both save money. The question is how much flexibility you need.
The comparison
| Reserved Instances | Savings Plans | |
|---|---|---|
| Discount | Up to 72% | Up to 66% |
| Commitment | Specific instance type, region, OS | Dollar amount per hour |
| Flexibility | Low (Standard) to Medium (Convertible) | High (Compute SP) to Medium (EC2 SP) |
| Term | 1 or 3 years | 1 or 3 years |
| Services covered | EC2, RDS, ElastiCache, OpenSearch, Redshift | EC2, Fargate, Lambda, SageMaker |
| Can resell | Yes (Standard RIs on marketplace) | No |
| Capacity reservation | Yes (Zonal RIs) | No |
The deeper discount on Reserved Instances comes at the cost of flexibility. If your workload is stable and predictable — same instance type, same region, running 24/7 for the foreseeable future — the extra 6% discount from an RI over a Savings Plan adds up. If your environment is evolving, that rigidity becomes expensive the moment you need to change.
When to use Reserved Instances
Reserved Instances are the right choice in specific scenarios:
Databases. RDS, ElastiCache, OpenSearch, and Redshift are not covered by Savings Plans. If you're running managed databases on AWS, Reserved Instances are your only commitment discount option. Database workloads also tend to be highly stable — you don't change your RDS instance type every quarter.
Capacity reservation. If you need guaranteed capacity in a specific Availability Zone — not just a discount, but the assurance that the instance will be available when you need it — only Zonal Reserved Instances provide this. Savings Plans have no capacity reservation component.
Stable, predictable EC2 fleets. If you run a large fleet of the same instance family that hasn't changed in 12+ months and won't change in the next 12, a Standard RI captures the maximum discount. The key word is "won't change" — if there's any chance you'll migrate to Graviton, switch regions, or resize, a Savings Plan is safer.
When to use Savings Plans
Savings Plans are the default choice for most organisations. Here's why:
Your compute mix changes. If you're modernising infrastructure, experimenting with Graviton instances, expanding to new regions, or adopting serverless (Lambda, Fargate), a Compute Savings Plan gives you the discount without locking you to a specific configuration. The discount follows your spend, not your instance type.
You're not sure what your environment will look like in 12 months. Most organisations can't predict their exact instance mix a year out. Savings Plans accommodate this uncertainty by committing to a spend level rather than a configuration.
You want simplicity. Managing Reserved Instance coverage across multiple instance types, regions, and accounts is operationally complex. Savings Plans apply automatically to your highest-discount-eligible usage first, with no manual matching required.
The decision framework:
Workload has run on the same instance type for 3+ months and won't change for 12+ more → Reserved Instance
Database workload (RDS, ElastiCache, Redshift) → Reserved Instance (only option)
Need guaranteed capacity in a specific AZ → Reserved Instance (Zonal)
Compute mix changes or may change → Compute Savings Plan
Confident in instance family but want region/size flexibility → EC2 Instance Savings Plan
Using Lambda, Fargate, or SageMaker → Compute Savings Plan
Not sure → Compute Savings Plan (safest default)
The sequence that matters most
The biggest mistake organisations make with commitment discounts is buying them too early. The correct sequence is:
1. Audit. Understand what you're actually running and what it costs. You can't commit intelligently without baseline data.
2. Rightsize. Resize oversized instances to match actual utilisation. A 40% discount on a 4xlarge you should have been running as an xlarge is still waste — you're paying 60% of the wrong price.
3. Eliminate idle resources. Terminate instances, volumes, and services that aren't being used. No point committing to spend on things that shouldn't exist.
4. Then commit. Now your remaining workloads represent actual demand. Commit to discounted pricing on this rightsized, cleaned-up baseline — not on the bloated environment you started with.
The most expensive commitment mistake: Buying Reserved Instances before rightsizing. You lock in a discount on oversized instances, which means you're paying less for waste — but you're still paying for waste. And you're locked in for 1–3 years. Always rightsize first, then commit.
How much to commit
The temptation is to cover 100% of your compute with commitments. Don't. The right coverage target is 70–80% of your steady-state baseline, with 20–30% left on-demand for flexibility, growth, and workloads that may change.
Here's how to calculate your baseline:
Pull 60–90 days of hourly on-demand compute spend. Not average — minimum. Your baseline is the lowest consistent spend level, not the typical one. Committing to your average means you're over-committed during low periods.
Commit to 70–80% of that minimum. This gives you a safety margin. If your minimum hourly spend is £50/hour, commit to £35–40/hour. The remaining £10–15/hour stays on-demand.
Review quarterly. Workloads change. What was your baseline six months ago may not be your baseline today. Reassess coverage every quarter and adjust as commitments expire.
The layering strategy
The most effective approach isn't choosing one or the other — it's layering them:
Layer 1: Compute Savings Plan (60–70% of baseline). This is your foundation. It covers your minimum compute spend with maximum flexibility. If anything changes — instance types, regions, services — the discount still applies.
Layer 2: EC2 Instance Savings Plans or Standard RIs (10–15%). For instance families you're confident won't change, add a second layer at the higher discount rate. This captures the extra savings on your most stable workloads.
Layer 3: Reserved Instances for databases (as needed). RDS, ElastiCache, and Redshift aren't covered by Savings Plans. Buy RIs specifically for these services based on their utilisation patterns.
Layer 4: On-demand and Spot (20–30%). Keep this buffer for growth, variable workloads, and anything that might change. Use Spot instances for fault-tolerant workloads (batch processing, CI/CD, dev environments) at 60–90% discount.
Azure: the same logic, different names
Azure uses different terminology but the same underlying concepts:
| AWS | Azure equivalent |
|---|---|
| Reserved Instances | Azure Reserved VM Instances |
| Savings Plans | Azure Savings Plan for Compute |
| Spot Instances | Azure Spot VMs |
Azure Savings Plans for Compute work almost identically to AWS Compute Savings Plans — you commit to a dollar-per-hour spend level and the discount applies across VM families, regions, and eligible services. Azure Reserved VM Instances lock you to a specific VM series and region, same as AWS RIs.
The decision framework is the same: rightsize first, commit to your stable baseline with Savings Plans, add Reserved Instances for specific workloads you're confident won't change, and keep a buffer on pay-as-you-go for flexibility.
The mistakes we see most often
Committing before rightsizing. The most common and most expensive mistake. You're locking in a discount on the wrong size. Always rightsize first.
Over-committing. Covering 100% of compute with commitments leaves no room for workload changes, growth, or architectural improvements. Target 70–80%, not 100%.
Ignoring utilisation after purchase. A commitment bought today may not match your environment in six months. Review coverage quarterly and plan new purchases as old ones expire.
Using RIs where Savings Plans would suffice. The extra 6% discount from a Standard RI is not worth the risk if there's any chance your workload configuration changes. For most compute workloads, the flexibility of a Savings Plan is worth more than the marginal extra discount.
Forgetting databases. Savings Plans don't cover RDS, ElastiCache, or Redshift. If your database spend is significant and stable, you're leaving money on the table by not buying database RIs.
The bottom line
Commitment-based discounts are not complicated. The decision comes down to: how confident are you that this workload won't change? High confidence means Reserved Instances for the deeper discount. Any uncertainty means Savings Plans for the flexibility. Databases always get RIs because there's no alternative.
But the sequence matters more than the choice. Audit, rightsize, clean up, then commit. Every organisation that skips the first three steps ends up locked into discounts on waste — paying less per hour for infrastructure they shouldn't be running at all.
Get the sequence right, and commitment discounts become the single biggest line item on your savings report. Get it wrong, and they become a 1–3 year reminder of a decision you can't undo.