Azure Reservations are a resource-based commitment discount. You commit to using a specific type of resource — a particular VM size, in a particular region, for 1 or 3 years — and Microsoft gives you a discount of up to 72% compared to pay-as-you-go pricing in return for that predictability.
The mechanic is straightforward: you give Microsoft certainty about your future demand, and they give you a lower price for it. The reservation sits in your account and automatically applies its discount whenever a matching resource runs within its scope — no manual intervention needed.
Reserved Instances vs Reserved Capacity: Azure uses "Reservations" as the umbrella term, but within that you'll see two patterns. Reserved Instances refers to compute resources (VMs, App Service, AKS). Reserved Capacity refers to data services (Azure SQL, Cosmos DB, Storage, Redis). The buying mechanic is similar but the commitment attributes differ by service. Reserved Capacity for data services is covered on the Reserved Capacity page.
If you would like to learn more about Reservations and Savings Plans the below video where we talk with Obinna Nwokolo from the Microsoft Commercial team may be interesting to you.
How Azure Reserved Instances Work
When you purchase a reservation, you're not reserving a specific virtual machine — you're reserving the right to run a specific configuration of resource at a discounted rate. If you purchase a 1-year reservation for a Standard_D4s_v5 VM in UK South, Azure will apply that discount to any Standard_D4s_v5 VM running in UK South on your account, within the scope of the reservation, for the duration of the term.
There is no link between the reservation and any specific resource. Azure matches reservations to running resources automatically each hour. If a matching resource is running, the discount applies. If nothing matching is running, the reservation hour is wasted — you've still paid for it.
Characteristic | Details |
|---|---|
Commitment type | Specific resource — VM size, region, OS, and term |
Term | 1-year or 3-year |
Payment options | All upfront, Partial upfront, or Monthly |
Scope | Management group, Shared (all subscriptions), Single subscription, Resource group |
Maximum discount | Up to 72% vs pay-as-you-go (varies by VM family, region, and term) |
Application | Automatic — applied each hour to matching running resources |
Unused reservation | Each unused hour is lost — there is no rollover |
Cancellation | Allowed, with a 12% early termination fee on remaining value (up to $50k/year across all commitments) |
Exchange | The exchange facility is intended to be ended but is currently still active and will be advised when/if a new end date is introduced. |
What Services Use Reserved Instances
Azure Reservations (Reserved Instances) cover a wide range of services. The most commonly used and highest-impact are compute resources, where the discount rates are largest:
Service | What you commit to | Typical discount vs PAYG |
|---|---|---|
Virtual Machines & Virtual Machine Scale Sets | VM series, size, region, OS (Windows/Linux) | Up to 72% |
Azure Dedicated Host | Host SKU and region | Up to 57% |
Azure App Service (Isolated v2 & Premium V3) | Stamp fee reservation by region | Up to 55% |
Azure Kubernetes Service | VM nodes (node pool VM size and region) | Same as VM rates |
Azure VMware Solution | Node type and region | Up to 52% |
For data services (Azure SQL Database, Cosmos DB, Redis, Synapse, Storage), Azure uses a similar mechanism called Reserved Capacity. This works on the same principles but the commitment attributes are service-specific — covered on the Reserved Capacity page.
Scope — Where the Discount Applies
Reservation scope determines which subscriptions and resource groups can benefit from the discount. Getting scope right is important — too narrow and you waste reservation coverage; too broad and you lose cost attribution clarity.
Scope | Discount applies to | When to use |
|---|---|---|
Shared (billing account) | All subscriptions under the billing account | Most efficient for organisations with multiple subscriptions — discount pools across all eligible usage automatically |
Management group | All subscriptions within the management group and its children | Useful for limiting scope to a specific organisational unit while still pooling across its subscriptions |
Single subscription | Resources in one specific subscription only | When chargeback requires discount to be attributed to a specific team or cost centre |
Resource group | Resources in one specific resource group only | Narrow attribution use case — rarely the right choice for efficiency |
For most organisations, Shared scope is the right default. It maximises the chance that each reservation hour is matched to running usage, which is the most efficient outcome. If you need to attribute the discount to a specific team for chargeback, this can be handled through cost allocation rather than by restricting reservation scope.
Instance Size Flexibility for VMs
For most VM families, Azure offers Instance Size Flexibility (ISF) — the reservation can apply to any size within the same VM series and generation, not just the specific size you purchased. This is an important feature that makes VM reservations less brittle.
For example, if you purchase a reservation for a Standard_D8s_v5 and later scale down to Standard_D4s_v5 instances, the reservation still applies — the D4s_v5 has a lower ISF ratio, so the reservation would cover two D4s_v5 instances instead of one D8s_v5. If you scale up to a D16s_v5, the reservation covers half the cost of that one instance and the rest is pay-as-you-go.
ISF is on by default for most VM families, but not all. Isolated-series VMs and some specialised VM types do not have Instance Size Flexibility. Check whether ISF applies when purchasing reservations for non-standard VM families.
ISF does not apply across different VM series (D-series to E-series, for example), and it does not flex across regions. A reservation purchased for UK South stays in UK South.
Architect's Perspective — Getting Reservations Right
Reservations only make sense for stable, predictable workloads
A reservation that runs at 60% utilisation isn't saving you money — it's just spending it differently. The core requirement for a reservation to deliver value is that the committed resource configuration runs consistently, close to 24/7, for the duration of the term. If a workload scales significantly, gets decommissioned, or changes VM family, you're left holding a reservation that's either partially wasted or fully wasted.
Before purchasing a reservation, ask: will this workload run at this size in this region for the next 1–3 years with high confidence? If the answer is yes, a reservation is the right tool. If there's significant uncertainty, a Savings Plan gives you more flexibility for a slightly lower discount rate.
Start with utilisation analysis, not intuition
Pull your VM cost data for the last 90 days from Azure Cost Management. Filter to resources that ran continuously (or near-continuously) without significant size changes. Those are your reservation candidates. Azure Cost Advisor will also generate reservation recommendations based on your actual usage — these are a useful starting point, though you should validate them against your understanding of workload roadmaps before committing.
Layer reservations and Savings Plans
Reservations give a higher discount rate than Savings Plans for the same VM configuration, but are less flexible. The recommended approach is to cover your most stable, identifiable workloads with reservations first, then use a Savings Plan to provide a discount floor across remaining variable compute. Azure applies reservation discounts before Savings Plan discounts — the two mechanisms stack.
Scope to Shared unless you have a specific reason not to
Shared-scope reservations are more efficient because the discount pools across all subscriptions. A reservation that can't find a matching resource in subscription A might find one in subscription B. If you restrict to single subscription, any hours where that subscription doesn't have matching usage are wasted. Reserve at the widest appropriate scope and handle cost attribution separately through tagging and allocation.
Understand what happens at term end
Reservations do not auto-renew by default. When the term expires, the resource reverts to pay-as-you-go pricing — which can cause a sudden cost increase that surprises teams who've forgotten a reservation was in place. Build reservation expiry dates into your FinOps calendar. If you want to auto-renew, configure this at purchase time, but be aware the renewal will be at the same commitment without revisiting whether the workload has changed.
Common Optimisation Strategies
Identify low-utilisation reservations immediately
After purchasing reservations, set up utilisation monitoring. Any reservation running consistently below 100% utilisation is either not matched to the right workload or covering a workload that has changed since purchase. Investigate quickly — the earlier you identify waste, the more time you have to adjust (including cancellation if the reservation is relatively new).
Don't over-reserve — start conservative and add
It's better to purchase a reservation that covers 80% of your stable workload and pay pay-as-you-go on the remainder than to purchase one sized for peak usage that runs at 60% average utilisation. You can always purchase additional reservations. You cannot easily reduce an over-sized commitment.
Use Shared scope and manage attribution through tagging
Don't use narrow reservation scope to achieve cost allocation. Use Shared or management group scope for efficiency, and apply consistent resource tagging to allow reservation savings to be distributed back to the right teams through cost allocation tooling. Restricting scope to achieve attribution is the wrong trade-off — you'll waste reservation coverage to solve an accounting problem.
Review reservations when workloads change
Any significant infrastructure event — cloud migration, application re-architecture, regional expansion, decommission — should trigger a reservation review. Reservations purchased against a previous architecture may no longer match current usage. A regular quarterly review of reservation utilisation, upcoming expiry dates, and workload changes is good FinOps practice.
Align reservation terms to your planning horizon
A 3-year reservation offers meaningfully higher discounts than a 1-year reservation (typically 15–25% more), but requires high confidence over a longer horizon. For new workloads or environments in transition, start with 1-year. Once a workload has demonstrated stability through one term, renewing on a 3-year basis is usually the right cost decision.
How Can Turbo360 Cost Analyzer Help?
Reservations are only valuable if they're being utilised — and most Azure environments have some degree of reservation waste. Turbo360 Cost Analyzer gives you visibility into your reservation portfolio so waste doesn't go unnoticed.
Reservation utilisation monitoring
Cost Analyzer tracks utilisation for each of your reservations, showing you the percentage of each reservation's capacity being consumed each day. Reservations running below threshold trigger visibility so you can investigate before months of waste accumulate. This is the most important reservation metric: a reservation at 70% utilisation is losing money every hour.
Expiry alerts
Reservations that expire silently cause unexpected cost spikes. Cost Analyzer tracks upcoming reservation expiry dates and surfaces them ahead of time, giving you the opportunity to decide whether to renew, replace, or retire the covered workload rather than discovering the price jump after the fact.
Identifying candidates for new reservations
Cost Analyzer's workload analysis can identify resources currently running at pay-as-you-go rates that have consistent enough usage patterns to be good reservation candidates. This turns reservation purchasing from a periodic manual exercise into an ongoing, data-driven process.
Reservation savings attribution
Shared-scope reservations save money across your estate, but the saving needs to be attributed back to the teams whose workloads benefited. Cost Analyzer's tag-based allocation lets you distribute reservation savings proportionally to the right cost centres, keeping your chargeback or showback model accurate.
FAQ
Can I cancel a reservation if my workload changes?
Yes, but with a cost. Microsoft charges a 12% early termination fee on the remaining value of the reservation. Across all commitment discounts (Savings Plans and Reservations combined) you can cancel up to $50,000 worth per year. For large or long-term reservations, the termination fee can be substantial — which is why right-sizing at purchase time matters. If the reservation is recent and the remaining value is small, cancellation may be worth it. If a significant term remains, weigh the ongoing waste cost against the termination fee.
What happens if I resize a VM that's covered by a reservation?
If the new size is in the same VM series and region, Instance Size Flexibility means the reservation will still apply — though the coverage ratio adjusts based on the relative size of the reservation and the new VM. If you resize to a different VM series, the reservation will no longer match and its hours will go unused until a matching resource is running. This doesn't break anything operationally, but the reservation is now wasted until you either change the VM back or cancel the reservation.
Can I apply a reservation to a specific virtual machine?
No — reservations don't attach to specific VMs. Azure matches reservations to running resources automatically each hour based on matching attributes (VM size, region, OS). If you have one reservation and two VMs that match it, one will get the discount and one won't — Azure applies the discount to whichever resource matches first. If you want to ensure a particular team's workload benefits from a reservation, use single-subscription scope and make sure that subscription only runs the workload you want covered.
Do reservations cover Windows licensing costs?
The reservation price for a does not include the Windows Server licence. You can combine a reservation with Azure Hybrid Benefit (bringing your own Windows Server licences from on-premises Software Assurance).
How do reservations interact with Savings Plans if I have both?
Reservation discounts are applied first. Azure matches reservation coverage to eligible usage before Savings Plan coverage. If a resource matches a reservation, the reservation discount applies and that usage doesn't count against your Savings Plan commitment. Savings Plans then cover remaining eligible compute usage up to the committed hourly amount. They're complementary — reservations for what you can specify precisely, Savings Plans for the rest.
Useful Resources
Turbo360 blog posts
Related playbook pages
Microsoft resources