Cost

Buy Azure VMware Solution reserved instances

One capability across an Azure VMware Solution estate: pay for the host nodes you are going to run anyway up front, on a one or three year commitment, and let the reservation discount strip the on-demand premium out of the compute and bundled licensing.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Reserving Azure VMware Solution hosts: the basics

What does Azure Advisor mean when it says 'Consider Azure VMware Solution reserved instance to save over the on-demand costs'?

Azure VMware Solution runs your VMware estate on dedicated bare-metal host nodes inside Azure, billed per host per hour. By default those hosts run at pay-as-you-go rates, which is the right price for capacity you might switch off tomorrow and the wrong price for a private cloud you have committed to for years. Azure Advisor watches the steady-state host count and, when it sees a baseline that has been running long enough to be predictable, raises the reservations recommendation 'Consider Azure VMware Solution reserved instance to save over the on-demand costs' (recommendation ID 10aedd06-621e-4b4f-a45c-5256573e0191).

A reserved instance is a billing commitment, not a different host. You commit to a number of Azure VMware Solution hosts of a given size, in a given region, for a one or three year term, and Microsoft applies a reservation discount to any matching running hosts. The reservation covers the compute part of your usage and includes the bundled VMware software licensing, vSphere, vSAN, NSX and HCX, so the discount lands on the largest line on the Azure VMware Solution bill rather than a sliver of it. Nothing about the cluster changes: the same hosts keep running, the workloads do not move, only the rate they are billed at drops.

The mechanics are simple once you see them. Your usage that gets a reservation discount has an effective price of zero, so the reserved capacity does not incur any additional charge on top of the up-front purchase. You pay for the commitment, that prepayment burns down against the matching hosts hour by hour, and anything above the reserved count keeps running at pay-as-you-go. The job is to find the host baseline you are confident will keep running, reserve exactly that, and leave the variable top end on demand.

In this lesson you will learn how Azure VMware Solution host billing works, why Advisor raises the reserved-instance recommendation, how to size a commitment to the host baseline you are confident in, and how to purchase it through the portal or the az CLI without over-buying. You will also see why the sizing decision matters, because while an over-bought commitment can be exchanged or refunded under the standard self-service process, the refund is prorated and capped, so unwinding a mistake is slow and partial.

Fun fact

The dedicated host that never sleeps

Unlike an idle virtual machine you can deallocate to stop the meter, an Azure VMware Solution host is dedicated bare metal: it is yours, reserved for your private cloud, and it bills around the clock whether the workloads on it are busy or quiet. That is precisely why the reservation maths is so favourable here. The capacity is already paid for every hour it exists, so committing to a baseline you were always going to run does not change your behaviour at all, it only changes the rate. The reservation discount lands on a host that, by its nature, was never going to be switched off to save money in the first place.

Reading the Advisor recommendation and sizing the commitment

Priya runs platform engineering for a firm that migrated its VMware estate onto Azure VMware Solution eight months ago. Two private clouds have settled into a steady host count, and the monthly bill has stopped moving. Azure Advisor has raised the reserved-instance recommendation against the subscription.

Rather than accept the headline number, Priya starts by pulling the recommendation itself, so she can see the host SKU, region and baseline Advisor has detected before deciding how much to commit.

Start by listing the cost recommendations and reading the Azure VMware Solution reservation Advisor has raised. This is the baseline Microsoft thinks is safe to reserve.

$ az advisor recommendation list --category Cost --query "[?contains(shortDescription.problem, 'VMware')].{problem:shortDescription.problem, sku:extendedProperties.displaySKU, region:extendedProperties.location, term:extendedProperties.term}" -o table

Problem Sku Region Term

---------------------------------------------------------- ----- -------- ----

Consider Azure VMware Solution reserved instance to save.. AV36 uksouth P3Y

# Advisor sees a steady AV36 host baseline in uksouth worth committing for 3 years.

Advisor recommends against the steady-state baseline it has observed, not your peak. Read the SKU, region and term before you size the purchase, and reserve at or below this baseline, never above it.

How an Azure VMware Solution reservation actually applies the discountdeep dive

A reservation is defined by a small set of attributes that must match a running host for the discount to apply: the host SKU (Azure VMware Solution reservations are sold against the host size, such as AV36), the region, the term, the quantity of hosts, and the scope. Each hour, Azure looks for running Azure VMware Solution hosts in scope that match those attributes and applies the reservation discount to them, giving that usage an effective price of zero against the prepaid commitment. Any matching host beyond the reserved quantity is billed at pay-as-you-go, and any reserved quantity with no matching host that hour is simply unused: the commitment is spent whether or not a host consumed it.

Scope is the lever that decides how widely the discount can land. A single subscription scope applies the discount only to matching hosts in that subscription; a single resource group scope narrows it further; a shared scope spreads it across all eligible subscriptions in the billing context, which for an Enterprise Agreement is the enrollment; and a management group scope applies it across the subscriptions in a chosen management group. Shared scope is the safest default for fully using a commitment, because it lets the discount float to wherever a matching host happens to run rather than stranding it in one subscription.

The attributes you cannot change in place after purchase are the ones that make sizing matter. Region, SKU, quantity and term are fixed for the life of the reservation; you can update the scope, split or merge reservations and change ownership, but you cannot shrink the quantity or shorten the term directly. To change those you exchange the reservation. Azure VMware Solution reservations sit in the same compute family as virtual machine reservations, so an over-bought commitment can be exchanged or refunded through the same self-service process, but only within limits: the refund is prorated to the days left and the cancelled commitment across the billing scope cannot exceed 50,000 USD in a rolling 12 month window, and a refund returns money rather than the lost reserved-rate saving. That friction is why the discipline is to reserve the certain floor and no more.

What is the impact of leaving the baseline on demand?

The direct impact is the on-demand premium, paid every hour on hosts you were always going to run. Azure VMware Solution hosts are large, bundled units of compute and licensing, so the premium on even a modest steady-state cluster compounds into a meaningful number over a multi-year platform life. Microsoft does not publish a single headline percentage for Azure VMware Solution specifically, but the structure is the same as every Azure reservation: the reserved rate is materially below on-demand, and the three year term discounts deeper than the one year. Leaving the committed baseline unreserved is, in effect, a recurring overpayment with no offsetting benefit, because the capacity is not going anywhere.

The second-order impact is forecasting noise. An estate billed entirely at on-demand rates has a bill that drifts with hourly usage and offers no committed-cost floor to plan against. A reserved baseline converts the predictable part of the spend into a known, prepaid number, which makes the rest of the forecast tighter and the variable top of the estate easier to see and reason about.

There is a real cost to getting it wrong in the other direction, though. An over-sized commitment can be exchanged or refunded under the standard self-service process, but the refund is prorated to the days remaining and capped at 50,000 USD across the billing scope in a rolling 12 month window, so a large over-commitment cannot be cleanly reversed. The impact of over-buying is therefore not symmetric with the impact of under-buying: under-reserving leaves some saving on the table that you can capture later by buying more, while over-reserving ties up spend against hosts that may no longer exist and recovers only a prorated, capped fraction of it. The whole discipline of this capability is to make that asymmetry work for you by committing only the floor.

How do you buy the reservation without over-committing?

Work the decision as a sizing problem, not a purchasing one. The order matters: confirm the true baseline and the eligibility prerequisites before you buy, because unwinding an over-sized reservation means a prorated, capped self-service refund rather than a clean reversal.

1. Confirm the steady-state baseline

Read the Advisor recommendation and compare it against your own host count over the last several months. The number to reserve is the floor you are confident will still be running for the term, not the current count and not the peak. When in doubt, reserve below the baseline: under-committing is recoverable by buying more, over-committing is not.

2. Check eligibility and quota before you buy

An Azure VMware Solution reservation needs an eligible billing account, typically an Enterprise Agreement or Microsoft Customer Agreement, the owner or reservation purchaser role on the funding subscription, and, for a single or shared scope, sufficient host quota in the subscription. Resolve any quota gap with a host quota increase request first, so the purchase does not fail or strand the discount.

3. Calculate the price, then choose term and billing plan

Run the calculate step to see the exact commitment for the SKU, region, quantity and term before committing money. Choose the three year term for the floor you are most certain of to bank the deepest discount, and a one year term for capacity you are less sure of. Pick monthly or upfront billing to suit cash flow; neither changes the discount.

4. Scope it widely and purchase the floor only

Use shared scope, or a management group scope, so the discount can float to any matching host across the billing context rather than stranding in one subscription. Purchase exactly the certain baseline, leave the variable top of the estate on demand, and review the commitment at each renewal rather than over-buying to chase a marginally larger discount.

# 1. Price the commitment first: AV36 hosts, 3-year term, shared scope, monthly billing.
#    Reserve the certain baseline only (here: 4 hosts). Replace <billing-subscription-id>.
az reservations reservation-order calculate \
  --reserved-resource-type AVS \
  --sku AV36 \
  --location uksouth \
  --term P3Y \
  --billing-plan Monthly \
  --quantity 4 \
  --applied-scope-type Shared \
  --billing-scope "<billing-subscription-id>" \
  --display-name "avs-uksouth-floor"

# 2. The calculate response returns a reservationOrderId. Purchase against it once the
#    price and the host count are confirmed. This is the committing step.
az reservations reservation-order purchase \
  --reservation-order-id "<reservation-order-id-from-calculate>" \
  --reserved-resource-type AVS \
  --sku AV36 \
  --location uksouth \
  --term P3Y \
  --billing-plan Monthly \
  --quantity 4 \
  --applied-scope-type Shared \
  --billing-scope "<billing-subscription-id>" \
  --display-name "avs-uksouth-floor"

Quick quiz

Question 1 of 5

Azure Advisor raises 'Consider Azure VMware Solution reserved instance to save over the on-demand costs'. What does buying the reservation actually change?

Keep learning

Go deeper on how Azure VMware Solution reservations are purchased, priced and applied, and how Advisor builds the recommendation behind them.

You can now treat the Advisor reservation recommendation as a sizing decision rather than a one-click purchase: read the SKU, region and baseline Advisor detected, confirm the floor you are confident will run for the term, check eligibility and quota, calculate the price, and commit exactly that certain baseline at a widely scoped reservation, leaving the variable top of the estate on demand. Because unwinding an over-bought reservation means a prorated self-service refund capped at 50,000 USD in a rolling 12 month window, the discipline is to under-commit rather than over-commit and re-size at each renewal.

Back to the library

Reserving Azure VMware Solution hosts: the savings view

Converting a predictable on-demand host baseline into a discounted, prepaid commitment

Azure VMware Solution host nodes are among the largest single line items an Azure bill can carry, because each host bundles dedicated compute and the full VMware licence stack. Running that baseline at pay-as-you-go rates means paying the on-demand premium every hour on capacity you already know you will keep. A reserved instance removes that premium on the committed hosts: same hardware, lower rate, in exchange for a one or three year commitment. This is the clearest cost lever in the Azure VMware Solution estate, and Advisor surfaces it precisely because the saving against on-demand is material.

The decision is a commitment trade, not a spend increase. You are not buying more capacity; you are pre-committing to capacity you are running anyway. The three year term discounts deeper than the one year, and the choice between them is a forecast question: how confident are you that this host count is still running in eighteen months? Reserve the floor you are certain of, leave the variable top on demand, and you capture most of the saving with almost none of the lock-in risk.

Frame the payback explicitly. A reservation has an up-front or monthly cost and a defined term; the saving is the difference between the on-demand run rate and the reserved rate over that term, against the hosts the reservation actually matches. The risk is a reservation that does not get used. Azure VMware Solution reservations sit in the same compute family as virtual machine reservations, so an over-bought commitment can be exchanged or refunded under the standard self-service process, but only within limits: refunds are prorated to the days left and the cancelled commitment across your billing scope cannot exceed 50,000 USD in a rolling 12 month window. That friction is exactly why the sizing question, reserve the certain baseline only, is the whole game.

This lesson is for the finance partner who sees the Advisor reservation recommendation and wants to know what it saves, what the payback is, and where the risk sits. It covers how to read the recommendation, how to size the commitment so it is fully used, why one year versus three years is a forecast call, and why an over-bought commitment is awkward to unwind, since the self-service refund is prorated and capped at 50,000 USD in a rolling 12 month window.

Fun fact

The dedicated host that never sleeps

How a finance partner frames the reservation decision

Priya is the finance partner for the platform team, and the Advisor recommendation has landed on her desk with an annual-savings figure attached. The instinct is not to wave the headline number straight into the forecast; it is to interrogate the commitment behind it. The recommendation is for a baseline of AV36 hosts in UK South over a three year term, and the saving is the difference between what those hosts cost at on-demand rates today and what they would cost reserved. Her first question is whether that host count is genuinely the floor, the number running in eighteen months in the most pessimistic plausible plan, or whether Advisor has measured a temporary high water mark.

She splits the decision into a certain part and an uncertain part. The hosts the business cannot run the platform without are the floor, and those go onto a three year reservation to capture the deepest discount. Any hosts that exist because of a migration in flight, or a project that might wind down, are left on demand or, at most, put on a one year term where the lock-in is shorter. The finance pack reads: 'We commit the certain baseline for three years and bank the largest saving against on-demand, we leave the variable top of the estate on demand so we keep flexibility where it is worth paying for, and because unwinding an over-bought reservation means a prorated refund capped at 50,000 USD in a rolling 12 month window, we deliberately under-commit rather than over-commit.' The payback is stated as the term length over which the reserved rate beats the on-demand run rate, and the named risk is unused commitment, which the sizing discipline is built to avoid.

Why the reservation belongs on the savings plan, sized to the floor

The saving here is real, recurring and easy to forecast, which makes it one of the cleanest cost wins in an Azure VMware Solution estate. The reserved rate beats on-demand on the committed hosts for the whole term, and because the hosts are dedicated capacity that runs around the clock, the reservation is used to its full extent as long as it is sized at or below the true baseline. The payback is the point in the term at which the cumulative reserved cost drops below the cumulative on-demand cost it replaced; for a baseline that genuinely keeps running, that crossover is well inside the term.

The cost of getting it wrong is asymmetric and worth stating plainly on the savings plan. Under-committing means you captured slightly less saving than you could have, recoverable by buying more later. Over-committing means prepaying for hosts you may switch off, and while the reservation can be exchanged or refunded through the standard self-service process, the refund is prorated and capped at 50,000 USD across the billing scope in a rolling 12 month window, so the money is recovered slowly and only in part. The finance role is to pin the commitment to the floor the business is certain of, choose the term that matches that certainty, and book the saving against the on-demand baseline it actually displaces, not against a hoped-for peak.

What finance can do about the reservation decision

Finance cannot purchase a reservation in the portal, but it owns the framing that turns an Advisor headline into a deliberately sized commitment with a stated payback and a named risk. Three levers.

1. Size to the certain floor, not the Advisor headline

Advisor measures a baseline that may include temporary capacity. Make explicit that the number to commit is the host count the business is confident will still be running for the whole term, in the most pessimistic plausible plan. Anything less certain belongs on a shorter term or stays on demand. Because unwinding an over-bought reservation means a prorated refund capped at 50,000 USD in a rolling 12 month window, the rule is to under-commit rather than over-commit and buy more later if the floor proves higher.

2. State the payback and the term trade explicitly

Book the saving as the difference between the on-demand run rate and the reserved rate over the term, against the hosts the reservation actually matches, not against a hoped-for peak. Make the one year versus three year choice a forecast decision on the record: the three year term banks the deepest discount but extends the commitment, so it belongs only on the host count the business is most certain of.

3. Track utilisation so the commitment stays fully used

A reservation only saves money on hours where a matching host runs. Put reservation utilisation on the cost review: if reserved hosts are sitting unused, the commitment was over-sized and the saving is leaking. Pair that with a renewal calendar so each term is re-sized against the current floor rather than rolled over blindly, which keeps the commitment matched to reality as the estate evolves.

Quick quiz

Question 1 of 5

Advisor attaches an annual-savings figure to the Azure VMware Solution reservation recommendation. As the finance partner, what is the right way to treat that number?

Keep learning

Go deeper on how Azure VMware Solution reservations are purchased, priced and applied, and how Advisor builds the recommendation behind them.

You have finished the finance view of Azure VMware Solution reservations. You know the saving is the gap between the on-demand and reserved rates over the term, that it is real only on hosts the reservation matches, and that the term choice is a forecast call. You know the risk is over-commitment rather than under-commitment, because although these reservations can be exchanged or refunded under the standard process, the refund is prorated and capped at 50,000 USD in a rolling 12 month window, so you will size to the certain floor, state the payback explicitly, and track utilisation at each review.

Back to the library

Reserving Azure VMware Solution hosts: the headline

Whether the committed part of the private cloud is being paid for at the committed-use rate or the on-demand one

Azure VMware Solution is usually a multi-year platform decision: a private cloud lifted into Azure that the business intends to run for years. Paying for that long-lived baseline at hourly on-demand rates is leaving money on the table every hour, and Advisor flags it because the gap is large and avoidable.

The leadership question is not 'should we use reservations?' It is 'what fraction of our steady-state host count are we confident enough about to commit, and are we capturing that saving?' A reservation on the certain baseline is close to free money: the same platform, billed lower, in return for a commitment to capacity already in production. The main risk is over-committing to hosts that later get switched off: an over-bought reservation can be exchanged or refunded, but refunds are prorated and capped at 50,000 USD across the billing scope in a rolling 12 month window, so unwinding a large over-commitment is slow and partial rather than a clean reversal.

This is a return-on-investment decision, not a security or reliability one. The reservation changes nothing about how the platform runs; it changes only the rate. The defensible position is a deliberate, sized commitment on the predictable floor, reviewed each term, with the variable top of the estate left on demand so flexibility is preserved exactly where it is worth paying for.

A short read for the leader who needs to know why the committed part of an Azure VMware Solution estate should be paid for at the reserved rate, how large the saving is relative to its risk, and what a defensible, deliberately sized commitment looks like across a multi-year platform.

Fun fact

The dedicated host that never sleeps

What it looks like when the committed baseline is paid for at the committed rate

When the CFO reviewed the Azure VMware Solution bill at quarter end, the question was blunt: this is a platform we have committed to for years, so why are we paying for it by the hour like something we might turn off tomorrow? The honest answer was that nobody had yet converted the steady-state host baseline from on-demand rates to a reservation, so the business was paying the on-demand premium every hour on capacity it had no intention of giving up.

The response was to treat the reservation as a deliberate commitment sized to the floor, not a blanket purchase. The team confirmed the host count the platform could not run without, reserved exactly that for three years to bank the deepest discount, and left the variable top of the estate on demand where the flexibility was genuinely worth the premium. The next quarter the answer to the CFO's question had changed from 'we are paying on-demand on everything' to 'the committed baseline is on the reserved rate, the variable capacity is on demand by design, and the commitment is sized so every reserved host is used.' That shift, from paying the on-demand premium on a multi-year platform to paying the committed-use rate on the part of it that is genuinely committed, is the return this capability delivers, and it changes nothing about how the platform runs.

Why this is a board-level savings decision

An Azure VMware Solution estate is a multi-year commitment to a platform, and the largest avoidable cost on it is paying the on-demand premium on the part of that platform you have already committed to. Reserving the steady-state baseline converts that overpayment into a known, discounted, prepaid line, with no change to how the platform runs. This is the rare cost decision where the saving is large, the operational risk is nil, and the only thing to get right is the size of the commitment.

The downside to manage is over-commitment, not under-commitment. An over-bought reservation can be exchanged or refunded, but the refund is prorated and capped at 50,000 USD across the billing scope in a rolling 12 month window, so a large over-commitment is recovered only slowly and partially. The leadership instruction should therefore be to commit deliberately to the certain floor and review at each term, rather than to chase the maximum possible discount by over-buying. Sized that way, the reservation is close to free money on a platform the business was always going to keep running.

The leadership move on the reservation

The executive handle is not to approve a specific purchase; it is to require that the committed part of the platform is paid for at the committed rate, sized deliberately to the floor, and reviewed each term.

1. Set the policy: commit the floor, leave the top on demand

Ask for the steady-state host baseline to be reserved and the variable capacity to be left on demand by design, so flexibility is preserved exactly where it is worth paying for. The goal is not to maximise the headline discount by reserving everything; it is to capture the saving on the part of the estate that is genuinely committed, with no commitment against capacity that might be switched off.

2. Treat over-commitment as the real risk

An over-sized commitment can be exchanged or refunded, but the refund is prorated and capped at 50,000 USD across the billing scope in a rolling 12 month window, so a large over-commitment ties up spend that comes back only slowly and partially. Make clear that under-committing is the safer error: the saving missed by reserving too little is recoverable later in full, the money lost by reserving too much is recovered only slowly and in part. A deliberately conservative commitment is the right posture.

3. Ask for utilisation and a renewal review, not a one-off purchase

The proof that this is working is not the purchase; it is a reservation that stays fully used and is re-sized at each renewal against the then-current floor. Ask for utilisation on the cost review and a renewal decision at each term end, so the commitment tracks the platform as it grows or shrinks rather than drifting out of step with it.

Quick quiz

Question 1 of 5

At a review you ask whether the Azure VMware Solution estate is being paid for efficiently. What is the defensible end state to look for?

Keep learning

Go deeper on how Azure VMware Solution reservations are purchased, priced and applied, and how Advisor builds the recommendation behind them.

Two takeaways. The committed part of an Azure VMware Solution platform should be paid for at the committed-use rate, not the on-demand one: the reservation changes only the bill, not how the platform runs, so it is close to free money on the certain baseline. And the risk to manage is over-commitment, because unwinding an over-bought reservation means a prorated refund capped at 50,000 USD in a rolling 12 month window, so the defensible posture is a deliberate, conservatively sized commitment on the floor, reviewed at each term, with the variable top of the estate left on demand.

Back to the library

Part of the learning path Lock in Azure commitments

Buy Azure VMware Solution reserved instances

Reserving Azure VMware Solution hosts: the basics

The dedicated host that never sleeps

Reading the Advisor recommendation and sizing the commitment

How an Azure VMware Solution reservation actually applies the discountdeep dive

What is the impact of leaving the baseline on demand?

How do you buy the reservation without over-committing?

1. Confirm the steady-state baseline

2. Check eligibility and quota before you buy

3. Calculate the price, then choose term and billing plan

4. Scope it widely and purchase the floor only

Quick quiz

Keep learning

Reserving Azure VMware Solution hosts: the savings view

The dedicated host that never sleeps

How a finance partner frames the reservation decision

Why the reservation belongs on the savings plan, sized to the floor

What finance can do about the reservation decision

1. Size to the certain floor, not the Advisor headline

2. State the payback and the term trade explicitly

3. Track utilisation so the commitment stays fully used

Quick quiz

Keep learning

Reserving Azure VMware Solution hosts: the headline

The dedicated host that never sleeps

What it looks like when the committed baseline is paid for at the committed rate

Why this is a board-level savings decision

The leadership move on the reservation

1. Set the policy: commit the floor, leave the top on demand

2. Treat over-commitment as the real risk

3. Ask for utilisation and a renewal review, not a one-off purchase

Quick quiz

Keep learning

Related cost lessons