Azure gives you two commitment instruments for compute. A Reservation commits to a specific VM size in a region for one or three years and returns the deepest discount against pay as you go, but the discount only applies to that size unless you use the instance size flexibility within a family, so it rewards predictability and punishes change. The Azure Savings Plan for compute commits to an hourly dollar amount of spend for one or three years and applies automatically across eligible VM families, sizes, and regions, which makes it far more flexible but at a shallower discount than a like for like Reservation. The discounts are indicative and move, so confirm current figures on the Azure pricing page, but the ordering is stable: Reservation deeper, Savings Plan more flexible. The right answer is almost never one or the other. Cover the stable base of your forecast, the capacity you are confident you will run regardless, with Reservations for the depth, and cover the layer that shifts across families and regions with the Savings Plan so you keep the discount even as workloads move. Size both to a defensible forecast, not to today's peak, because both instruments make you carry the utilisation risk if the capacity goes unused.
Here is how each instrument is priced, what each costs you in flexibility, and the layered approach that fits most estates.
How does an Azure Reservation work?
A Reservation is a one or three year commitment to a specific VM size in a region, billed either upfront or monthly, that returns the deepest available discount on that capacity. Within a VM family, instance size flexibility lets the discount float across sizes in the same family in the same region, so a reservation for a given size can cover a mix of smaller and larger instances in that family by ratio. Reservations can be exchanged or, within limits, refunded, which softens the lock in, but the core trade stands: you get the largest discount in exchange for committing to a fairly specific shape of compute. They suit steady, long lived workloads whose size you can predict with confidence.
How does the Azure Savings Plan work?
The Azure Savings Plan for compute commits to a fixed hourly amount of compute spend, for one or three years, and applies that discounted rate automatically to eligible usage across VM families, sizes, and regions until the hourly commitment is met. Any usage beyond the commitment bills at pay as you go. Because the benefit floats across the whole eligible estate, you do not have to predict which family or region you will run, only how much steady compute spend you will sustain. The discount is shallower than a matched Reservation, which is the price of that flexibility. It suits workloads that shift across families and regions, autoscaling fleets, and estates in the middle of migration where the shape is uncertain but the floor of spend is reliable.
Which one fits which workload?
Match the instrument to the predictability of the workload. A database, a fixed application tier, or any long lived VM whose size you are confident about belongs under a Reservation, where the deeper discount rewards your certainty. A fleet that scales across sizes, a platform that rebalances across regions, or capacity you expect to migrate or rearchitect belongs under the Savings Plan, where flexibility protects the discount through change. Most estates have both kinds of workload, so the practical answer is a layered one: Reservations for the bedrock, Savings Plan for the part that moves.
| Dimension | Azure Reservation | Azure Savings Plan |
|---|---|---|
| Discount depth | Deeper | Shallower |
| Flexibility | Specific size and region, family flexibility within limits | Across families, sizes, and regions automatically |
| Commit shape | Capacity for a VM size | Hourly dollar amount of spend |
| Best for | Steady, predictable, long lived workloads | Variable or migrating workloads |
How much of the estate should you commit?
Coverage follows the forecast, not the discount. Plot your compute run rate and find the stable base, the level of usage you are confident you will run for the term regardless of what changes above it. Cover that base, and only that base, with commitments, leaving the variable top layer on pay as you go so an unexpected drop never leaves you paying for idle commitment. Within the covered base, weight toward Reservations for the part whose shape you can predict and toward the Savings Plan for the part that may move. Aim to be slightly under covered rather than over, because an under covered hour costs a little extra at pay as you go while an over covered hour is pure waste. This is risk adjusted coverage, the subject of the sibling guide on sizing reservation coverage linked below.
One year or three year, and how do you de risk it?
The three year term returns a larger discount than the one year on both instruments, but it locks you in longer, so the choice is a forecast confidence question. Use three year commitments for the part of the base you are most certain about and one year for the part you are less sure of, blending the two to match your real conviction. De risk further by using the Savings Plan's flexibility for anything uncertain, by exchanging Reservations when workloads shift rather than letting them strand, and by reviewing coverage and utilisation on a regular cadence so a change in the estate triggers a change in the commitment portfolio rather than a surprise at renewal.
A worked example
A European SaaS company ran a steady database and application tier alongside an autoscaling web fleet that frequently shifted VM families as it tuned performance. It had wrongly put everything under Reservations, then watched the fleet move off the reserved sizes and strand the discount. Restructuring to cover the steady tier with three year Reservations and the variable fleet with an Azure Savings Plan sized to the stable base of spend recovered the lost discount and removed the stranding, while leaving the volatile top layer on pay as you go. Effective savings rate rose materially with no change to the workloads themselves. Figures are verified against billing data and anonymised.
Frequently asked questions
Is the Azure Savings Plan better than Reservations?
Can I use Azure Reservations and a Savings Plan together?
How much of my Azure compute should I commit?
Build the right Azure commitment mix
We help Azure teams forecast the stable base, split coverage between Reservations and the Azure Savings Plan, and size both to a defensible forecast so you capture the discount without carrying idle commitment, across AWS, Azure, GCP, and OCI. We take zero provider commissions and answer only to you, on a Fixed Fee or a no risk Gainshare basis, with a simple guarantee: we reduce your cloud spend or we reimburse our service fee. Download the commitments playbook, and read the full Azure method below.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.