Savings plan vs reservations
25 Sept 2026
Savings plans vs reservations: read the application order
Both instruments get explained as a slider. Reservations on the left: deeper discount, less flexibility. Savings plans on the right: shallower discount, goes anywhere. Pick a position, sign for three years.
That framing holds right up until you look at what the billing system actually does at the top of each hour. Then it stops being a preference and becomes a mechanism with a published order of operations — and the order has consequences that don't appear in anyone's comparison table.
Every hour, Azure sorts your eligible usage by how big the savings plan discount is — not by which workload you bought the plan for — and drains the commitment down that list until it's empty. Reservations are matched first, before the savings plan is touched at all. Nothing carries into the next hour. A reservation locks a rate; a savings plan locks a number of dollars, and the rate it buys is whatever the price list says that month.
One hour, in the order Azure drains it
Take a tenant with a $5.00/hour compute savings plan and one VM reservation still running. At 14:00, five things are billable. Here is the sequence the billing system runs, and it is the same sequence every hour of the term.
Four rules are doing the work in that picture, and all four are in the docs rather than in anyone's sales deck. Benefit is applied first to the product with the greatest savings plan discount, because that maximises the return on the commitment. Reservation benefits are matched before savings plan benefits, since they're more restrictive and usually deeper — spending the flexible thing first would strand the rigid one. Each hour is use-it-or-lose-it. And if you hold several plans, the three-year ones apply before the one-year ones, and the more narrowly scoped before the broadly scoped.
A savings plan locks the spend, not the price
This is the line that changes how the instrument should be described, and it sits in the same doc, two headings down: prices under savings plans are subject to change. Changes take effect on the first day of the month, and regardless of when the plan was purchased, current savings plan pricing is used when applying the benefit.
So the three-year commitment is a commitment to spend $5.00 an hour. It is not a commitment on Microsoft's side to sell you a fixed quantity of compute for that $5.00. A reservation says "this SKU, this region, this rate, for 36 months". A savings plan says "$43,800 of eligible compute at whatever the savings plan rate is when each hour is billed". Those are different kinds of promise, and only one of them is a hedge against price movement.
Worth knowing in the other direction too: if you have a negotiated consumption discount whose pay-as-you-go rate happens to beat the savings plan rate, Azure applies the lower of the two and decrements the commitment by the result. You don't get punished for the overlap — but you do burn commitment on usage the plan wasn't needed for.
Greatest-discount-first is not your-workload-first
The sorting rule is optimal for the invoice total. It is not a targeting mechanism, and the trade-in documentation says so about as plainly as Microsoft ever says anything: as a savings plan is a flexible benefit, there isn't a guarantee that the savings plan benefit always gets applied to usage from the resources that were previously covered by the reservations.
The practical shape of that: you trade a reservation on your production cluster for a savings plan, and next month the discount is landing on dev/test because dev/test happened to carry the higher savings plan rate that hour. The bill is no worse. But "our production VMs are covered" has quietly stopped being a true sentence, and any chargeback model built on it is now fiction.
Two more artefacts of the same engine. Utilisation can legitimately read above 100% — the billing system uses a best-fit model that keeps re-evaluating a given hour as usage arrives up to 48 hours later, so figures move under you for two days after the fact. And a savings plan covers infrastructure only: no software, no networking, no storage. It's also EA, MCA and MPA only; a subscription on any other offer type gets nothing.
The exit is where the two actually diverge
Everyone compares the discount. Almost nobody compares the door, which is where the asymmetry is severe enough to decide the question on its own.
| Reservation | Savings plan | |
|---|---|---|
| What it matches | A quantity of one SKU family, one region | Dollars per hour, any eligible service, any region |
| Applied | First | Second, highest-discount product first |
| Rate | Fixed at purchase | Whatever the price list says that month |
| Cancel / refund | Yes, capped at $50,000 per rolling 12 months | Never. No cancellation, no refund |
| Exchange | Until 1 Feb 2027, then one final exchange | Never — not for a reservation, not for another plan |
| Convert | Trade in for a savings plan, up to 100 at once | One-way. There is no route back |
Read the last two rows together. A savings plan is the most flexible thing Azure will sell you about where the discount lands and the least flexible thing it will sell you about whether you keep paying. The trade-in is a ratchet: compute and database reservations go in, savings plans come out, and nothing comes back.
The trade-in maths has a second edge. The new plan's total commitment must equal or exceed what was left on the reservation — eighteen payments into a $100/month three-year reservation, that's $1,800 — and the default hourly commitment Azure proposes is just that leftover spread across the new term. A $250 remainder on a one-year plan becomes about $0.029/hour, which covers essentially nothing. It is the floor of the transaction, not a sizing recommendation, and it's the number people accept by default.
Two instruments, two sizing questions
Sizing a reservation is a concurrency question: how many of this SKU are running simultaneously, hour by hour, and is the marginal instance matched often enough to clear break-even. Sizing a savings plan is a floor question: what is the lowest hourly compute cost this scope never drops below.
Azure's recommendation engine answers the second one, and it's more careful than it looks. It builds candidate commitments from your last 7, 30 and 60 days, runs hundreds of simulations per candidate, discards any that don't produce net savings, and surfaces up to ten. Then it runs the whole thing again on only the last three days and gives you the lower of the 3-day and 30-day answers — explicitly so that a decommissioned workload in stale data can't talk you into overcommitting.
Three caveats on the number it shows you. The portal's recommendations all use a 30-day lookback, so a quarterly-cycle workload is invisible to it. After you buy at one scope, recommendations at other scopes can take up to 25 days to adjust down — buy twice in that window and you commit twice for the same usage. And Microsoft's own advice is to leave at least 7 days between buying a reservation and buying a savings plan, for the same reason. Auto-renew, for what it's worth, defaults to off on savings plans.
All three assume something that usually isn't true: that you can see the hourly shape of compute spend across the estate before you commit. Both instruments are priced against that curve, and the portal only ever shows it to you per subscription, after the fact, one tab at a time. Right-sizing comes first regardless — a discount reduces the rate, never the waste, so the orphaned resource sweep belongs before any commitment, not after it.
- How a savings plan discount is applied — greatest-discount-first ordering, reservations applied before savings plans, hourly use-it-or-lose-it, the 48-hour best-fit window and utilisation above 100%, multi-plan ordering, and the monthly price-change rule.
- What are savings plans? — discounts vary by term and not commitment amount, the eligible service list, no software/networking/storage coverage, EA/MCA/MPA only, and the flat "purchases can't be canceled or refunded".
- Self-service trade-in for savings plans — the one-way ratchet, the 100-reservation cap, the remaining-commitment rule with its $1,800 example, the 1 February 2027 exchange change, the unchanged $50,000 cancellation cap, and the no-guarantee-of-targeting warning.
- Savings plan recommendations — the 7/30/60-day candidates, the simulation method, the 3-day overcommitment guard, the 30-day portal lookback, the 25-day cross-scope lag, and the $0.029/hour trade-in floor.
- Buy a savings plan — "unlike reservations, you can't cancel or exchange savings plans", and auto-renew defaulting to off.
- Decide between a savings plan and a reservation — the five-step order that puts right-sizing before any commitment, and the stable-versus-dynamic split.
GraphPaaS keeps Azure spend broken down by resource, type and resource group for every tenant you manage, with the month-by-month drill-down next to it — so "which of these workloads has been stable long enough to reserve, and what's the floor under the rest" is a question with a chart behind it rather than a portal tab and a guess.
See the shape of your Azure compute spend before you commit to three years of it.
See your Azure spend →