Reserved Instances or a Savings Plan: which saves you more?

Both cut the same bill. A reservation says "I will run this exact VM size in this exact region for a year"; a savings plan says "I will spend five dollars an hour on compute for a year" — and the price you pay for that second, easier promise is a shallower discount.

New to cloud? CAMPUX is a free, build-first course. Start here →

You are looking at a VM line on the bill that has read the same amount every month for six months. That steadiness is money you are leaving on the table, because Azure will trade you a lower rate for a commitment. There are two ways to make that commitment, and they are not the same deal. A reservation commits you to a specific resource. A savings plan commits you to a specific hourly spend. Everything else — how much you save, how much you can change your mind — falls out of that one difference.

The core trade, in one sentence each

Microsoft's own wording is clean, so use it. A reservation is "a commitment to use a specific type of compute instance or instance family, in a specific Azure region, for a set period of time," for example a D2v4 in Japan East for one year. A savings plan is "committing to a specific hourly expenditure on eligible compute services across all Azure regions," for example five dollars an hour for three years. The reservation is narrow and deep. The savings plan is wide and shallow. Both come in 1-year and 3-year terms, and both are billing constructs — they change what you are charged, not how the machines run.

How each one lands on the bill

A reservation only applies to the thing you reserved: that instance size, that region. When a matching VM runs, its usage is billed at the reserved rate; when nothing matches, the reservation sits idle and you have paid for a discount you did not use. A savings plan works differently. Every hour, Azure looks at your eligible compute usage, applies the discounted rate starting with the usage that saves the most, and draws it down against your hourly commitment until the commitment is spent. Anything above the commitment that hour is billed at normal pay-as-you-go. Anything you did not use that hour expires — it does not roll over. The savings plan does not care whether today's spend was a D-series VM in West Europe or a container app in East US; it applies across families, regions, and a broad set of compute services.

A reservation pays off when the exact machine you named is running. A savings plan pays off when any eligible compute is running. That is the whole difference, and it is why one discounts harder.

Which one to reach for

Pick a reservation when the workload is boring in the best way: it runs continuously, on a size you are not going to change, in a region you are not going to leave. A production database VM that has looked identical for a year is the textbook case. Fully utilized, that is where the deepest discount lives. Pick a savings plan when the workload moves — you resize VMs, you shift families, you spread across regions, you swap one compute service for another. You lose some discount depth, and in exchange the benefit follows your spend instead of chasing a machine you might delete next month. In practice a mature estate runs both: reservations under the stable floor, a savings plan over the churn on top.

Both need a baseline, and that is your job to find

Neither instrument is free money. Each is a one-way promise: reservations can be exchanged and savings plans cannot be cancelled, so a commitment sized above your real steady-state usage is money you have pre-spent on capacity you will not run. The whole game is finding the baseline — the floor of usage that is genuinely always on — and committing to that, not to your busy-week peak. This is squarely a cloud engineer's work. Someone reads the bill, spots the lines that never move, right-sizes away the waste first, and only then buys a commitment against what is left. Discounts reduce your rate; they do not reduce waste, and buying one on top of an oversized VM just locks the waste in for a year. Get the baseline right before you sign anything.

If this is new territory, start upstream. Knowing where Azure spend actually leaks tells you what is safe to commit to, and wiring up budgets and alerts tells you the moment reality drifts from the baseline you bought against.

The takeaway

Reservations and savings plans both beat pay-as-you-go on steady usage; they differ in what you promise. A reservation ties you to a specific size and region for the deepest cut and the least room to move. A savings plan ties you to a dollar-per-hour spend that follows your compute across families, regions, and services, for a smaller but far more forgiving discount. Stable and known goes to reservations; mixed and evolving goes to savings plans; and both only pay off on a baseline you have measured, not guessed. Reserve the floor, savings-plan the churn, and size both to usage you have actually measured. Buy it that way and the discount is real money; buy it against a number someone guessed and you have simply pre-paid for capacity that never runs.

Questions people also ask

What is the difference between an Azure reservation and a savings plan?

A reservation commits you to a specific instance type or family in a specific region for a 1-year or 3-year term, and it carries the deepest discount. A savings plan commits you to a fixed hourly dollar spend on eligible compute across families and regions for the same terms, trading some discount depth for flexibility as your workload moves.

Are Azure reservations worth it?

A reservation is worth it when a workload runs continuously on a size and region you do not expect to change, since a fully-used reservation cuts the most off pay-as-you-go. It is not worth it when the machine sits idle or you delete it early, because you have prepaid for a discount on usage that never shows up.

Can you cancel an Azure savings plan?

No. Once you buy a savings plan you cannot cancel it or exchange it for a reservation, so every purchase is final for the full term. Reservations are more forgiving: you can exchange them, and Azure allows cancellation for a prorated refund within its limits. Size a savings plan to usage you are confident stays steady.

Can you use reservations and savings plans together?

Yes, and a mature estate usually does. Azure applies a matching reservation first, then draws remaining eligible usage against the savings plan, so the two layer instead of competing. You reserve the stable floor that never moves for the deepest cut, then put a savings plan over the churn on top to catch the compute that shifts.

Which one saves more, a reservation or a savings plan?

For the same fully-used workload, a well-matched reservation usually saves more than a savings plan, because a narrow commitment discounts harder than a flexible one. Both beat pay-as-you-go on steady usage. The catch is the same for each: the saving only appears if the baseline usage is genuinely there, so measure the floor before you commit.