AWS Reserved Instances and Savings Plans both give you discounts in exchange for a 1- or 3-year commitment. The discount rates are similar — 30–72% off on-demand, depending on how you commit. The mechanisms are meaningfully different.
One is a promise about what you will run; the other is a promise about what you will spend. That distinction decides what happens to your bill in month fourteen, when the architecture has moved on and the commitment has not.
Where they are the same
Both come in 1-year and 3-year terms. Both offer All Upfront, Partial Upfront and No Upfront payment, and the more you pay up front, the deeper the discount. Both apply automatically to matching usage. Both are, once purchased, irreversible. Everything that follows is about what “matching usage” means, and what you can do when it stops matching.
Reserved Instances
You commit to a specific instance type, in a specific region (or Availability Zone for zonal RIs). The discount is maximally applied when your usage matches the commitment exactly. Zonal RIs also give you capacity reservations — a meaningful benefit if you're in a capacity-constrained region.
The risk: if you change instance type (for right-sizing, for a new generation, for a different workload), you're carrying a commitment that no longer maps to your usage. You can sell Standard RIs on the Marketplace, but not Convertible RIs, and the Marketplace isn't always liquid.
Standard vs Convertible
Standard RIs give the larger discount and the least flexibility. Regional Linux RIs with default tenancy get size flexibility within the family — an m6i.xlarge reservation covers two m6i.large — but you cannot move to a different family. When the next generation arrives cheaper per unit of work, your m6 reservation covers nothing unless you keep m6 running to consume it.
Convertible RIs solve exactly that: you can exchange them for a different family, OS or tenancy, provided the new reservation is of equal or greater value. The cost is a smaller discount and — the part people miss — no exit. A Convertible cannot be listed on the Marketplace. Flexibility to change, not flexibility to leave.
Zonal RIs and capacity
A zonal RI is the only commitment product that actually holds hardware for you. If something must scale back up in a specific AZ after a failover, or you have seen InsufficientInstanceCapacity errors in your region, that guarantee is worth more than a few points of discount. For everything else, zonal scope is a restriction you pay for without using: no size flexibility, no coverage if the workload lands in a different AZ.
The Marketplace, honestly
The RI Marketplace works, but it needs a buyer who wants your exact instance type, in your region, for the remaining term, at a price that suits them. Popular types in big regions sell. An unusual type in a smaller region can sit unsold for months. Treat it as partial recovery, not a plan.
Savings Plans
You commit to a spend rate ($/hour) rather than a specific instance. Compute Savings Plans apply across any instance family, region, or OS — the most flexible. EC2 Instance Savings Plans are more restrictive but offer a slightly higher discount.
The risk: the commitment is financial rather than capacity. You don't get capacity reservations. In a crunch, AWS prioritises on-demand customers with reservations first.
Compute vs EC2 Instance
A Compute Savings Plan is the closest thing AWS sells to “just give me a discount on whatever I run”. It follows you across families, sizes, regions, operating systems and tenancy, and it also covers Fargate and Lambda. If you are part-way through moving from instances to containers, that matters: an RI bought for the old fleet becomes dead weight as the fleet shrinks, while a Compute plan moves with the spend.
An EC2 Instance Savings Plan locks you to one family in one region, with flexibility on size, OS and tenancy inside that. The discount is a few points better. It is the right choice when a family is staying put — a database tier on r6g nobody will touch — and the wrong choice for anything that might get right-sized.
How the commitment is consumed
Savings Plans are applied hour by hour, highest-discount usage first, until the committed dollars are used up. Anything above the commitment is billed On-Demand. Anything below it is wasted: commit to $10 an hour, run $7 of eligible compute, pay $10. That is the whole risk in one sentence, and why sizing the commitment matters more than choosing between the two products.
There is no Marketplace for Savings Plans and no exchange. You hold to term.
Capacity without RIs
If you need guaranteed capacity but want Savings Plan flexibility, On-Demand Capacity Reservations hold hardware in an AZ independently of any discount, and a Savings Plan or regional RI will discount the reserved capacity. You pay whether you use it or not, so reserve only what genuinely needs a guarantee.
What we recommend
For most teams: Compute Savings Plans for baseline coverage, On-Demand for burst, and zonal Reserved Instances only for workloads with specific capacity reservation needs.
Buy in tranches. Don't commit 100% of your baseline in one purchase. Buy 40% of your forecasted coverage, run for 60 days, then buy more. The 60 days of data will correct your forecast, and the incremental approach prevents over-commitment if your workload changes.
The best commitment is the one you would still be happy with after the architecture review you have not had yet.
Term and payment
Default to 1-year No Upfront. The 3-year discount is real, but three years is longer than most architectures stay still, and the extra points rarely cover the commitment you no longer need in year three. Go to 3-year, and to upfront payment, only for the layer of spend you are certain about — and be honest about how much that is.
Two numbers to watch
- Utilisation — how much of what you committed to is being consumed. Anything under 100% is money spent on nothing. This is the number that tells you whether you over-bought.
- Coverage — how much of your eligible usage is discounted. This tells you whether the next tranche is due. Leave real headroom for burst; don’t chase the last few percent.
Both are in Cost Explorer. Check them monthly. A commitment can quietly stop making sense after a right-sizing pass, and the bill will not tell you — utilisation will.
Before you commit
- Right-size first. Never buy a discount on an instance you should have shrunk. Commitments lock in whatever inefficiency exists on the day you buy them.
- Finish any migration that is already in flight — to a new generation, to Graviton, to containers — before committing to the old shape.
- Take the baseline from at least a month of steady-state usage, and take the lowest hour of that month, not the average.
- Buy the first tranche. Set a calendar reminder for 60 days. Look at utilisation before you buy the second.
None of this is complicated. It is just slower than the recommendation button, which is the point. The button optimises for coverage today. You are optimising for not regretting it next year.
