The short answer
Savings Plans commit to an hourly spend and apply across instance families and regions, making them the safer default for changing estates. Reserved Instances commit to a specific configuration and can be sold on the marketplace, which suits stable, long-lived workloads. Cover roughly 70–80% of your steady-state baseline rather than 100%, so you retain the ability to keep shrinking.
Key takeaways
- Compute Savings Plans are the flexible default for most estates
- Reserved Instances suit stable workloads and can be resold
- Target 70–80% coverage of baseline, never peak
- Always right-size before committing to anything
Part of our guide to FinOps: how to actually reduce a cloud bill.
Both models offer a discount in exchange for a one or three year commitment. The difference is what you are committing to, and that difference decides which is safe for your estate.
Savings Plans commit to spend
A Compute Savings Plan commits you to a dollar amount per hour. Within that, you can change instance family, size, operating system, region, and move between EC2, Fargate and Lambda. The discount applies automatically to whatever qualifying usage exists.
That flexibility is the point. If you are still optimising — and after a migration you certainly are — a Compute Savings Plan lets you keep right-sizing and modernising without stranding the commitment.
EC2 Instance Savings Plans offer a deeper discount but pin you to a specific instance family in a specific region. Better rate, less room to move.
Reserved Instances commit to configuration
A Standard Reserved Instance commits to a particular instance type in a particular region. The discount is comparable to an EC2 Instance Savings Plan, with one meaningful advantage: Standard RIs can be sold on the Reserved Instance Marketplace if your needs change.
That resale option is genuinely useful for long-lived, stable workloads, and it is the main reason RIs still make sense despite Savings Plans being simpler.
Convertible RIs allow exchange for a different type but at a lower discount, which puts them in an awkward middle ground that Savings Plans generally occupy better.
How to choose
Use Compute Savings Plans when your estate is still changing, you are mid-migration or mid-optimisation, or you want one instrument covering EC2, Fargate and Lambda together. For most organisations this is the right default.
Use Reserved Instances when a workload is stable, long-lived, and unlikely to change instance family — a production database that has run the same way for two years — and you value the ability to sell the commitment if that changes.
Consider a mix. RIs for the genuinely fixed core, a Compute Savings Plan over the rest.
Coverage: aim below full
Cover your steady-state baseline, not your peak. Roughly 70–80% of baseline is a reasonable target for most estates.
Committing to 100% is a trap. It removes any benefit from further optimisation — every instance you subsequently right-size or retire leaves commitment unused, so the saving is cancelled out. Deliberately leaving headroom on demand keeps the incentive to keep improving.
Sequence, and payment terms
Right-size first. Let the estate settle for a few weeks. Then measure the new baseline and commit against it. Committing before optimising is how organisations end up paying, for three years, for capacity they proved they did not need.
On payment: all-upfront gives the deepest discount, no-upfront the shallowest, partial sits between. The gap is usually modest, so the decision is mostly about cash flow rather than optimisation.
Finally, revisit coverage quarterly. Commitments expire, baselines drift, and an unreviewed commitment strategy slowly stops matching the estate it was bought for.
