Both are commitments in exchange for a discount. The difference is what you are committing to, and how much room you leave yourself to change your mind.
The short version
Savings Plans commit you to a dollar amount of compute spend per hour. Reserved Instances commit you to specific capacity attributes. Savings Plans are simpler to manage and cover EC2, Fargate, and Lambda. Reserved Instances are still the only option for RDS, ElastiCache, Redshift, and OpenSearch, which is the detail most comparison articles leave out.
Savings Plans, in two flavours
- Compute Savings Plans — the flexible one. Applies across instance family, size, region, operating system, and tenancy, and covers Fargate and Lambda too. Change your architecture completely and the discount follows.
- EC2 Instance Savings Plans — locked to an instance family in a region. Bigger discount, less freedom. You can change size within the family, so an m6i.large to m6i.xlarge move is fine, but m6i to c7g is not.
The application is automatic. You commit to an hourly spend, AWS applies the discounted rate to whatever qualifying usage you run up to that amount, and anything above it bills on-demand. There is nothing to assign.
Where Reserved Instances still win
Beyond the services Savings Plans do not cover, there are two cases:
- Capacity reservation — a zonal RI reserves capacity in a specific Availability Zone. If you have a workload that absolutely must be able to launch in a particular AZ during a regional crunch, that guarantee is only available through an RI.
- An exit route — Standard RIs can be sold on the Reserved Instance Marketplace, subject to eligibility requirements. Savings Plans cannot be sold, cancelled, or transferred. Once you sign, you pay for the term.
Term and payment
One year or three, and no upfront, partial upfront, or all upfront. The discount rises with both commitment length and how much you pay in advance — AWS publishes maximums in the region of seventy-two percent for the most aggressive combination, though real coverage across a mixed estate lands well below the headline.
For most SMBs we work with, one year with no upfront is the sensible starting point. It preserves cash, and a three-year commitment on an architecture you are still changing is a bet on a version of your infrastructure that may not exist in eighteen months.
How much to commit
Look at hourly compute spend over the last three months and find the floor — the level it never drops below, including weekends and holidays. Commit somewhere around that, not at the average, and definitely not at the peak.
Under-committing costs you a little discount on the uncovered portion. Over-committing costs you real money for capacity you no longer run. The penalties are not symmetric, so err low and top up in a second purchase once you have watched coverage for a month.
A practical sequence
- Right-size first. Buying a commitment against over-provisioned instances locks in waste for a year.
- Retire whatever is idle. Same reason.
- Then buy a Compute Savings Plan at your floor, one year, no upfront.
- Add Reserved Instances for RDS and ElastiCache separately, since Savings Plans will not cover them.
- Check the coverage and utilisation reports in Cost Explorer monthly. Utilisation should sit close to a hundred percent; if it does not, you over-committed and the next purchase should be smaller.