Azure Commitment Strategy: Reservations, Savings Plans, and Hybrid Benefit Optimization

Commitment discounts are the single largest lever in an Azure bill, and the one teams most often pull wrong. The failure mode is not “we forgot to buy reservations” — it is buying the wrong instrument, at the wrong scope, for a baseline that drifts, and then discovering at renewal that half the commitment went unused while pay-as-you-go (PAYG) charges piled up next to it. Every rupee of unused commitment is a negative discount: you paid up front and got nothing back. A 3-year reservation that under-utilizes at 60% is more expensive than the PAYG it was supposed to beat.

This guide is the decision logic, not a feature tour. We pick the right instrument per workload, size it from real utilization data, choose scope deliberately, stack Azure Hybrid Benefit (AHB) on top, and build the exchange-and-review cadence that keeps the portfolio matched to a moving estate. Because this is a reference you will return to at every renewal and every monthly FinOps review, the instruments, scopes, eligibility, exchange rules, error conditions and the sizing playbook are all laid out as scannable tables — read the prose once, then keep the tables open when finance asks “why did coverage drop.” Numbers here are illustrative; pull live rates from the Azure pricing calculator and your EA/MCA price sheet before committing.

By the end you will stop over-committing out of optimism and under-committing out of fear. You will know — within one query — what fraction of your estate is genuinely immovable (reserve it), what is stable-in-spend but mobile-in-shape (savings-plan it), and what is spiky (leave it on PAYG). You will know that VM reservation exchanges ended for new purchases, that savings plans cannot be cancelled, and therefore why conservatism at purchase is the entire game.

Mental model. Reservations and savings plans discount compute and a few other resource types. AHB discounts licensing (Windows Server, SQL Server) and is independent — it stacks. PAYG is your liquidity reserve for the part of the baseline you are not yet confident is permanent. Most mature estates run all three at once, layered: reservation on the floor, savings plan on the flexible band, PAYG on the peak.

What problem this solves

The pain is concrete and it is large. A mid-size Azure estate spends ₹40–₹80 lakh/month, of which 50–70% is compute that could carry a commitment discount of 30–65%. Leave it all on PAYG and you overpay by lakhs every month. But the naive fix — “buy 3-year reservations for everything” — is worse, because an estate is never static: teams migrate VM families, stand up new regions for data residency, autoscale fleets up and down, refactor VMs into App Service or AKS. Every one of those moves can strand a SKU-pinned reservation, and since like-for-like VM reservation exchanges ended for new purchases, a stranded VM reservation is now cash you mostly cannot recover.

What breaks without a deliberate strategy: a team buys reservations off a single peak month and under-utilizes through every trough; a platform team buys at single-subscription scope and watches a perfectly-sized reservation sit idle next to PAYG usage in the subscription next door; someone flips AHB onto a dev/test subscription that already zeroes the license, burning a Software Assurance entitlement a production VM needed; a savings plan is sized off Azure’s optimistic recommendation and then under-runs every weekend. None of these show up as an outage — they show up as a finance review six months later asking why the “optimized” estate costs more than the unoptimized one did.

Who hits this: every team past the experimentation phase. It bites hardest on estates in active migration (D→E series, single→multi region, IaaS→PaaS), on regulated workloads with data-residency-driven region sprawl, on cost-sensitive teams (the ones who most need the discount and can least afford a stranded commitment), and on platform teams that own commitments centrally but cannot see per-team utilization without amortized cost data. The fix is almost never “buy more” — it is “buy only the immovable floor, cover the probable band with the flexible instrument, and review monthly against a moving estate.”

To frame the whole field before the deep dive, here is every instrument this article covers, the part of the bill it touches, what it locks you to, and the one question that decides whether to use it:

Learning objectives

By the end of this article you can:

• Choose, for any compute baseline, the right instrument — reservation, savings plan, or PAYG — from the stability of its SKU/region versus the stability of its spend, and justify the choice to finance.
• Size a commitment from real utilization: pull amortized cost, compute the 5th-percentile hourly floor per SKU, and commit only the floor while layering a savings plan on the flexible band.
• Pick reservation scope (single-subscription, single-RG, management-group, shared) deliberately, and re-point scope at no cost to chase utilization when a workload moves.
• Apply Azure Hybrid Benefit correctly to Windows Server VMs, SQL on Azure VMs, Azure SQL Database and Managed Instance — and not to dev/test subscriptions where it double-counts.
• Stack AHB with reservations/savings plans and dev/test pricing so compute and license discounts compound on different parts of the meter.
• Navigate the exchange, refund and cancellation mechanics — including the end of like-for-like VM reservation exchanges and the non-cancellability of savings plans — and size conservatively because of them.
• Run a monthly commitment-review cadence that catches under-utilization early (re-scope, which is free) before it becomes a refund (capped, fee-bearing).
• Read every reference table in this article — instrument matrix, scope matrix, eligibility grid, exchange rules, error conditions, sizing playbook — to make purchase decisions without re-deriving the mechanics each time.

Prerequisites & where this fits

You should already understand the Azure billing hierarchy: an Enterprise Agreement (EA) or Microsoft Customer Agreement (MCA) billing account contains billing profiles and invoice sections; under it sit subscriptions, optionally organized under management groups. You should know that a reservation and a savings plan are billing artifacts purchased against a billing scope, not resources deployed into a resource group. Familiarity with Cost Management (cost analysis, exports, budgets), running az in Cloud Shell, and reading amortized vs actual cost views is assumed. You should know roughly what an Azure VM SKU name encodes (D8s_v5 = D-series, 8 vCPU, premium-storage-capable, v5 generation).

This sits in the Governance & FinOps track. It is downstream of the broad cost-management foundation in the Azure FinOps & Cost Engineering Guide and the operating model in Azure FinOps Cost Management at Scale, and it depends on accurate cost allocation, which comes from Tagging & resource organization for cloud cost visibility. The compute it discounts is the subject of the Azure VM Deep Dive: Every Setting; for the non-committable, interruptible end of the spectrum see Azure specialized compute: dedicated hosts, Spot, confidential, HPC & batch. Where SQL licensing dominates the bill, Azure SQL Database: Hyperscale, elastic pools, ledger & Always Encrypted is the workload AHB pays down hardest, and you gate the whole thing with Azure Policy & governance at scale.

A quick map of who owns each decision, so the right person is in the room at purchase time:

Core concepts

Six mental models make every later decision obvious.

A commitment is a bet on stability, priced in flexibility. The three compute instruments trade discount depth against flexibility, and that single trade is the entire decision. A reservation is the deepest discount and the least flexible: you lock a specific SKU in a specific region (or an instance-size-flexible group within a family) for 1 or 3 years. A compute savings plan is shallower but flexes across SKU family, region, OS and even service: you lock an hourly spend, not a shape. PAYG is full list price but free to abandon any hour. Azure’s billing engine applies the deepest applicable discount first each hour, so a correctly-fitted reservation beats a savings plan on price for the same usage — the savings plan wins only when the shape of usage is uncertain even though the spend is stable.

Coverage and utilization are two different numbers, and you need both. Coverage is the fraction of eligible usage that already sits under a commitment — low coverage on a stable workload is money on the table. Utilization is the fraction of a purchased commitment you actually consumed — utilization below ~95–100% on a reservation means you over-bought and are paying for hours you did not use. You can have high coverage and terrible utilization (you bought too much) or low coverage and perfect utilization (you bought too little). The goal is high on both, and the only way to see them honestly is amortized cost, which spreads an upfront purchase across its term so a day’s true run-rate is visible instead of a lump on purchase day.

Size to the floor, never the average and never the peak. The defensible reservation quantity is the minimum sustained concurrency — the count you run essentially all the time, which the 5th-percentile hourly running count approximates. Commit the floor to reservations, cover the band between floor and median with a savings plan, and let the peak ride on PAYG. Committing to the mean guarantees you under-utilize during every trough; committing to the peak guarantees you over-buy.

Scope decides which usage a reservation is even allowed to pay down. A reservation has an applied scope — single subscription, single resource group, a management group, or shared across the whole billing context. A perfectly-sized reservation at single-subscription scope sits idle next to matching PAYG usage in the subscription next door, because scope forbade it from reaching across. Scope is mutable after purchase at no cost — this is the cheapest lever you have to fix under-utilization.

AHB discounts a different part of the meter than the compute commitment. A reservation or savings plan discounts the compute portion; Azure Hybrid Benefit removes the license portion (Windows Server, SQL Server) when you bring your own licenses with active Software Assurance. They are orthogonal and they stack. In fact the published reserved-VM rate for Windows already assumes AHB (it excludes the license), so the deepest Windows price is reserved-compute-rate plus your owned license at zero — both levers at once.

The exits are narrow, so the entry must be conservative. VM reservation exchanges ended for purchases after a cutoff date — the intended path to flexibility is now the savings plan, by design. Reservation refunds exist but carry an early-termination fee and an annual cap (currently $50,000 per billing scope in a rolling 12 months). Savings plans cannot be cancelled, refunded or exchanged at all — the commitment is to a dollar amount and Azure auto-applies it broadly, so there is nothing to exchange. Because the exits are narrow, you buy reservations only for the floor you are certain is permanent, cover the merely-probable with a savings plan sized below your true floor, and let the rest ride PAYG.

The vocabulary in one table

Before the deep sections, pin down every moving part. The glossary at the end repeats these for lookup; this table is the mental model side by side:

The commitment-instrument reference

Before the per-instrument deep dives, here is the lookup table you scan first when a new workload arrives: every eligible Azure commitment product, what it discounts, the terms, the typical discount band, and the one gotcha that decides whether it fits. The non-obvious ones are that savings plans are compute-only and non-cancellable, and that several resource types (storage, databases, even software) have their own reservation products distinct from VM reservations.

Three reading notes that save the most money:

1. PAYG vs reservations vs savings plans: where each wins

The three instruments trade discount depth against flexibility. That is the entire decision. The hierarchy is simple: reservations are the deepest discount but the least flexible; savings plans are shallower but flex across SKU family, region, and OS; PAYG is full price but free to walk away. Azure’s billing engine applies the deepest applicable discount first each hour. A reservation, when it fits, beats a savings plan on price for the same usage; savings plans win when the shape of usage is uncertain even though the spend is stable.

The decision flow as a table

For any compute baseline, answer the questions top to bottom; the first match is your instrument:

A nuance that trips people: the compute savings plan covers a broad set of compute services under one hourly-dollar commitment, automatically applying to the highest-PAYG-rate eligible usage first. Reservations are per-resource-type — a VM reservation does not pay down an App Service plan. That breadth is exactly why savings plans absorb migration churn that would strand a reservation. What the savings plan covers, and what it pointedly does not:

Do not assume a savings plan blankets the bill. It is compute, broadly defined — not the whole invoice.

Payment option and purchase settings

Both reservations and savings plans expose a small set of purchase-time settings that change cash-flow and renewal behaviour, not the discount shape. Get them right at the order, because some are awkward to change later:

2. Reading utilization and coverage to size commitments correctly

Never size a commitment off a single month or a portal eyeball. You need two numbers per workload, tracked over time — coverage (how much eligible usage is already committed) and utilization (how much of a purchase you consumed) — and you size to the stable floor of the last 30–60 days, not the average and never the peak. The classic mistake is committing to the mean, which guarantees you under-utilize during the troughs.

The metrics that drive the decision, what each tells you, and the action each threshold triggers:

Pull the raw signal from amortized cost data via Cost Management. The amortized view spreads an upfront reservation purchase across its term so a day’s true run-rate is visible instead of a lump on purchase day.

# Export amortized usage so reservation/savings-plan cost is spread across the term,
# not booked as a lump on the purchase date.
az costmanagement export create \
  --name amortized-daily \
  --type AmortizedCost \
  --scope "subscriptions/<sub-id>" \
  --storage-account-id "<storage-resource-id>" \
  --storage-container "cost-exports" \
  --storage-directory "amortized" \
  --timeframe MonthToDate \
  --recurrence Daily \
  --recurrence-period from="2026-06-01T00:00:00Z" to="2026-12-31T00:00:00Z"

Then query the exported data (or the same fields in a Log Analytics / cost workspace) to find the stable hourly floor per SKU. The shape that matters is the minimum sustained concurrency, which is your safe reservation quantity:

// Stable VM concurrency floor per SKU over 60 days.
// The 5th-percentile hourly running count is a defensible reservation quantity:
// you run at least this many essentially all the time.
Usage
| where TimeGenerated > ago(60d)
| where MeterCategory == "Virtual Machines"
| summarize RunningVMs = dcount(ResourceId) by SkuName, bin(TimeGenerated, 1h)
| summarize FloorQty = percentile(RunningVMs, 5),
            MedianQty = percentile(RunningVMs, 50),
            PeakQty   = max(RunningVMs)
  by SkuName
| order by FloorQty desc

Commit the FloorQty to reservations, cover the band between floor and median with a savings plan, and let the peak ride on PAYG. That layering is the whole strategy in one query. How the three layers map to the percentiles, the instrument, and the risk if you mis-size:

The Cost Management surfaces you actually open to read these numbers, and what each is the source of truth for:

For savings-plan sizing specifically, Azure’s own recommendation engine is worth consulting — Cost Management surfaces a recommended hourly commitment at 1-yr and 3-yr terms based on your last 7/30/60 days of eligible usage, with a projected utilization. Treat it as a starting point, then haircut it 5–10% toward the conservative side because the recommendation assumes your recent past repeats exactly. How to read the recommendation inputs:

3. Reservation scope: shared, single-subscription, and management-group

Scope decides which usage a reservation is allowed to pay down. Get it wrong and a perfectly-sized reservation sits idle next to PAYG usage it was never permitted to touch. The four scopes, what each lets a reservation reach, and when each is right:

The default and usually correct choice for a platform team is shared (or management-group scope when you want a boundary): it lets one reservation float to wherever the matching SKU is running, which maximizes utilization — the number that actually determines ROI. Pin to single-subscription only when a business unit funds its own commitment and must not subsidize another, or when chargeback rules forbid cross-charging.

The operationally valuable fact: scope is mutable after purchase, at no cost. If a shared reservation is under-utilizing because the workload it was bought for shrank, narrow or re-point its scope to where the matching usage actually lives — no exchange, no refund, just a property change. The scope-change levers and what each costs:

# List reservations and their current utilization so you can spot misallocation.
az reservations reservation-order list -o table

# Show utilization for a specific order before deciding to re-scope.
az consumption reservation summary list --grain monthly \
  --reservation-order-id "<order-id>" \
  --start-date 2026-05-01 --end-date 2026-05-31 -o table

# Re-point a reservation to a management group (or flip to Shared) to chase usage.
az reservations reservation update \
  --reservation-order-id "<order-id>" \
  --reservation-id "<reservation-id>" \
  --applied-scope-type ManagementGroup \
  --applied-scope-groups "/providers/Microsoft.Management/managementGroups/landing-zones"

Governance gotcha. A shared reservation can be consumed by any subscription in the billing scope, which can quietly cross-subsidize teams and muddy showback. If your chargeback model is strict, prefer management-group scope so the discount stays inside an org boundary, and reconcile with amortized cost so each team sees its effective (post-discount) rate, not the list price.

Instance size flexibility

A VM reservation purchased for a size within a family can apply its discount to other sizes in the same family in proportion to a published ratio, so a resize within the family does not strand the reservation. This is distinct from the savings plan’s cross-family flexibility. The mechanics and limits:

4. Compute savings plans for flexible, cross-SKU and cross-region coverage

A compute savings plan is a commitment to spend a fixed dollars-per-hour on eligible compute for 1 or 3 years, in exchange for savings-plan rates on usage up to that hourly amount. Usage above the commitment bills at PAYG; usage below means you paid for hours you did not consume — the same under-utilization trap as a reservation, just denominated in dollars. You do not assign a savings plan to a resource: the billing engine sweeps each hour and discounts the most expensive eligible usage first until your hourly commitment is exhausted. You buy flexibility, and you pay for it with a slightly shallower discount than the equivalent reservation.

Why platform teams reach for it over reservations, and the limit on each axis:

# Inspect savings-plan recommendations (hourly commitment + projected utilization)
# before you buy. Look-back of 30 days, 3-year term, shared scope.
az billing-benefits savings-plan-order list -o table

# Validate a hypothetical commitment against your usage before purchase.
az billing-benefits savings-plan-order-alias create \
  --order-alias-name sp-prod-3yr \
  --billing-scope-id "/subscriptions/<sub-id>" \
  --term P3Y --billing-plan Monthly \
  --applied-scope-type Shared \
  --commitment amount=12.50 currencyCode=USD grain=Hourly

In Bicep you can codify the savings-plan order so commitments are reviewed like infrastructure rather than clicked in the portal:

// Codify a compute savings plan so the commitment is PR-reviewed, not portal-clicked.
resource savingsPlan 'Microsoft.BillingBenefits/savingsPlanOrders@2022-11-01' = {
  name: 'sp-prod-3yr'
  properties: {
    displayName: 'Prod compute floor — 3yr'
    billingScopeId: '/subscriptions/${subscriptionId}'
    term: 'P3Y'
    billingPlan: 'Monthly'
    appliedScopeType: 'Shared'
    commitment: {
      amount: 12.50          // $/hr — sized BELOW the proven floor
      currencyCode: 'USD'
      grain: 'Hourly'
    }
  }
}

A worked example of the auto-apply order, because it surprises people: the engine spends your hourly commitment on the most expensive eligible usage first, so a fixed $/hr buys down different usage as your fleet changes. Given a $12.50/hr commitment:

Notice you never told Azure which resources to cover — the engine chose, highest-rate first, until $12.50/hr ran out. That is exactly why a savings plan survives a D→E migration: the dollars follow whatever runs.

Practical rule: layer savings plans under reservations, not instead of them. Reservations cover the immovable floor at the deepest discount; the savings plan covers the flexible band above it at a still-meaningful discount; PAYG handles the spiky top. Buying only savings plans because they are “easier” leaves the deepest reservation discount on the table for the part of the estate that genuinely never moves. The 1-yr vs 3-yr term trade-off:

5. Azure Hybrid Benefit for Windows Server and SQL licensing

AHB is a licensing discount, orthogonal to compute commitments. If you own Windows Server or SQL Server licenses with active Software Assurance (or qualifying subscription licenses), AHB lets you bring them to Azure and stop paying the license portion of the meter — you pay the base compute rate only. For Windows Server VMs the savings are substantial; for SQL the savings can be larger still because SQL licensing is expensive. The core entitlements:

The entitlement details that decide how many cores you actually cover:

Enabling AHB is a property, not a purchase — flip it on existing resources:

# Windows Server VM: switch the license type to bring your own Windows license.
az vm update -g rg-prod -n vm-app-01 --license-type Windows_Server

# Convert back to pay-as-you-go licensing (e.g., if you run out of entitlements).
az vm update -g rg-prod -n vm-app-01 --license-type None

For SQL on Azure VMs you set the license type on the SQL virtual machine resource (the IaaS extension), not the VM:

# SQL Server IaaS: AHB / bring-your-own-license at the SQL VM resource level.
az sql vm update -g rg-prod -n vm-sql-01 --license-type AHUB

Azure SQL Database and Managed Instance expose AHB as a property of the database/instance:

# Azure SQL Database: enable Azure Hybrid Benefit (base-rate licensing).
az sql db update -g rg-prod -s sql-logical-01 -n salesdb --license-type BasePrice

The licenseType / equivalent values you will set, per resource, and what each means:

In Bicep, make AHB the default for managed compute so nobody forgets it at deploy time:

resource sqlMi 'Microsoft.Sql/managedInstances@2023-08-01-preview' = {
  name: 'mi-prod-01'
  location: location
  sku: { name: 'GP_Gen8', tier: 'GeneralPurpose' }
  properties: {
    // BasePrice = Azure Hybrid Benefit; LicenseIncluded = pay for the license.
    licenseType: 'BasePrice'
    vCores: 8
    storageSizeInGB: 256
    subnetId: subnetId
  }
}

Compliance is on you. Azure does not verify you actually hold the licenses you claim. AHB is an entitlement you assert; a license audit can claw it back. Track AHB usage against owned SA seats in a spreadsheet or your SAM tool, and gate the property behind policy so it is a deliberate, attributable choice — not a default someone flipped to cut their bill.

Where AHB lands per SQL deployment model — the nuance that decides whether the property even exists and how many cores it covers:

You can enforce that with Azure Policy so AHB is never silently toggled outside the SAM-tracked process:

// Audit any SQL DB that turns on AHB so licensing can reconcile it against owned SA.
resource ahbAudit 'Microsoft.Authorization/policyAssignments@2022-06-01' = {
  name: 'audit-sql-ahb'
  properties: {
    displayName: 'Audit AHB (BasePrice) on SQL databases'
    policyDefinitionId: auditIfNotExistsPolicyId
    parameters: { effect: { value: 'Audit' } }
  }
}

6. Stacking AHB with reservations and dev/test pricing

The discounts compose, and the savings multiply because they hit different parts of the meter: a reservation (or savings plan) discounts the compute portion, AHB removes the license portion, and reserved VM pricing for Windows is published assuming AHB — i.e., the deepest published Windows reservation rate already excludes the license, which you then satisfy with your owned license. Stack them and you pay reserved-compute rate plus zero license. How the layers compose on one Windows VM:

For non-production there is a fourth lever: an Enterprise Dev/Test or Pay-As-You-Go Dev/Test subscription removes the Windows/SQL license charge entirely for Visual Studio subscribers’ dev/test workloads, with no SA required. You generally would not apply AHB there — the dev/test subscription already zeroes the license. The discount layering therefore differs by environment:

The trap is applying AHB to a dev/test subscription and assuming it stacks — it does not double-discount the license, and you have now consumed an SA entitlement that a production VM could have used. Reserve AHB entitlements for production, where they are the only way to drop the license charge. A combined view of every lever by environment so the whole stack is visible at once:

7. Exchanges, refunds, and avoiding underutilized commitments

Estates drift. The instrument that fit at purchase will not fit forever, so you must know the exit mechanics before you buy. The exits, side by side:

Reservations. Refunds (cancellations) return a prorated value subject to an early-termination fee and an annual cap on total refunds per billing scope (currently $50,000 in a 12-month window). Refunds are the escape hatch, not a planning tool. Exchanges historically let you swap one reservation for another of equal-or-greater value with no fee — but Microsoft ended like-for-like compute (VM, dedicated host, etc.) reservation exchanges for purchases made after a cutoff date. The intended migration path for flexibility is now the compute savings plan. Non-compute reservations (storage, some databases) still support exchange. Do not architect a strategy around freely exchanging VM reservations; it no longer exists for new purchases.

Savings plans. Effectively non-cancellable and non-refundable for the term — no exchanges, no early termination. This is the price of their flexibility: the commitment is to a dollar amount, and Azure auto-applies it broadly, so there is nothing to “exchange” for. Size them conservatively.

Because VM reservation exchanges are gone and savings plans cannot be canceled, conservatism at purchase is the entire game. Buy reservations only for the part of the floor you are certain is permanent. Cover everything merely “probable” with a savings plan sized below your true floor. Let the rest ride PAYG. Under-committing costs you a little discount; over-committing costs you cash you cannot get back.

Catch under-utilization early with a recurring report. Reservation utilization below 100% over a trailing window is the first signal to re-scope (cheap) before considering a refund (expensive, capped):

# Trailing reservation utilization. Anything under ~95% is a re-scope candidate.
az consumption reservation summary list \
  --grain daily \
  --start-date 2026-05-01 \
  --end-date 2026-05-31 \
  -o table

The under-utilization & misallocation playbook

This is the differentiator. A commitment portfolio fails operationally in a handful of recognizable ways, and the order of the right move matters: re-scope (free) before refund (capped, fee-bearing), and never confuse low utilization (over-bought) with low coverage (under-bought). Match the symptom, confirm with the exact command, then apply the fix — and note the band-aid that masks each so you do not reach for it:

The error / blocked-operation reference

The specific conditions Azure will refuse or warn on, what triggers each, how to confirm, and the resolution:

Architecture at a glance

The diagram is not a network path — it is the decision and money flow of a commitment portfolio, read left to right as a request for discount travels from your usage to your invoice. On the far left, your eligible usage (running VMs, App Service plans, SQL) and your owned Software Assurance licenses are the two raw inputs. They feed an analysis stage where amortized cost and the 5th-percentile floor query split the estate into three bands: the immovable floor, the flexible band, and the spiky peak. That split is the whole strategy, and it is where the badges cluster, because every expensive mistake is a mis-classification at this stage.

From analysis, each band routes to its matching instrument: the floor to a reservation (deepest discount, SKU/region-pinned, scoped shared or to a management group), the flexible band to a compute savings plan (cross-SKU, cross-region, non-cancellable), and AHB runs alongside as a license-meter switch that stacks on either. Finally the billing engine applies the deepest applicable discount each hour and emits an amortized invoice that — if everything landed — shows every team an effective rate below list. Follow the numbered badges: they sit on the exact nodes where commitments strand (wrong scope, migrated SKU, over-sized savings plan, AHB double-counted on dev/test), and the legend narrates each as symptom · confirm · fix. The footer truth is the same as the prose: reserve only the floor, savings-plan the probable, PAYG the peak, and review monthly because the bands move.

Real-world scenario

Meridian Assurance, a regulated insurance carrier, ran a stable production fleet of roughly 120 D8s_v5 Windows VMs in westeurope and bought 3-year VM reservations against it at shared scope, with AHB enabled across the fleet from owned SQL Enterprise and Windows Datacenter SA. Monthly Azure spend was about ₹62 lakh, of which the committed compute was ₹28 lakh. For six months the portfolio looked exemplary: reservation utilization sat at 99%, AHB zeroed the Windows and SQL license meters, and amortized cost showed every business unit a rate well below list. The FinOps lead presented it as a model engagement.

Then two things happened in the same quarter. The application team kicked off a migration to E-series memory-optimized VMs (a heavier in-memory rating engine), and a new data-residency requirement forced a second region in northeurope. Reservation utilization on the D8s_v5 order cratered to ~55% almost overnight: the E-series and northeurope usage billed at full PAYG while the paid-for D8s_v5 reservation sat idle. The on-call instinct was to exchange the reservations into E-series — but those reservations were purchased after the compute-exchange cutoff, so like-for-like VM exchange was unavailable. The second instinct was to refund and re-buy — but the refund was both capped ($50k/12 months per billing scope) and wasteful, eating an early-termination fee on a 3-year purchase only six months in.

The constraint, then: a deep but now-mismatched 3-year reservation that could not be exchanged, against a fleet that had become flexible by nature — active migration, multi-region, changing SKU family. Fighting the reservation model was the wrong move.

The fix was to stop fighting it. They let the reservation expire gracefully on the residual D8s_v5 footprint (which was still ~50 VMs and falling), and moved the flexible portion of the estate onto a compute savings plan, which is SKU- and region-agnostic by design and therefore immune to exactly this churn. Critically, they sized the savings plan from the 5th-percentile hourly spend across both regions and both SKU families combined — not per-SKU — so the commitment floated to wherever usage landed:

// Cross-SKU, cross-region hourly spend floor that a savings plan can safely commit to.
// Summing eligible compute spend (not per-SKU) is what makes the commitment
// resilient to the D->E migration and the new region.
Usage
| where TimeGenerated > ago(60d)
| where MeterCategory in ("Virtual Machines")
| where ResourceLocation in ("westeurope", "northeurope")
| summarize HourlySpend = sum(PreTaxCost) by bin(TimeGenerated, 1h)
| summarize CommitFloorPerHour = percentile(HourlySpend, 5)

They committed ~80% of that floor as a 1-year savings plan (short term, because the migration meant the future shape was still moving), kept AHB enabled across both SKU families and regions to hold the Windows and SQL license savings constant through the migration, and let the old D8s_v5 reservations amortize out. They also moved the reservation scope from shared to the landing-zones management group, so the residual discount stayed inside the production org boundary and stopped cross-subsidizing a dev subscription that had quietly started consuming it.

Blended effective discount recovered to within a couple of points of the original target within one billing cycle, with zero stranded commitment going forward. The lesson the team wrote into their standards: reserve only the immovable floor; everything that can migrate goes on a savings plan — and AHB rides through both because it discounts the license, not the shape. The portfolio that resulted, before and after:

Advantages and disadvantages

The commitment model is the largest cost lever on the platform and also the one most able to backfire. Weigh it honestly:

The model is right for any estate past experimentation with a meaningful stable compute floor — which is almost all of them. It bites hardest on estates in active migration (where reservations strand), on teams that buy off a single peak month (over-utilization at the trough), and on anyone who treats a purchase as fire-and-forget rather than a portfolio reviewed monthly against a moving estate. The disadvantages are all manageable — but only if you classify usage honestly (floor vs band vs peak), buy the matching instrument, and review on a cadence. That discipline is the entire point of this article.

Hands-on lab

This lab is analysis-only and free — you will read your own utilization, coverage and recommendations, and verify AHB state, without buying anything. (Purchasing a commitment costs real money and is not reversible for savings plans; never do that in a lab.) Run in Cloud Shell (Bash).

Step 1 — Variables and confirm your billing context.

SUB=$(az account show --query id -o tsv)
echo "Operating on subscription: $SUB"
az account show --query "{name:name, state:state}" -o table

Step 2 — Stand up an amortized daily cost export so true run-rate (not purchase lumps) flows to storage. Create a throwaway storage account first.

RG=rg-finops-lab; LOC=centralindia
SA=stfinopslab$RANDOM
az group create -n $RG -l $LOC -o table
az storage account create -n $SA -g $RG -l $LOC --sku Standard_LRS -o table
SAID=$(az storage account show -n $SA -g $RG --query id -o tsv)

az costmanagement export create \
  --name amortized-daily-lab \
  --type AmortizedCost \
  --scope "subscriptions/$SUB" \
  --storage-account-id "$SAID" \
  --storage-container "cost-exports" \
  --storage-directory "amortized" \
  --timeframe MonthToDate --recurrence Daily \
  --recurrence-period from="2026-06-01T00:00:00Z" to="2026-12-31T00:00:00Z"

Expected: the export is created and will run daily; the first run lands a CSV under cost-exports/amortized/.

Step 3 — List any existing reservations and their utilization. (Empty output is fine — it just means none are purchased yet.)

az reservations reservation-order list -o table
az consumption reservation summary list --grain monthly \
  --start-date 2026-05-01 --end-date 2026-05-31 -o table 2>/dev/null \
  || echo "No reservations to summarize — expected if none purchased."

Step 4 — Pull savings-plan recommendations (the sized starting point you would haircut before buying):

az billing-benefits savings-plan-order list -o table 2>/dev/null \
  || echo "No savings-plan orders yet — expected."
# Recommendations also surface in Cost Management → Advisor → Reservations/Savings plans.

Step 5 — Verify AHB state across your VMs and SQL (read-only — this is the audit you run monthly):

# Which Windows VMs are bringing their own license vs paying for it?
az vm list --query "[].{name:name, rg:resourceGroup, license:licenseType}" -o table

# SQL on VMs carrying AHUB?
az sql vm list --query "[].{name:name, license:sqlServerLicenseType}" -o table 2>/dev/null \
  || echo "No SQL VMs — expected."

Expected: each Windows VM shows Windows_Server (AHB on) or None (paying for the license). A None on a production VM you do hold a license for is money on the floor.

Step 6 — Reconcile against amortized cost in the portal. Open Cost Management → Cost analysis, switch the metric to Amortized cost, group by Reservation and by Resource group. Effective rates on committed resources should sit visibly below list; coverage on stable workloads should be high.

Step 7 — Teardown. The export and storage cost essentially nothing, but clean up:

az costmanagement export delete --name amortized-daily-lab --scope "subscriptions/$SUB" --yes 2>/dev/null
az group delete -n $RG --yes --no-wait

You never purchased a commitment, so there is nothing irreversible to undo — exactly the point: the analysis is free; only the purchase is permanent.

Common mistakes & troubleshooting

The portfolio-level failure modes, each as symptom → root cause → how to confirm → fix. These complement the playbook table above with the reasoning behind each.

1. Committing to the average (or the peak) instead of the floor. Symptom: a reservation that looked right under-utilizes every weekend and overnight. Root cause: sized to the mean, so every trough falls below the commitment. Confirm: the p5/p50/max query shows a wide gap between floor and median. Fix: re-size future buys to the p5 floor; cover the floor→median band with a savings plan, not a bigger reservation.

2. Single-subscription scope on a platform-team reservation. Symptom: a perfectly-sized reservation idles while identical PAYG usage runs in a sibling subscription. Root cause: scope forbids cross-subscription application. Confirm: az reservations reservation-order list shows low utilization while usage lives elsewhere. Fix: change applied scope to Shared or the relevant management group — free, instant.

3. Trying to exchange a VM reservation after a migration. Symptom: the exchange option is gone. Root cause: like-for-like compute exchanges ended for purchases after the cutoff. Confirm: the reservation order has no exchange action. Fix: let the reservation lapse on the residual footprint; move the migrated/flexible portion to a compute savings plan.

4. Over-sizing a savings plan off the optimistic recommendation. Symptom: savings-plan utilization sits at 85% indefinitely. Root cause: took the recommendation at face value; it assumed the recent peak repeats. Confirm: az billing-benefits savings-plan-order list plus amortized export shows persistent unused commitment. Fix: you cannot cancel — let it run, and size the next buy at 90–95% of the proven floor.

5. AHB applied to a dev/test subscription. Symptom: SA seats exhausted, yet a production VM still pays for its Windows license. Root cause: AHB was toggled on a dev/test subscription that already zeroes the license, consuming the entitlement for nothing. Confirm: audit dev/test subs for a set licenseType. Fix: remove AHB from dev/test; reclaim the seat for production.

6. IaC reverting AHB on redeploy. Symptom: a SQL database’s AHB silently turns off after a pipeline run. Root cause: the Bicep/Terraform default is LicenseIncluded. Confirm: az sql db show --query licenseType returns LicenseIncluded right after a deploy. Fix: set BasePrice explicitly in the template so deploys preserve it; gate with policy.

7. Reading cost in actual instead of amortized. Symptom: the bill shows a huge lump on reservation purchase day and “looks wrong.” Root cause: the actual view books the upfront purchase as a lump; the amortized view spreads it. Confirm: toggle Cost analysis between Actual and Amortized — the lump vanishes in amortized. Fix: standardize all FinOps reporting on amortized.

8. Auto-renew re-buying a stale quantity. Symptom: at term end a reservation renews at last year’s count even though the estate shrank. Root cause: auto-renew was left on. Confirm: the reservation order shows the auto-renew flag and a renewal at the old quantity. Fix: disable auto-renew; re-size from the current floor at each renewal.

9. Hitting the refund cap. Symptom: a refund request is blocked. Root cause: you exceeded $50k in refunds in a rolling 12 months for that billing scope. Confirm: the returns history in billing. Fix: re-scope instead (free); if a refund is truly needed, stagger across cap windows.

10. Assuming a savings plan covers storage/DB/egress. Symptom: coverage looks low and storage still bills at PAYG. Root cause: savings plans are compute; storage, databases and egress have their own products. Confirm: the eligibility table — storage/DB are excluded. Fix: buy the dedicated storage/SQL/Cosmos reservation for those workloads.

11. Cross-subsidy muddying showback under shared scope. Symptom: one team’s effective rate looks better than its own purchases justify. Root cause: shared scope let it consume another team’s reservation discount. Confirm: amortized cost per subscription against each team’s own commitments. Fix: move to management-group scope; reconcile showback to the org boundary.

12. 3-year lock on a floor that wasn’t durable. Symptom: a 3-year reservation strands mid-term during a re-platform. Root cause: the “floor” included usage that was about to migrate. Confirm: current p5 floor is well below the reserved quantity. Fix: let it lapse on the residual; savings-plan the mobile part; next time gate 3-yr buys behind an explicit “is this genuinely permanent?” sign-off.

Best practices

Crisp, production-grade rules distilled from the above:

• Reserve only the immovable floor. Use the p5 hourly concurrency per SKU as the defensible quantity; never commit to the mean or the peak.
• Layer, don’t choose. Reservation on the floor, compute savings plan on the flexible band, PAYG on the peak, Spot on the interruptible — most estates run all of them.
• Default reservation scope to shared (or management-group). It maximizes utilization, which is what actually determines ROI; pin to single-subscription only for strict chargeback.
• Re-scope before you refund. Scope changes are free and instant; refunds carry a fee and a $50k/12-month cap. Re-scope is the first move on any under-utilizing reservation.
• Buy conservatively because the exits are narrow. VM reservation exchanges are gone and savings plans cannot be cancelled — size below your true floor and let probable usage ride a savings plan or PAYG.
• Prefer 1-year terms while the estate is moving. Reserve 3-year terms for a floor you have proven durable across multiple review cycles.
• Apply AHB to every eligible production Windows/SQL resource — and never to dev/test. Dev/test already zeroes the license; AHB there double-counts and burns an SA seat.
• Gate AHB and license types behind policy and IaC. Make BasePrice/Windows_Server the deployed default so a redeploy never silently reverts the benefit.
• Report exclusively on amortized cost. It is the only view that shows true run-rate and effective per-team rates; the actual view hides the run-rate behind purchase lumps.
• Haircut the recommendation 5–10%. The engine assumes the recent past repeats exactly; trim toward the conservative side.
• Reconcile AHB usage against owned SA seats monthly. Compliance is asserted, not verified; track it in a SAM tool so an audit cannot claw it back.
• Run a fixed monthly review with finance and platform in the room. Commitments decay against a moving estate; treat the portfolio as a living thing, not a one-time purchase.

The monthly commitment-review checklist

Run this on a fixed cadence; each row is a question with a clear owner and a fix:

Security notes

Commitments are billing artifacts, but they carry real security and governance weight:

• Purchase is a privileged action. Buying reservations/savings plans requires the EA Reservation Purchaser role (or appropriate MCA billing role / subscription owner). Grant it narrowly — an over-broad assignment lets someone lock six-figure, hard-to-reverse commitments. Audit who holds it.
• Least privilege on billing scope. Reservation and savings-plan management (scope changes, refunds) should be limited to the FinOps/platform team; most engineers need only read on cost data. Use Azure RBAC on the billing account and management groups, not blanket owner.
• AHB is a compliance assertion — protect its integrity. Because Azure does not verify the license, the only control is process: gate licenseType behind Azure Policy (audit or deny outside the SAM-approved process) and IaC so AHB is attributable and reviewed, never silently flipped. An unauthorized AHB toggle is both a cost and a compliance event.
• Cost-export storage holds sensitive financial data. Amortized exports reveal spend, effective rates and per-team allocation. Put the export storage account behind private endpoints, restrict access with RBAC, and treat the data as confidential — competitors and bad actors find spend patterns useful.
• Separate duties between buying and approving. The person who recommends a commitment should not be the only one who approves it; require a finance sign-off on large or 3-year purchases, mirroring change control.
• Tag and attribute every commitment. Even though reservations aren’t tagged like resources, record their intent, owner and the floor analysis that justified them, so an auditor (or your future self) can see why each commitment exists.
• Policy-gate the dev/test AHB trap. A policy that flags AHB on dev/test subscriptions prevents the silent SA-seat leak that is both a cost and a licensing-compliance problem.

Cost & sizing

What drives the bill, how to right-size, and rough figures (illustrative — confirm against your EA/MCA price sheet):

Rough sizing math for a stable production fleet: with a p5 floor of, say, 40 D8s_v5 running essentially always, a 3-year reservation on those 40 at shared scope captures the deepest discount on the part that never moves; the band from 40→~70 (median) rides a compute savings plan sized at ~90% of that band’s hourly spend; everything above ~70 stays on PAYG with autoscale. AHB on all 40 (and the savings-plan-covered band) removes the Windows license meter on top. In INR terms, on a fleet spending ~₹28 lakh/month of committable compute, moving from all-PAYG to this layering commonly recovers 35–55% of the committable portion — lakhs per month — provided utilization stays high; a reservation under-utilizing at 60% gives back a chunk of that and can net out worse than PAYG.

Free-tier note for learning this topic: the analysis is free. Cost exports, utilization queries, recommendation reads and AHB audits cost essentially nothing. The only thing that costs money is the purchase itself — which is exactly why you practice the analysis until you are confident, and treat the purchase as the irreversible, finance-approved step it is.

Interview & exam questions

Mapped to AZ-104, AZ-305, and the FinOps Certified Practitioner body of knowledge.

1. When does a reservation beat a compute savings plan? When the footprint is stable in both SKU and region for the term. The reservation gives a deeper discount for the same usage; the savings plan only wins when the shape (SKU/region/OS/service) is uncertain even though the spend is stable.

2. What does a compute savings plan cover that a VM reservation does not? Breadth across services and shape: VMs plus App Service, Container Instances, Functions Premium and dedicated hosts, and across SKU family, region and OS — applied automatically to the highest-rate eligible usage first. A VM reservation is per-resource-type and SKU/region-pinned.

3. Explain the difference between coverage and utilization. Coverage is the fraction of eligible usage already under a commitment (low = money on the table). Utilization is the fraction of a purchased commitment actually consumed (low = over-bought). You want both high; they fail independently.

4. Why size to the 5th-percentile floor rather than the average? The floor is the minimum sustained concurrency — the quantity you run essentially all the time, so a reservation on it stays ~100% utilized. Committing to the average guarantees under-utilization during every trough.

5. What changed about VM reservation exchanges, and what is the intended flexibility path now? Microsoft ended like-for-like compute reservation exchanges for purchases after a cutoff date. The intended path to flexibility is the compute savings plan, which is SKU/region/OS-agnostic by design.

6. Can you cancel a savings plan? What is the implication? No — savings plans are non-cancellable and non-refundable for the term. The implication is that you size them conservatively, below your true floor, because over-committing is cash you cannot recover.

7. How does Azure Hybrid Benefit relate to a reservation on a Windows VM? They stack — AHB removes the license meter while the reservation discounts the compute meter. The published reserved Windows rate already excludes the license, so reserved-rate-plus-owned-license is the deepest Windows price.

8. Why must you NOT apply AHB to a dev/test subscription? A Dev/Test (EA or PAYG Dev/Test) subscription already zeroes the Windows/SQL license charge for VS subscribers. Applying AHB there double-counts — it doesn’t discount further and it consumes an SA entitlement a production VM could have used.

9. A reservation is under-utilizing. What is the first, cheapest fix? Re-scope it — change the applied scope (e.g., single-subscription → shared or management-group) to reach matching usage elsewhere. Scope changes are free and instant; refunds carry a fee and a $50k/12-month cap.

10. Why report on amortized rather than actual cost? Amortized spreads an upfront purchase across the term, revealing true daily run-rate and effective per-team rates; actual books the purchase as a lump on buy-day, hiding the run-rate and making utilization impossible to read.

11. What is instance size flexibility and how does it differ from a savings plan’s flexibility? A VM reservation flexes within a single SKU family by a published ratio (e.g., one D8s_v5 covers two D4s_v5). A savings plan flexes across families, regions, OS and services. Size flexibility does not add region flexibility.

12. How do you decide reservation scope for a central platform team with strict chargeback? Use management-group scope: it maximizes utilization within an org boundary while preventing cross-subscription subsidy that shared scope allows. Reconcile per-team cost using amortized (effective) rates.

Quick check

1. You have a fleet stable in spend but actively migrating from D-series to E-series across two regions. Which instrument fits, and why?
2. A 3-year VM reservation drops to 55% utilization after a migration. Rank your options from cheapest to most expensive.
3. Your savings-plan utilization sits at 85% indefinitely. Can you cancel it? What do you do?
4. A production Windows VM shows licenseType = None and you own the SA. What are you losing, and how do you fix it?
5. Why should AHB never be applied to a Dev/Test subscription?

Answers

1. A compute savings plan — it is SKU-, region- and OS-agnostic, so it keeps applying through the D→E migration and the second region. A reservation would strand on the abandoned SKU/region. Size it from the p5 hourly spend across both regions and families combined.
2. Cheapest to most expensive: (a) re-scope to where matching usage runs (free); (b) let it lapse on the residual footprint while moving the flexible part to a savings plan (no cost, just time); © refund (early-termination fee + $50k/12-month cap — last resort). VM exchange is unavailable for post-cutoff purchases.
3. No — savings plans are non-cancellable. Let the current one run to term and size the next purchase at ~90–95% of the proven floor. The 85% tells you the original commit was set above the true floor.
4. You are paying the Windows license portion of the meter that AHB would remove — money on the floor. Fix with az vm update --license-type Windows_Server (and set it in IaC so a redeploy doesn’t revert it). Reconcile the seat against owned SA.
5. A Dev/Test subscription already zeroes the Windows/SQL license charge for VS subscribers. AHB there does not discount further and consumes an SA entitlement a production VM could have used — a double-count that wastes a license seat.

Glossary

• Reservation — A pre-paid commitment to a specific compute SKU + region (or instance-size-flexible group) for 1 or 3 years, in exchange for the deepest discount; strands if the workload moves off the SKU/region.
• Compute savings plan — A commitment to a fixed hourly dollar spend on eligible compute (VMs, App Service, ACI, Functions Premium, dedicated hosts) for 1 or 3 years; flexes across SKU/region/OS/service; non-cancellable.
• Pay-as-you-go (PAYG) — List-price billing with no commitment; the liquidity reserve for spiky or uncertain usage.
• Azure Hybrid Benefit (AHB) — A licensing benefit that lets you bring owned Windows Server / SQL Server licenses (with Software Assurance) to Azure and drop the license portion of the meter; a resource property, not a purchase; stacks on compute discounts.
• Software Assurance (SA) — The Microsoft licensing benefit that enables AHB; the entitlement AHB asserts and that a license audit can verify.
• Coverage — The fraction of eligible usage already under a commitment; low coverage on a stable workload means money left on PAYG.
• Utilization — The fraction of a purchased commitment actually consumed; below ~95% on a reservation means you over-bought.
• Amortized cost — A cost view that spreads an upfront commitment purchase across its term, revealing true daily run-rate and effective per-team rates.
• Applied scope — The property that decides which usage a reservation may discount: single resource group, single subscription, management group, or shared.
• Instance size flexibility — A VM reservation’s ability to apply its discount to other sizes within the same family by a published ratio.
• Exchange — Swapping one reservation for another; ended for compute/VM reservations on new purchases (use a savings plan instead); still allowed for non-compute reservations.
• Refund / cancellation — Returning a reservation for prorated value, subject to an early-termination fee and a $50,000-per-billing-scope annual cap.
• Dev/Test subscription — An EA or PAYG subscription type that zeroes the Windows/SQL license charge for Visual Studio subscribers’ non-production workloads; AHB should not be added on top.
• Recommendation engine — Cost Management’s suggested hourly/quantity commitment with a projected utilization, based on recent usage; optimistic — haircut it 5–10%.
• Effective rate — The post-discount per-unit price a team actually pays, visible only in amortized cost; should sit below list when a commitment is landing.

Next steps

• Build the cost-management foundation this depends on with the Azure FinOps & Cost Engineering Guide and operationalize it at scale via Azure FinOps Cost Management at Scale.
• Get accurate allocation — the prerequisite for honest coverage and showback — from Tagging & resource organization for cloud cost visibility.
• Understand the compute these commitments discount, end to end, in the Azure VM Deep Dive: Every Setting, and the interruptible end of the spectrum in Azure specialized compute: dedicated hosts, Spot, confidential, HPC & batch.
• Pay down the licensing that AHB targets hardest with Azure SQL Database: Hyperscale, elastic pools, ledger & Always Encrypted.
• Enforce the AHB and license-type defaults as guardrails with Azure Policy & governance at scale.