For steady AWS compute, a Compute Savings Plan is the safer default: you commit to a spend per hour, and the discount follows your usage across instance families, sizes and Regions. A Reserved Instance (RI) commits you to a specific configuration, which can match or beat the discount but punishes you when the workload changes. On-Demand is the right answer only for usage you cannot predict. Which one wins depends on how likely your estate is to change over the term.
Savings Plans vs Reserved Instances at a glance
Both give a lower price in return for a one- or three-year commitment. The difference is what you commit to. AWS puts it this way: Savings Plans commit to “a consistent amount of compute usage (measured in $/hour), instead of specific instance configurations.”
| Compute Savings Plan | EC2 Instance Savings Plan | Convertible RI | Standard RI | |
|---|---|---|---|---|
| Maximum saving vs On-Demand (AWS) | Up to 66% | Up to 72% | Up to 66% | Up to 72% |
| What you commit to | $/hour of compute | $/hour for one instance family in one Region | One instance configuration | One instance configuration |
| Any instance family | Yes | No | Exchangeable | No |
| Any Region | Yes | No | No | No |
| Covers Fargate and Lambda | Yes | No | No | No |
| Changing it later | Nothing to change | Nothing to change within the family | Manual exchange | Marketplace resale only |
The figures come from AWS’s Savings Plans types and Reserved Instances pages. They are maximums, not averages. AWS gives average RI discounts of 40% (one year) and 60% (three years) for Standard, and 31% and 54% for Convertible. Your own figure depends on instance family, Region and payment option. The glossary has the definitions; this post is about choosing.
Where On-Demand still fits
On-Demand pricing has no commitment, which is its value. Keep it for new workloads whose size you do not yet know, projects with a defined end, and spiky capacity above your steady floor. The mistake is not using On-Demand; it is leaving stable production there by default because nobody owns the decision. We covered that inertia in Why Your AWS Bill Is Higher Than It Should Be.
A worked example: what happens when the estate changes
(Illustrative: the discounts are assumptions, not AWS prices.) A UK wealth manager has £4,000 a month of steady EC2 compute at On-Demand rates. It compares a three-year Standard RI at 60% off (AWS’s stated average) with a three-year Compute Savings Plan at an assumed 50% off.
| Scenario over 36 months | Standard RI | Compute Savings Plan |
|---|---|---|
| Monthly saving, nothing changes | £2,400 | £2,000 |
| 36-month saving, nothing changes | £86,400 | £72,000 |
| Half the fleet moves to a different instance family at month 18 | £50,400 | £72,000 |
In the second case, the RI covering the moved half keeps being paid for and covers nothing: £800 a month, or £14,400 over the remaining 18 months. The Savings Plan follows the usage to the new family and keeps its discount.
If nothing changes, the RI is £14,400 better. If half the estate changes, the Savings Plan is £21,600 better. A migration to Graviton, a move to containers or a rightsizing exercise all count as change. That is why the practical answer for most smaller firms is to commit to Savings Plans first, and use RIs only where the configuration is certain.
How to choose
| Your situation | Usually the better fit |
|---|---|
| Mixed or evolving estate; EC2, Fargate or Lambda | Compute Savings Plan |
| One instance family you will keep in one Region | EC2 Instance Savings Plan, for the higher discount |
| Need to change family or OS, and want RI-style pricing | Convertible RI, accepting manual exchanges |
| Fixed, long-lived workload with a known configuration | Standard RI or EC2 Instance Savings Plan |
| Databases (Aurora, RDS, DynamoDB and others) | Database Savings Plans: one-year term, up to 35% for serverless and 20% for provisioned instances |
| Variable, new or short-lived | Stay On-Demand |
Size the commitment before you buy
A commitment you cannot cancel needs careful sizing.
- Commit to the floor, not the average. Look at 12 months of hourly usage and commit to what you always use. Usage above the commitment is billed at On-Demand rates.
- Rightsize first. Committing to oversized instances locks in waste. See Right-Sizing Without the Guesswork and the rightsizing glossary entry.
- Use the recommendations, then sense-check them. Cost Explorer generates Savings Plans recommendations from your usage. Stagger purchases rather than buying everything in one day.
- Know the exclusions. AWS says a Savings Plan does not apply to Spot usage or usage already covered by RIs, “doesn’t provide capacity reservations”, and “can’t be cancelled during the term”. Capacity for a recovery Region needs an On-Demand Capacity Reservation.
- Use the safety valve. A Savings Plan with an hourly commitment of $100 or less can be returned within seven days, in the same calendar month, subject to your return limit.
- Tag first. Commitments are easier to defend when spend maps to owners. See Tagging Strategy 101.
Two points for UK finance firms
A multi-year commitment is a financial liability, so it needs the same sign-off as any other contract. AWS states Savings Plan commitments in dollars per hour (verify: how this appears on a GBP invoice and who carries the exchange-rate risk). And a Compute Savings Plan applies across Regions, so a disaster recovery warm standby or pilot light in a second Region can draw on the same commitment as production. Do not shrink recovery capacity to protect a discount.
The cost of waiting
Every month that steady usage stays on On-Demand is money you cannot get back. In the example above, the first month of delay costs £2,000 to £2,400. A commitment that matches your usage floor, reviewed quarterly, stops the clock.
A Yemberzal Cost Optimisation Audit works out your usage floor, tests which commitment type fits your estate, and prices each recommendation in pounds a month before you buy.
