Commitment discounts are one of the biggest levers in cloud cost optimisation. They are also one of the easiest places to make an expensive mistake. Buy too little and you overpay On-Demand rates. Buy too much, or the wrong type, and you pay for capacity you do not use.
This guide compares Reserved Instances vs Savings Plans on AWS, explains when each makes sense, and shows how to build a commitment strategy that balances savings and risk.
Buy too much, or the wrong type, and you pay for capacity you do not use.
What are AWS Savings Plans?
A Savings Plan is a commitment to spend a fixed amount per hour (for example, $10/hour) on compute for a 1- or 3-year term, in exchange for a discount on that usage. There are three types:
Commitment coverage on baseline cloud usage
Illustration in progress
- Compute Savings Plans apply to EC2 in any Region, family, size, OS or tenancy, plus AWS Fargate and AWS Lambda. Most flexible.
- EC2 Instance Savings Plans apply to a specific instance family in a specific Region, with a deeper discount.
- SageMaker Savings Plans apply to eligible SageMaker usage.
What are Reserved Instances?
A Reserved Instance (RI) is a billing discount applied to a matching instance configuration, such as an m6i.large running Linux in ap-south-1. RIs come in two classes:
- Standard RIs offer the highest discount but limited flexibility. They can be sold on the RI Marketplace.
- Convertible RIs can be exchanged for different configurations, at a smaller discount.
Reservations still matter for managed services. Amazon Redshift and some ElastiCache engines use reserved nodes, and RDS reserved instances can still beat the newer Database Savings Plans, which cover RDS, Aurora, DynamoDB, ElastiCache for Valkey, OpenSearch Service and more for up to 35% off on a one-year term.
Reserved Instances vs Savings Plans: side-by-side
| Factor | Compute Savings Plan | EC2 Instance Savings Plan | Standard RI | Convertible RI |
|---|---|---|---|---|
| Commitment | $/hour | $/hour, one family + Region | Specific configuration | Specific configuration |
| Flexibility | Highest | Size, OS, AZ | Low | Exchangeable |
| Discount depth | Good | Deepest (tied) | Deepest (tied) | Moderate |
| Covers Fargate/Lambda | Yes | No | No | No |
| Covers RDS, ElastiCache | No (Database Savings Plans do) | No (Database Savings Plans do) | Yes (service RIs) | Varies |
| Resale | No | No | RI Marketplace | No |
AWS publishes maximum discounts of up to 66% for Compute Savings Plans and up to 72% for EC2 Instance Savings Plans and Standard RIs, compared with On-Demand. Actual savings depend on term, payment option and instance type.
When should you use Savings Plans?
Choose Compute Savings Plans when:
- Your architecture is still evolving (new instance generations, containers, serverless)
- You run workloads across multiple Regions
- You use Fargate or Lambda heavily
- You want low-maintenance coverage without managing many individual reservations
When should you use Reserved Instances?
Choose Reserved Instances when:
- You run stable databases or caches on RDS, ElastiCache, OpenSearch or Redshift
- You have very predictable EC2 workloads that will not change family or Region
- You want the option to resell unused capacity (Standard RIs)
How do you build a commitment strategy?
A good commitment strategy is gradual and data-driven:
Layered Savings Plan purchase strategy
Illustration in progress
- Rightsize and clean up first. Remove idle and oversized resources so you do not commit to waste. See why AWS bills run high.
- Measure your baseline. Look at the minimum steady compute spend over the last 30–90 days.
- Cover the baseline, not the peak. Target coverage of your steady usage, leaving spikes on On-Demand or Spot.
- Layer purchases. Buy in tranches every month or quarter instead of one large purchase. This spreads expiry dates and reduces risk.
- Track utilisation and coverage weekly. Utilisation shows whether you are using what you bought; coverage shows how much eligible spend is discounted.
- Use Spot for fault-tolerant work. Batch jobs, CI runners and stateless workers are good Spot candidates.
How does Azure compare?
Azure offers both Azure Reservations (for VMs, SQL Database, Cosmos DB and more) and an Azure savings plan for compute that works much like AWS Compute Savings Plans. Combined with Azure Hybrid Benefit for existing Windows Server and SQL Server licences, the stacking can be substantial. Our Azure cost optimisation checklist covers this in detail.
How Crozaint approaches commitments
In Crozaint FinOps engagements, commitment planning happens in the Optimization phase (weeks 6–8), after visibility and cost allocation are in place. That order matters: commitments bought on top of clean, allocated data are far less risky.
Our AI Cost Optimization Agent tracks coverage, utilisation and upcoming expiries continuously, so renewals are decisions rather than surprises. Clients see an average 27% reduction in cloud spend, with commitments typically one of several contributors alongside rightsizing and waste removal.
Common mistakes to avoid
- Committing for 3 years on workloads planned for re-architecture
- Buying to cover peak usage instead of baseline
- Letting large commitments all expire on the same day
- Forgetting databases: Compute Savings Plans do not cover RDS or ElastiCache, so they need reservations or Database Savings Plans
- Never reviewing utilisation after purchase
Conclusion
Savings Plans and Reserved Instances are complementary tools. Clean up first, commit to your baseline, layer your purchases and review utilisation weekly.
Not sure how much to commit? Book a 30-minute discovery call and we will look at your usage with you.
