Azure Reservations: when the 3-year lock is actually right

Reserved instances get sold on one number — up to 72% off — and refused on one fear: what if we don't use it. Both sides of that conversation are working from the wrong model. The arithmetic of a reservation is unusually forgiving on utilisation and unusually unforgiving on everything else, and almost nobody does it before signing.

Five questions, answered with the arithmetic and the policy rather than the sales deck.

Do I need high utilisation to justify a reservation?

No, and the reason is a single line of arithmetic that the portal never shows you.

Reservations are applied on an hourly basis. Buying one more reserved instance costs you the reservation rate for 24 hours a day, every day, whether anything matches it or not. It saves you the pay-as-you-go rate for each hour something does match. So the marginal instance is worth buying when:

hours matched ÷ 24  >  reservation rate ÷ pay-as-you-go rate

The right-hand side is just 1 − discount. A 62%-off reservation breaks even at 38% utilisation. A 40%-off one needs 60%. The deeper the discount, the more slack you're allowed — which is the opposite of how the three-year term is usually described.

What does that look like on a real day?

Take a compute profile of the shape most of us actually run: a handful of instances overnight, a working-day plateau, a mid-afternoon peak of 13. Total usage across the day, 166 instance-hours. Assume 62% off.

That configuration throws away 70 of its 216 reserved instance-hours — 68% utilisation — and it is still the cheapest of the three obvious choices. Reserving at the overnight floor of 3 wastes nothing and saves 27%. Reserving at the peak of 13 covers everything and saves 29%. Reserving at 9, with a third of it visibly going to waste, saves 38%.

The reason is the break-even line. Instance number 9 is matched 10 hours out of 24 — above the 9.1-hour threshold, so it pays. Instance number 10 is matched 8 hours, below it, so it doesn't. The optimum is the last instance that clears the bar, and at a deep discount that lands well short of full utilisation.

Two honest caveats. The pay-as-you-go rate in that comparison is the compute rate: a Reserved VM Instance covers infrastructure only, and you're still charged separately for Windows per vCPU, for storage, for networking and for any additional software. And the discount is use-it-or-lose-it per hour — an unused reserved hour at 03:00 does not pay for the burst at 14:00. Stopped VMs, incidentally, keep consuming reservation hours; only deallocated or deleted ones free the quantity up for something else.

So what am I actually risking with three years?

Not the waste. The door.

Until recently the answer to "what if the workload changes" was: exchange it. That answer has an expiry date. Microsoft's policy note is explicit — starting 1 February 2027, reservations purchased after that date aren't eligible for exchange if the service is covered by savings plans, which is to say Virtual Machines, App Service, SQL Database and their neighbours. Reservations bought before that date keep the right to one final exchange. Azure VMware Solution and other services savings plans don't cover are excluded from the change.

The refund door is narrower still, and it was always narrow: cancelled commitment can't exceed 50,000 USD in a rolling 12-month window per billing profile or enrollment. Microsoft's own worked example makes the consequence concrete — a three-year reservation at 3,000 USD/month is a 108,000 USD commitment, and you cannot cancel it at all until you've already spent 58,000 USD of it. There is no early termination fee today, but the docs reserve the right to a 12% one.

Exchanges have a matching catch even while they last: the new reservation's total commitment must be equal to or greater than the remaining commitment of the old one. Eighteen months into a 100 USD/month three-year term, you owe 1,800 USD, so you can only exchange into something worth at least 1,800 USD. An exchange is a way to change your mind about what you bought, never about how much.

What if the VM size changes?

That one Azure handles well, inside limits worth knowing before you pick a SKU. With instance size flexibility on, the discount floats across every size in the same flexibility group, weighted by a published ratio. A DS4_v2 reservation has a footprint of 8, so it covers eight DS1_v2s, or two DS2_v2s plus a DS3_v2, or half of one DS5_v2.

The wall is the group boundary. DSv2 and "DSv2 high memory" are different groups — a D-series reservation does nothing for a DS11_v2. Premium-storage and non-premium sizes are likewise separate, so a Standard_D1 reservation won't touch a Standard_DS1. You can't change a reservation's flexibility group after purchase; you can only exchange out of it. Which brings you back to the door that closes in February 2027.

Which workloads should never be reserved?

Microsoft's recommended sequence is worth quoting straight, because it is an order of operations and most teams run it backwards: right-size first, exchange underutilised reservations, trade in the ones that no longer fit, then buy new reservations for the stable remainder, then a savings plan on top. Reservations last, not first.

Where the inputs come from

Every number in this article is a property of your own usage, not of a price list. The hourly shape is the only input that matters and it's the one nobody plots before committing — the portal shows utilisation of reservations you already bought, which is the wrong direction. Before the purchase you want the hourly concurrency curve; after it, you want utilisation alerts pointed at the break-even threshold rather than at 100%.

GraphPaaS keeps Azure spend broken down by resource, type and resource group per tenant, alongside the month-by-month drill-down — so the "is this workload stable enough to lock for three years" question has an answer with a chart attached, across every customer at once rather than one portal tab at a time.