Updated 18 Oct 2026 • 7 mins read
Azure Savings Plan vs Reservations: How to Choose
Azure reservations discount up to 72 percent and lock a VM family and region; savings plans discount up to 65 percent and follow compute wherever it runs. This decision guide covers the real discounts below the headlines, application order, cancellation and the February 2027 exchange change, a per-workload matrix, and how Opslyft tracks coverage and utilization.
Microsoft gives the Azure savings plan versus reservation decision two numbers, up to 72 percent and up to 65 percent, and almost everyone who makes the decision on those numbers gets it wrong. Both are ceilings reached on specific SKUs over three years; the discount on the general-purpose VM you actually run is usually far lower and the gap between the two instruments on that VM is often wider than seven points. The decision that matters is not which discount is bigger but which commitment you can keep: a reservation pays more and holds you to a family and a region, a savings plan pays less and follows your compute wherever it goes, and the rules for getting out of either are tightening, with reservation exchanges disappearing for most compute from February 2027.
This guide covers how each instrument actually works, what the real discounts look like on common SKUs, how Azure applies them together, the cancellation and exchange rules as they stand and as they will stand in 2027, and a per-workload decision matrix. It is the Azure-specific companion to our comparison of Reserved Instances, Savings Plans, and Spot, and it sits inside the wider levers in our Azure cost optimization guide. Terms are from Microsoft's savings plan and reservations pages as of October 2026.
The short answer: An Azure reservation commits to a specific VM family in a region for one or three years and discounts qualifying VMs by up to 72 percent; a savings plan for compute commits to a fixed hourly spend and discounts eligible compute by up to 65 percent while following the workload across families, regions, and services. On common SKUs the real gap is wider than the headlines: a three-year reservation on a D8s v5 in East US is about 62 percent off, a three-year savings plan about 34 percent, and a one-year savings plan often 11 to 20 percent. Azure applies reservations first, then savings plans. A savings plan cannot be cancelled or exchanged; a reservation can be cancelled with a 12 percent fee under a $50,000 rolling-year refund cap, and from February 1, 2027 reservations for savings-plan-covered services lose exchange rights. Choose reservations for workloads that will provably keep their family and region for the term, savings plans for compute that is steady in spend but not in shape, and run both: reservations on the stable baseline, a savings plan over the remainder.
How Each Instrument Works
Reservations
An Azure reservation is a one- or three-year commitment to a specific resource configuration: for VMs, a family (with instance size flexibility within the family group), a region, and a quantity. In exchange the hourly rate for matching usage falls by up to 72 percent on qualifying VMs, with the deepest discounts on memory-optimized families over three years. Reservations exist for far more than VMs, including SQL Database, Cosmos DB, storage, and Databricks units, and they can be scoped to a subscription, a resource group, or shared across an enrollment. Unused reserved hours expire each hour; the commitment bills whether the matching VM runs or not.
Savings plans
An Azure savings plan for compute is a one- or three-year commitment to a fixed dollar amount per hour, say $20, that Azure applies automatically to eligible compute: VMs of any family, size, region, and OS, Dedicated Hosts, App Service, Functions Premium, and Container Instances and Apps. Each hour, Azure applies the commitment to whatever eligible usage yields the largest percentage discount first, up to the committed amount; usage beyond it bills at pay-as-you-go. Discounts reach up to 65 percent on three-year terms for specific SKUs and are considerably lower on others. A separate savings plan for databases, one year only, discounts SQL Database, Cosmos DB, PostgreSQL, and MySQL by up to 35 percent.
Side-by-Side
| Dimension | Reservation | Savings plan for compute |
|---|---|---|
| Commitment | Specific VM family, region, quantity, 1 or 3 years | Fixed $ per hour, 1 or 3 years |
| Headline discount | Up to 72% (qualifying VMs, 3 years) | Up to 65% (3 years; lower on most SKUs) |
| Example, D8s v5 East US, 3 years | About 62% | About 34% |
| Flexibility | Size within the family group; region and family fixed | Any family, size, region, OS, and eligible service |
| Covers | VMs plus many non-compute services (SQL, Cosmos, storage) | Compute services only; databases via a separate 1-year plan |
| Applied | First, to matching usage | Second, to remaining eligible usage, highest discount first |
| Unused commitment | Expires each hour | Billed each hour |
| Cancellation | Prorated refund, 12% fee, $50,000 cap per rolling 12 months | None |
| Exchange | Allowed until Feb 1, 2027; reservations bought after that date for savings-plan-covered services cannot be exchanged; earlier ones keep one final exchange | None; trade-in of a reservation to a savings plan remains possible |
| Stacks with Hybrid Benefit | Yes | Yes |
| Best for | Workloads that will keep their family and region for the term | Compute that is steady in spend but may change shape |
The exchange row is the one to read twice. Reservations have historically been the safer commitment because a wrong family could be exchanged for a right one; that safety valve closes for most compute in February 2027, and after that a reservation on the wrong shape is a cancellation with a fee under a cap, or a trade-in to a savings plan. The practical effect is that the reservation's extra discount has to be earned by genuine shape certainty, which is the whole decision.
The Real Discounts, Not the Headlines
Both ceilings are reached on specific families and terms, and the general-purpose VMs most estates run sit well below them. On a Standard D8s v5 in East US, independent analysis puts the three-year reservation near 62 percent off pay-as-you-go and the three-year savings plan near 34 percent, a 28-point gap, while a one-year savings plan runs roughly 11 to 20 percent and a one-year reservation about 35 to 40 percent. Two consequences follow. A savings plan's flexibility is paid for with real money on every hour it covers, so it should cover only the compute whose shape is genuinely uncertain. And the comparison has to be made per SKU in the Azure pricing calculator, because the gap on your workload may be much larger, or smaller, than seven points.
How to Choose, Workload by Workload
| Workload | Choose | Why |
|---|---|---|
| Production databases and steady application tiers on a fixed family | 3-year reservation | Shape will not change; the extra 20 to 30 points of discount are real money |
| Compute that will migrate families or regions during the term | Savings plan | The discount follows the move; a reservation would strand |
| Workloads moving to App Service, Functions, or containers | Savings plan | Covers those services; a VM reservation does not |
| Windows and SQL Server estates with owned licences | Either, plus Hybrid Benefit | Licence reuse stacks with both; often the larger saving |
| Year-one estates still settling | 1-year savings plan on a conservative baseline | Lowest regret; grow coverage as the shape stabilizes |
| Non-compute services (SQL Database, Cosmos, storage) | Reservations, or the 1-year database savings plan | Compute savings plans do not cover them |
| Interruptible batch and dev/test | Neither; Spot VMs | Up to 90 percent off with no commitment |
The portfolio most mature Azure estates settle on is both: three-year reservations on the baseline that has not changed in a year, a savings plan over the variable compute above it, Hybrid Benefit everywhere a licence qualifies, and Spot for what can be interrupted. Buy in tranches, size each commitment to the trough of sustained usage rather than the average, and ladder expiries so no single renewal is a cliff. The sizing discipline is the same one in our EC2 Instance Savings Plan playbook; the Azure-specific addition is to treat the 2027 exchange change as a reason to be more conservative with reservations, not less.
A Worked Example
An Azure estate spends $380,000 a month on compute: about $220,000 on a stable production platform of D- and E-series VMs that has not changed family or region in 18 months, $90,000 on application tiers that the team plans to move from VMs to App Service and Container Apps over the next year, and $70,000 of variable and non-production usage. Nothing is committed.
Following the matrix: three-year reservations sized to 80 percent of the production platform's trough cover about $175,000 of monthly usage at roughly 55 to 60 percent off for that mix, saving about $100,000 a month. A three-year savings plan sized to 70 percent of the application tiers' trough covers about $63,000 at roughly 30 to 35 percent off, saving about $21,000 and, critically, following that spend when it moves to App Service. Hybrid Benefit on the Windows and SQL Server instances adds about $18,000. The non-production usage goes to Spot and schedules. Monthly spend falls from $380,000 to about $225,000, 41 percent, with no stranded commitment: the reservations sit on shape that will not move, and the savings plan sits on shape that will.
How Opslyft Does This
Every step above depends on two numbers that most teams buy commitments without: coverage, the share of eligible usage a commitment is discounting, and utilization, the share of each commitment actually consumed. Opslyft measures both on allocated data across the estate. Explorer shows Azure spend by team, subscription, and service with the effective rate after reservations, savings plans, and Hybrid Benefit, so the stable baseline a reservation should cover and the variable remainder a savings plan should cover are visible as measured troughs rather than guesses, and under-covered growth running at pay-as-you-go is visible before the quarter ends. Canvas puts coverage and utilization by business unit on finance's screen and by team on engineering's, from the same numbers.
Atlas keeps the inventory of VMs and the commitments that cover them with an owner on each, and its change history shows the family or region change that stranded a reservation, with the team that made it. Monitor alerts the owner in Slack when a commitment's utilization drops, when growth is running uncovered, and when a term is approaching expiry, so the 2027-era decision, renew, trade in, or let lapse, is made on time rather than discovered. Tickets routes each renewal and right-sizing decision to the owner in Jira, ServiceNow, or Asana and records the saving, and Iris answers which commitments are under-utilized and why in plain English. Commitments stop being bought blind, which is the failure mode the brief for this page names.
That estate-wide view across Azure, AWS, GCP, and Snowflake is what Innovaccer built with Opslyft, cutting cloud cost by 30 percent and improving its MRR-to-cloud-cost ratio by 35 percent with commitments and budgets managed per customer.
The Bottom Line
Azure savings plans and reservations are not competing discounts; they are two commitments with different exit doors, and the right one for a workload depends on whether its shape will hold. Reserve what will provably keep its family and region for the term, because the extra discount is large and real. Cover what might change with a savings plan, because the discount follows the spend and a reservation would strand, especially once exchanges end in February 2027. Stack Hybrid Benefit on both, send interruptible work to Spot, buy in tranches sized to the trough, and measure coverage and utilization continuously so the portfolio is rebalanced rather than regretted. That measurement is what Opslyft's cost governance provides across Azure and every other cloud you run; for the rest of the Azure levers, see our Azure cost optimization guide and Azure cost management guide.
FAQs
A reservation commits to a specific resource, such as a VM family in a region, for one or three years, for a discount of up to 72 percent on qualifying VMs. A savings plan for compute commits to a fixed hourly dollar spend for one or three years and applies automatically across any eligible compute, VMs of any family and region, Dedicated Hosts, App Service, Functions Premium, Container Instances and Apps, for a discount of up to 65 percent. Reservations discount deeper and lock the shape; savings plans discount less and follow the workload.
The reservation. When the same usage is eligible for both, Azure applies the compatible reservation first because it is narrower and usually deeper, then applies the savings plan to the remaining eligible usage up to the hourly commitment, prioritizing whatever usage yields the largest discount each hour. Both stack with Azure Hybrid Benefit for Windows and SQL Server licences.
A savings plan cannot be cancelled, refunded, or exchanged; you can only buy more. Eligible reservations can be cancelled for a prorated refund with a 12 percent early-termination fee, capped at $50,000 of refunded commitment per billing profile or enrollment in a rolling 12 months. Reservation exchanges are being withdrawn: from February 1, 2027, reservations bought on or after that date for services a savings plan covers cannot be exchanged, and those bought before keep one final exchange.
Less than the 65 percent headline for most SKUs. The ceiling applies to specific families and terms; a three-year savings plan on a common general-purpose VM such as a D8s v5 in East US runs closer to 34 percent, where a three-year reservation on the same SKU is about 62 percent, and a one-year savings plan is often 11 to 20 percent. Check the discount for your actual SKU and region in the Azure pricing calculator before choosing on the headline.
When the workload will provably run the same VM family in the same region for the whole term: production databases, steady application tiers, and anything already stable for a year. The reservation's extra 20 to 30 percentage points of discount on that SKU is worth more than flexibility you will not use, and instance size flexibility within the family absorbs resizing.
When the compute is steady in spend but not in shape: workloads that may change family, move region, shift to App Service or containers, or be re-platformed during the term. The savings plan follows the spend wherever it goes, which removes the stranded-commitment risk that a reservation carries, especially now that exchanges are being withdrawn. Most estates use both: reservations on the stable baseline, a savings plan over the variable remainder.
Opslyft tracks commitment coverage and utilization across the estate on allocated data, so the stable baseline a reservation should cover and the variable remainder a savings plan should cover are measured rather than guessed, and under-utilized or expiring commitments surface with an owner. Explorer shows Azure spend by team and subscription with the effective rate after commitments, Monitor alerts when utilization drops or a commitment is about to expire, and Tickets routes the renewal decision to the owner.