Cost

Reserve virtual machine instances for steady workloads

One capability across the compute estate: find the virtual machines that run around the clock at a stable size, and stop paying the on-demand rate for capacity you were always going to use, by committing to a one or three year reservation.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Reserving VM instances: the basics

What is Azure Advisor actually telling you to buy?

A pay-as-you-go virtual machine bills at the on-demand rate for every hour it runs, whether it ran for an afternoon or has run continuously for two years. The on-demand rate is the price of flexibility: you can stop the machine at any moment and stop paying. For a workload that is never going to stop, a steady production fleet that runs at the same size month after month, that flexibility is something you are paying for and not using. An Azure reservation is the way to hand the flexibility back in exchange for a lower rate. You commit to a specific virtual machine size in a region for one or three years, pay either monthly or upfront, and the reservation discount applies automatically to any matching machine that runs.

Azure Advisor turns this into a concrete recommendation: 'Consider virtual machine reserved instance to save over the on-demand costs' (recommendation ID 84b1a508-fc21-49da-979e-96894f1665df, on the subscription resource type). Advisor analyses your actual virtual machine usage over a look-back window, identifies the sizes you run consistently, and tells you how many instances of each to reserve and what you would save. The recommendation does not change anything on its own. It is a prompt to convert steady, already-committed usage into committed pricing.

The work is not 'buy reservations'. It is to separate the virtual machines that genuinely run steady-state from the ones that scale up and down or get torn down between sprints, reserve only the steady base, and pick the term and scope that match how confident you are. Reserve too little and you leave money on the table; reserve a machine you are about to retire and you have committed to capacity you no longer need. The capability is matching commitment to the part of the fleet that was never going anywhere.

In this lesson you will learn how Azure prices steady compute, how Advisor identifies which virtual machines are worth reserving, and how to buy the right reservation, the right size, term, scope and instance size flexibility, without committing to capacity you are about to retire. The walkthrough uses the az CLI to read the recommendation, price a reservation before buying, and place the order.

Fun fact

Paying a deposit you never get back

The on-demand rate on a cloud virtual machine is best thought of as a standing option premium: you pay extra, every single hour, for the right to switch the machine off at a moment's notice. For a development box you spin up and tear down, that option is worth every penny. For a production database server that has run continuously since the day it was deployed and will run for years more, you are buying that option afresh every hour and never once exercising it. A reservation is simply you telling Azure you will not be exercising the option, and Azure handing back most of the premium in return. The machine does not change. Only the price does.

Finding what is worth reserving across a subscription

Priya runs the platform team at a SaaS company whose Azure bill has grown with the product. Cost Management shows compute as the largest line, and most of it is a stable production fleet that has not changed size in months. Azure Advisor is surfacing the virtual machine reservation recommendation on two of their subscriptions.

Rather than buy reservations from the portal estimate alone, Priya starts by pulling the Advisor recommendation and listing the running machines, so she can separate the steady base load that is worth reserving from the autoscaled and short-lived machines that are not.

Pull the Advisor cost recommendations for the subscription and look for the virtual machine reservation prompt. This is the same recommendation the portal shows, read straight from the API.

$ az advisor recommendation list --category Cost --query "[?contains(shortDescription.solution, 'reserved instance')].{problem:shortDescription.problem, impact:impact}" -o table

Problem Impact

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

Consider virtual machine reserved instance to save over the on- High

demand costs

# Advisor sized this from your real usage. Now confirm WHICH VMs are steady.

Advisor flags the opportunity and its size, but it is per subscription. Before buying, confirm which machines actually run steady-state so you reserve the base, not the peak.

How an Azure VM reservation actually applies the discountdeep dive

A reservation is a billing construct, not a compute resource. When you buy one you choose a virtual machine size (the SKU, for example Standard_D4s_v5), a region, a quantity, a term of one or three years (P1Y or P3Y), and a scope. You do not attach it to a specific machine. Each hour, Azure looks for running virtual machines that match the reservation's attributes within its scope and applies the discounted rate to them automatically; any matching usage above the reserved quantity falls back to the on-demand rate. If no matching machine runs in a given hour, that hour of the reservation is simply unused.

Two settings decide how widely the discount lands. Scope can be a single subscription, a resource group, a management group, or shared across the whole billing context: a shared scope lets one reservation soak up matching usage anywhere in the enrolment, which keeps utilisation high. Instance size flexibility, when on, applies the discount across other sizes in the same VM size group rather than only the exact SKU you bought, using a published ratio, so a reservation for a smaller size can cover a larger one and vice versa. By default, when the scope is shared, instance size flexibility is on, which is what makes a reservation forgiving of routine resizing.

Because the discount is matched per hour against whatever is running, the saving you actually realise tracks the reservation's utilisation. A reservation that sits over a machine running twenty-four hours a day returns close to its full value; one bought against a machine that gets switched off returns less. This is why the inventory step matters more than the purchase step: the discount is real, but it only pays out on the hours a matching machine is actually running.

What is the impact of leaving steady VMs on the on-demand rate?

The direct impact is straightforward: you pay the on-demand premium, every hour, on capacity you were always going to run. Microsoft documents reserved virtual machine instance discounts reaching up to 72 per cent against pay-as-you-go for the deepest commitments, so for a large, stable production fleet the gap between the on-demand rate and the reserved rate compounds into a significant recurring overspend. Unlike most optimisations this one requires no change to the workload, no resizing, no re-architecting, just a change to the rate you pay for what already runs.

The second-order impact is that the overspend is invisible by default. An on-demand machine does not flag itself as expensive; it just quietly bills at full rate. Advisor is the thing that surfaces the gap, and if nobody owns the recommendation it persists indefinitely. Every month a steady machine stays on the on-demand rate is a month of saving that cannot be recovered retroactively, because the discount only applies from the moment the reservation is bought forward.

There is a real but bounded risk on the other side, which is why this is a decision and not an automatic action. Commit to a size or a workload that then changes, and you hold a reservation that is not fully utilised. Microsoft mitigates this with instance size flexibility, which lets the discount cover neighbouring sizes, and with self-service exchange and refund, so an over-bought or stranded reservation can usually be exchanged or partially returned within published limits rather than wasted. The impact of getting it wrong is therefore a recoverable inefficiency, not a sunk loss.

How do you buy the right reservation safely?

Work this as a portfolio decision, not a single purchase. The order matters: confirm what is genuinely steady before you commit, price the reservation before you buy it, and match term and scope to confidence so you are reserving the base load rather than the peak.

1. Read the recommendation and confirm the steady base

Start from Advisor's virtual machine reservation recommendation, then cross-check it against what actually runs continuously. Advisor sizes its estimate from a look-back window, so a fleet that was temporarily large can be over-recommended. List your running machines by size and reserve below the steady minimum, never above the peak, so the reservation stays fully utilised.

2. Choose term and billing plan by confidence

A one year term (P1Y) paid monthly is the low-risk default: short commitment, the monthly bill simply drops. A three year term (P3Y), and paying upfront, saves more but commits the size and the workload for longer. Put the most durable machines, the core database and API tiers, on the longer term, and the merely-probable ones on the shorter.

3. Set scope and instance size flexibility to keep utilisation high

Prefer shared scope so the discount follows matching usage across subscriptions in the billing context rather than stranding on one. Leave instance size flexibility on for virtual machines so routine resizing within the same VM size group still draws the discount. These two settings are what stop a correctly-sized reservation from going unused after a routine change.

4. Price it, buy it, then monitor utilisation

Always run the calculate step before purchasing so the commitment and saving are confirmed against the live catalogue, never a stale estimate. After buying, track reservation utilisation as an ongoing metric: any reservation persistently below full use is a candidate to exchange or partially refund through Microsoft's self-service process rather than leave stranded.

# 1. Confirm the steady base: list running VMs by size before committing.
az vm list -d --query "[?powerState=='VM running'].{name:name, size:hardwareProfile.vmSize}" -o table

# 2. Price the reservation against the live catalogue BEFORE buying.
#    Reserve below the steady minimum, not the peak. Shared scope + size
#    flexibility keep utilisation high. (Requires: az extension add --name reservation)
billing_sub="<billing-subscription-id>"
az reservations reservation-order calculate \
  --reserved-resource-type VirtualMachines \
  --sku Standard_D4s_v5 \
  --location eastus \
  --quantity 3 \
  --term P3Y \
  --billing-plan Monthly \
  --applied-scope-type Shared \
  --billing-scope "$billing_sub" \
  --instance-flexibility On \
  --display-name prod-d4sv5-3yr

# 3. Place the order once the calculated price and saving look right.
az reservations reservation-order purchase \
  --reservation-order-id "$(cat /proc/sys/kernel/random/uuid)" \
  --reserved-resource-type VirtualMachines \
  --sku Standard_D4s_v5 \
  --location eastus \
  --quantity 3 \
  --term P3Y \
  --billing-plan Monthly \
  --applied-scope-type Shared \
  --billing-scope "$billing_sub" \
  --instance-flexibility On \
  --display-name prod-d4sv5-3yr

Quick quiz

Question 1 of 5

Azure Advisor surfaces 'Consider virtual machine reserved instance to save over the on-demand costs'. What is the most efficient way to act on it?

Keep learning

Go deeper on how Azure prices reserved virtual machines and how to size, scope and manage the commitment.

You can now treat reserved virtual machine instances as one capability: read Advisor's recommendation, confirm which machines genuinely run steady-state, reserve the base load below the peak, and match term, scope and instance size flexibility to how confident you are, pricing the order before you place it and watching utilisation afterwards. The same machines keep running unchanged, they just stop paying the on-demand premium on usage that was never going anywhere.

Back to the library

Reserving VM instances: the savings view

Turning steady, already-committed compute usage into a lower committed rate

This is one of the cleanest savings levers in the Azure bill. The machines Advisor flags are already running and already being paid for at the on-demand rate; a reservation simply lowers the rate on usage that was always going to happen. Microsoft documents the discount on reserved virtual machine instances as reaching up to 72 per cent versus pay-as-you-go for the longest terms and largest commitments, with the realised saving depending on the VM family, region and term you choose. The saving is not a forecast of future behaviour, it is a discount applied to a usage pattern you can already see in the last month of data.

The number that matters is not the headline percentage, it is the payback against the commitment. A one year reservation paid monthly carries almost no cash-flow risk: the monthly bill for that machine simply drops. A three year term paid upfront saves more but ties up the money and the capacity decision for longer. The finance role is to match the term to how confident the business is that the workload, and that VM size, will still be running, and to reserve the steady base rather than the peak.

The downside is bounded and known. Azure reservations are not strictly locked in: Microsoft allows self-service exchanges of compute reservations and refunds, with refunds subject to a documented cap per billing profile in a rolling twelve month window. That means a reservation bought against a workload that later moves or shrinks can usually be exchanged or partially returned rather than written off, which makes the commitment far less risky than it first appears.

This lesson is for the finance partner who sees compute running steadily on the on-demand rate and wants to know how much a reservation saves, how the payback works against a one or three year commitment, and how reversible the decision is. It covers why this is a near risk-free saving on the steady base, where the real trade-offs sit, and how to size the commitment to the workload.

Fun fact

Paying a deposit you never get back

How a finance partner frames the reservation decision

Priya is the finance partner supporting the platform team. The compute line is the biggest item on the Azure bill and it has been flat for months, which is exactly the signature of reservable usage. Advisor estimates the saving per subscription, but the instinct is not to wave the whole estimate through. It is to ask which of those machines are genuinely permanent. Advisor sizes its recommendation from a look-back window, so a fleet that was temporarily large during a migration can be over-recommended; the finance job is to reserve the durable base load and leave headroom.

Priya reframes the recommendation as a payback decision rather than a discount percentage. For each candidate size she asks two questions: how confident are we that this workload runs for the full term, and do we want the cash-flow profile of monthly billing or the deeper saving of paying upfront? The steadiest, longest-lived machines, the production database and the core API tier, go onto a three year term for the largest saving. The merely-probable ones go onto a one year term paid monthly, where the commitment is short and the monthly bill simply falls. The finance pack reads: 'We are converting our steady compute base to committed pricing, sized below peak, with terms matched to confidence, and the commitment is exchangeable if the workload moves.'

Why reservations belong on the savings plan, not the someday list

The cost model here is unusually favourable. The machines in scope are already running and already in the budget at the on-demand rate, so a reservation does not add a workload, it lowers the price of one you are already paying for. The saving begins the hour the reservation is bought and continues for the full term, which means every month of delay is saving that is permanently forgone, not merely deferred.

The risk is the mirror image and it is bounded. The worst realistic case is a reservation bought against a machine that later shrinks or moves, leaving part of the commitment unused. Instance size flexibility absorbs routine resizing, and Microsoft's self-service exchange and refund process, refunds capped per billing profile in a rolling twelve month window, means a genuinely stranded reservation can usually be exchanged for one that fits or partially returned. The finance role is to reserve the confident base load on the right term, monitor reservation utilisation as a first-class metric, and treat any persistent underutilisation as a prompt to exchange rather than a loss to absorb.

What finance can do about the reservation gap

Finance cannot place the order, but it owns the framing that turns a per-subscription Advisor estimate into a confident, right-sized commitment with a known payback and a documented exit. Three levers.

1. Reserve the steady base, not the recommended peak

Make explicit that the goal is to commit only to usage you are confident is permanent. Advisor sizes from a look-back window, so a migration spike or a temporarily large fleet can inflate the recommendation. Ask the team to reserve below the steady minimum so the reservation is fully utilised, and treat the headroom above it as on-demand. Underutilisation is the only way this saving turns into waste, and right-sizing is how finance prevents it.

2. Match the term and billing plan to confidence and cash flow

A three year upfront reservation saves the most but ties up cash and a capacity decision for longest; a one year monthly reservation saves less but carries almost no risk and no cash-flow hit. Map each candidate workload to a confidence level and pick the term accordingly. The metric for the review is realised saving against committed spend, not the headline discount percentage.

3. Treat exchange and refund as a managed control, not a failure

Reservations are not a one-way door. Microsoft supports self-service exchanges and refunds within published limits, including a refund cap per billing profile over a rolling twelve month window. Build that into the plan from the start: monitor utilisation, and when a reserved workload shrinks or moves, exchange the reservation for one that fits rather than absorbing the unused cost. That is what makes a longer term a reasonable bet rather than a gamble.

Quick quiz

Question 1 of 5

Advisor estimates a saving for reserving a fleet of virtual machines. As the finance partner, what is the right starting assumption about that estimate?

Keep learning

Go deeper on how Azure prices reserved virtual machines and how to size, scope and manage the commitment.

You have finished the finance view of reserving virtual machines. You know this is a discount on usage you already pay for, that the saving begins the hour you buy and is forgone for every month you delay, and that the commitment is reversible: instance size flexibility absorbs resizing and Microsoft's exchange and refund process handles a workload that moves. Next time Advisor flags the recommendation, you will reserve the confident base load on a term matched to confidence, track utilisation, and treat any underuse as a prompt to exchange rather than a loss.

Back to the library

Reserving VM instances: the headline

Whether the estate pays the on-demand premium on compute it always intended to run

Every always-on production virtual machine that bills at the on-demand rate is paying a premium for a flexibility the business is not using. Azure Advisor quantifies exactly how much, per subscription, and tells you which sizes to reserve to remove it. This is not a cut to capacity or performance: the same machines keep running at the same size, they just cost less.

The leadership question is not 'should we use reservations?' It is 'what proportion of our steady-state compute is still on the on-demand rate, and why?' Mature estates run their predictable base load on reservations or savings plans and keep on-demand for genuinely variable workloads. A high on-demand share on steady machines is money left on the table every month it persists.

The trade is a commitment of one or three years against a lower rate, and it is a reversible one: Microsoft supports exchanging and refunding compute reservations within published limits. The decision is therefore less 'are we locked in?' and more 'are we confident this workload will still be running?', which is exactly the kind of question leadership is positioned to answer.

A short read for the leader who needs to know why always-on compute on the on-demand rate is an avoidable premium, what proportion of the estate it applies to, and why committing to a reservation is a reversible, low-risk decision rather than a lock-in.

Fun fact

Paying a deposit you never get back

What it looks like when steady compute is on the right rate

At a cost review the CFO noticed that compute was the largest and fastest-growing line, and asked the obvious question: are we getting the best rate on the machines that never turn off? The honest answer at the time was that the production fleet, stable for the better part of a year, was still billing entirely at the on-demand rate because nobody had owned the reservation decision.

The team's response was to treat it as a portfolio rather than a one-off purchase. They pulled Advisor's recommendation, identified the steady base load that ran at a constant size, reserved it on a mix of one and three year terms with shared scope so the discount followed the workload across subscriptions, and left the autoscaling and ephemeral machines on the on-demand rate where the flexibility is genuinely used. The next review showed the same machines running unchanged at a materially lower unit cost, with a documented exchange route if any workload moved. The shift, from paying the on-demand premium by default to reserving the predictable base on purpose, is the saving this capability delivers, and it touches nothing about how the applications run.

Why this is a recurring line on the bill, not a one-off

Steady compute on the on-demand rate is one of the most common avoidable costs in a growing Azure estate, precisely because it requires no mistake to occur: machines simply default to the on-demand rate and stay there. The saving from reserving the predictable base is recurring, it lands every month for the life of the reservation, and unlike a cost cut it does not reduce capacity or slow anything down.

The reason to treat this as a leadership decision rather than delegate it entirely is the commitment, and the reassuring part is how reversible that commitment is. Microsoft supports exchanging and refunding compute reservations within published limits, so the genuine risk is not lock-in but the discipline of buying against truly steady workloads. This is the rare saving that is both large and low-risk: the question to ask is simply why any always-on machine is still on the on-demand rate.

The leadership move on reservations

The executive handle is not to approve individual purchases; it is to require that the steady-state compute base is on committed pricing, sized to confidence, with the on-demand rate reserved for genuinely variable workloads.

1. Set a target for committed coverage of steady compute

Ask the team for the proportion of always-on compute currently on the on-demand rate, and a target for how much should sit on reservations or savings plans. A mature estate runs its predictable base on committed pricing and keeps on-demand for variable load. The gap between today's coverage and that target is recurring saving available every month it is closed.

2. Ask for the payback and the exit, not just the discount

The discount percentage is the headline; the decision is the payback against the commitment and the route out if the workload changes. Ask for the realised saving against committed spend, the term chosen and why, and confirmation that the commitment is exchangeable or refundable within Microsoft's limits. A reservation you can exchange is a low-risk bet, not a lock-in.

3. Make reservation utilisation a standing metric

The saving is only as good as the utilisation. Require that reservation utilisation is reported alongside spend, and that any persistently underused reservation is exchanged or refunded rather than left stranded. That single discipline is the difference between reservations as a clean recurring saving and reservations as shelfware.

Quick quiz

Question 1 of 5

At a cost review you ask why steady compute is on the on-demand rate. What end state should you be looking for as the answer?

Keep learning

Go deeper on how Azure prices reserved virtual machines and how to size, scope and manage the commitment.

Two takeaways. Always-on compute on the on-demand rate is an avoidable, recurring premium that reserving the steady base removes every month without touching how the workload runs. And the commitment is low-risk: Microsoft supports exchanging and refunding compute reservations within published limits, so the real question is not 'are we locked in?' but 'what proportion of our steady compute is still on the on-demand rate, and why?'

Back to the library

Part of the learning path Lock in Azure commitments

Reserve virtual machine instances for steady workloads

Reserving VM instances: the basics

Paying a deposit you never get back

Finding what is worth reserving across a subscription

How an Azure VM reservation actually applies the discountdeep dive

What is the impact of leaving steady VMs on the on-demand rate?

How do you buy the right reservation safely?

1. Read the recommendation and confirm the steady base

2. Choose term and billing plan by confidence

3. Set scope and instance size flexibility to keep utilisation high

4. Price it, buy it, then monitor utilisation

Quick quiz

Keep learning

Reserving VM instances: the savings view

Paying a deposit you never get back

How a finance partner frames the reservation decision

Why reservations belong on the savings plan, not the someday list

What finance can do about the reservation gap

1. Reserve the steady base, not the recommended peak

2. Match the term and billing plan to confidence and cash flow

3. Treat exchange and refund as a managed control, not a failure

Quick quiz

Keep learning

Reserving VM instances: the headline

Paying a deposit you never get back

What it looks like when steady compute is on the right rate

Why this is a recurring line on the bill, not a one-off

The leadership move on reservations

1. Set a target for committed coverage of steady compute

2. Ask for the payback and the exit, not just the discount

3. Make reservation utilisation a standing metric

Quick quiz

Keep learning

Related cost lessons