Reserved Instances vs Savings Plans for Azure Virtual Desktop

How Azure reservations and savings plans work, why autoscaled AVD host pools change the math, how to find the baseline worth committing to with a worked example, and which option fits which pool type. Dated to Microsoft's current terms, with sources.

By David,

Every Azure Virtual Desktop (AVD) cost conversation reaches the same question sooner or later: should we buy Azure Reserved Instances or a savings plan? Both trade a one- or three-year commitment for a lower compute rate. Both are sold as "save up to" a big number. And on AVD, both can quietly cost you money, because the hosts you would commit to are designed to switch themselves off.

This guide explains how each commitment works, why autoscaled host pools change the math, how to find the baseline worth committing to from your own usage, and which option fits which kind of host pool. It's vendor-neutral until the section on where Atlas AVD helps.

The short version: fix scaling first, then commit only to the hosts that run nearly every hour of the week. Put a reservation on that baseline when the VM size and region are settled. Use a savings plan when they aren't, or to cover baselines spread across several sizes and regions. Leave the daytime peak on pay-as-you-go.

Microsoft changes commitment terms and prices from time to time. Everything below reflects Microsoft Learn and Azure's pricing pages as of October 2026, with links to each source so you can check what has changed since.


How each commitment works

A reservation (the VM kind is usually called a Reserved Instance, or RI) is a commitment to a specific VM size family in a specific region for one or three years. A savings plan for compute is a commitment to spend a fixed amount per hour on eligible compute, in any region, for one or three years (Microsoft Learn). Neither changes how your VMs run. They're billing discounts that Azure applies to matching usage after the fact.

Reservation (Reserved VM Instance)Savings plan for compute
You commit toA VM size, in one region, for 1 or 3 yearsA dollar amount per hour, for 1 or 3 years
Discount, per MicrosoftUp to 72% vs pay-as-you-goUp to 65% vs pay-as-you-go
Applies toMatching VMs in the region. With instance size flexibility, other sizes in the same size group.Eligible usage across VM families, regions and other compute services: App Service, Functions Premium, Container Instances, Container Apps, Dedicated Host
CoversThe VM's compute only. Not Windows software, storage or networking.Compute infrastructure only. Not software, storage or networking.
ScopeResource group, subscription, management group or sharedResource group, subscription, management group or shared
Unused hoursLost. A reserved hour with no matching VM running isn't refunded.Lost. Commitment not used in an hour doesn't roll over.
Cancel or refundYes, within a USD 50,000 limit per rolling 12 months. No early termination fee is charged today.No. Savings plans can't be canceled or refunded.
ExchangeYes for now; changing for reservations bought from 1 February 2027No, but reservations can be traded in for a savings plan
PaymentUp front or monthly, same totalUp front or monthly, same total

A few details in that table matter more than they look:

  • The headline percentages are maximums. Microsoft's footnotes base "up to 72%" and "up to 65%" on three-year terms for large M-series VMs (Azure Reserved VM Instances, Azure savings plan for compute). The discount on the D- and E-series sizes most AVD pools use is usually lower, and it varies by size, region and term. Read the real number for your size off your own price sheet or the Azure pricing calculator.
  • Both are hourly and use-it-or-lose-it. Azure applies reservations and savings plans hour by hour. A reserved hour with nothing running to use it is simply gone (Determine what reservation to purchase). This is the whole AVD problem, and the next section is about it.
  • Reservations go first. If you hold both, Azure applies matching reservations before the savings plan, because reservations are narrower and usually deeper (How a savings plan discount is applied).
  • Savings plan rates can move. Like pay-as-you-go prices, savings plan prices can change on the first of a month, and Microsoft applies the current savings plan price to plans already active (What are savings plans?). What's fixed is your hourly commitment.
  • Scope is changeable. You can rescope a reservation after purchase without restarting its term (Buy an Azure reservation). Start with shared scope unless you need to charge one team for it.

Exchange and cancellation rules, as of October 2026

These rules decide how much it costs to be wrong, so they deserve their own paragraph (Self-service exchanges and refunds):

  • Reservations can be returned for a prorated refund, but the total canceled commitment can't exceed USD 50,000 in a rolling 12-month window per billing profile or enrollment. Microsoft isn't charging an early termination fee today, and says it may charge a 12% fee in the future.
  • Compute reservations can still be exchanged under a grace period that runs "until further notice". An exchange that changes size, series or region starts a new term.
  • That's changing. Reservations for services that savings plans cover, including Azure Virtual Machines, that are bought from 1 February 2027 won't be exchangeable. Reservations bought before that date keep one final exchange. Instance size flexibility and the refund policy aren't affected.
  • You can trade a reservation in for a savings plan if the workload has become variable. There's no change to that policy.
  • Savings plans can't be canceled, refunded or exchanged. Size one only to spend you're sure of.

The direction is clear. Reservations are becoming the instrument for workloads you're confident won't change, and savings plans the flexible one. Microsoft's own advice is to right-size first, fix existing commitments next, and only then buy new reservations for stable usage and savings plans for the rest (Decide between a savings plan and a reservation).


The AVD wrinkle: autoscaled pools don't run 24/7

Most commitment advice assumes a server that runs all day. A well-run AVD host pool doesn't. Pooled host pools scale out for the working day and back in at night. Personal desktops deallocate or hibernate when users disconnect. Start VM on Connect lets a pool sit at zero hosts until the first user arrives. That's where most AVD savings come from: Microsoft's own cost guidance puts autoscale first and commitments second (Understand and estimate costs for AVD).

Commitments and scaling pull in opposite directions. A reservation or savings plan bills every hour of its term. Autoscale exists to stop paying for the hours nobody uses. Commit to the number of hosts you run at 10:00 on a Tuesday and you pay for that capacity at 03:00 on Sunday too, when autoscale has switched most of it off. You've paid twice: once for the hosts you need, once for the commitment those hosts no longer use.

So on AVD the question isn't "how many hosts do we run?" It's "how many hosts do we run in nearly every hour of the week?" That number, the baseline, is what's worth committing to.

Two AVD-specific details help:

  • On Windows client session hosts, compute is most of the VM bill. If your users are properly licensed for AVD, you can run Windows 10 or 11 Enterprise and Enterprise multi-session hosts without paying for another Windows license (Apply Windows license to session host VMs). Since reservations and savings plans only discount compute, that's the part of the bill they act on. Windows Server session hosts are different: the discount doesn't touch the Windows Server software charge, which Azure Hybrid Benefit covers if you have eligible licenses.
  • The rest of AVD isn't VMs. Profile storage, image storage, networking and AVD Insights logs aren't covered by either compute commitment. Some storage services sell their own reserved capacity, such as Azure Files, so check the tier your FSLogix shares use.

Finding your baseline from real usage: a worked example

Take a pooled host pool for a 400-person office. Every host is the same VM size in one region. Autoscale runs it like this:

WhenHosts running
Weekdays 00:00 to 06:002
Weekdays 06:00 to 08:00 (ramp-up)6
Weekdays 08:00 to 17:00 (peak)14
Weekdays 17:00 to 20:00 (ramp-down)8
Weekdays 20:00 to 24:003
Weekends2

That's 1,026 host-hours a week. Running all 14 hosts around the clock would be 2,352, so autoscale has already removed more than half the compute bill before any commitment.

Now line the hosts up by how many of the week's 168 hours each one runs:

HostHours running per weekShare of the week
Hosts 1 and 2168100%
Host 39054%
Hosts 4 to 67042%
Hosts 7 and 86036%
Hosts 9 to 144527%

The break-even rule. A commitment for one host costs every hour, at the discounted rate. It pays off only if the host runs for more than (1 − discount) of the hours. At a 40% discount, a host has to run at least 60% of the week. At 30%, it has to run 70%.

To put numbers on it, assume your price sheet shows a 40% discount for a one-year reservation on this size and 30% for a one-year savings plan. These are illustrative assumptions, not Microsoft quotes: use your own rates. Costs are in pay-as-you-go host-hours per week:

ApproachWeekly costvs all pay-as-you-go
Autoscale, all pay-as-you-go1,026baseline
Reserve the 2 baseline hosts89213% less
Savings plan sized to the 2 baseline hosts92510% less
Reserve 6 hosts ("the average daytime load")9953% less
Reserve all 14 hosts ("the peak")1,41138% more

Reserving to the peak is the classic AVD mistake: it costs more than not committing at all, because the reservation keeps billing for the 12 hosts autoscale switches off every night and weekend. Reserving the "average" is better but barely beats pay-as-you-go, because hosts 3 to 6 sit idle too often to repay their commitment. Host 3 alone runs 90 hours against a 100.8-hour reservation cost: a small, guaranteed loss.

The deeper the discount, the lower the bar. A three-year term with a bigger discount can pull hosts 3 to 6 over the line, but only if you're confident the pool will still use that size, in that region, at that scale, three years from now.

How to find the baseline in your own estate

  1. Fix scaling first. If hosts run all night because scaling isn't tuned, today's "baseline" is waste you'd be locking in. Commit after autoscale has settled, not before.
  2. Look at the quietest hours, not the average. The baseline is the number of hosts running at the quietest hour of a normal week: usually the middle of the night at the weekend. Check public holidays, month-end and seasonal peaks too.
  3. Use Microsoft's filter. Microsoft's guidance for sizing a VM reservation is to analyze your usage file and ignore resources with less than 24 hours of usage in a day (Determine what reservation to purchase). For an AVD pool, that's exactly the baseline: the hosts that ran every hour.
  4. Read Azure's recommendations critically. The reservation recommendations in Azure Advisor and the purchase experience simulate your hourly usage over the last 7, 30 or 60 days and pick the quantity with the biggest saving. They're calculated per VM size, not per size group, and they can't know about the pool you're about to resize, migrate or retire. Treat them as an upper bound.
  5. Add pools up before you buy. Several pools of the same size group in the same region can share one shared-scope reservation. Baselines spread across different sizes or regions are where a savings plan earns its place.

Combining a commitment with scaling

Once you know the baseline, set things up so the commitment and autoscale don't fight:

  • Make the baseline explicit. Set your scaling floor to the number of hosts you committed to. In a native AVD scaling plan that's the Minimum percentage of active hosts for the off-peak phase, which is a percentage of the pool's total hosts, so check what it works out to in hosts. A commitment sized for 2 hosts with a floor of zero leaves reserved hours unused every night.
  • Commit to the floor, scale the rest. Autoscale handles everything above the baseline on pay-as-you-go. If you've already committed to more than the floor, raising the floor to match costs little extra compute, since you pay for those hours anyway. But treat it as a sign the commitment is oversized, and fix it at the next exchange, trade-in or renewal.
  • Deallocate, don't just stop. A VM shut down from inside Windows stays allocated and keeps billing compute. AVD autoscale and most scaling tools deallocate. Check any custom scripts do too.
  • Watch for size changes. A reservation is tied to a size group. If you move the pool from one VM series to another, the reservation stops applying and the new hosts run at pay-as-you-go. Exchange the reservation (while that's possible), or cover the new size with a savings plan.
  • Mind the mixed estate. If you hold reservations and a savings plan, Azure uses the reservations first and the savings plan on whatever eligible usage is left. Size the savings plan to the baseline the reservations don't already cover.
  • Monitor utilization monthly. Reservations and savings plans both report utilization in the Azure portal. Anything persistently below 100% is money you're paying for nothing. Trade it in, exchange it or let it lapse at renewal.

Decision matrix: reservation, savings plan or pay-as-you-go, by pool type

Pool typeUsage patternUsually the best fit
Pooled, office hours, autoscaledSmall overnight and weekend floor, large daytime peakReserve the floor if the size and region are settled. Pay-as-you-go for the peak.
Pooled, 24/7 operations (contact center, shift work, global teams)Large, steady baseline every hourReservations for most of the baseline. A savings plan for the part that changes size.
Personal, always onEvery desktop runs around the clockReservations per size group, or a savings plan if desktops use many sizes.
Personal, deallocate or hibernate on disconnect, or Start VM on ConnectEach desktop runs only while its user worksPay-as-you-go. A small savings plan only for the share of desktops that run every hour.
GPU poolsExpensive hosts, often scaled hardReserve only GPU hosts that run every hour. A wasted GPU reservation hour costs far more than a CPU one.
Pilots, proofs of concept, pools mid-migrationSize, region or user count still changingPay-as-you-go until it settles, or a modest savings plan if you're sure of the spend but not the shape.
Supporting VMs (domain controllers, file servers, management VMs)Always on, rarely resizedReservations. These are the easiest commitments in the estate.

If most of your personal desktops still run around the clock, fix that before you commit to anything. Pooled vs Personal Host Pools in AVD covers how to take them off the meter.

Two more questions settle the close calls:

  • How sure are you about the next one or three years? A savings plan follows you through a change of VM series, a region move or a shift of workloads to App Service or containers. A reservation follows size changes only within its size group, and one bought from February 2027 can't be exchanged, so a move to another series or region leaves it needing a trade-in.
  • What agreement are you on? Savings plans are available on Enterprise Agreement, Microsoft Customer Agreement and Microsoft Partner Agreement subscriptions. Reservations are also available on pay-as-you-go subscriptions and through CSP partners (Buy an Azure reservation).

Where Atlas AVD helps

Everything above works with Azure's own tools. Atlas AVD helps with the parts that come before a purchase, getting scaling right and seeing the baseline, and then shows whether your commitments are covering your compute. Here's exactly what it does, and what it leaves to you.

It doesn't buy commitments. Atlas AVD doesn't buy, exchange or manage reservations or savings plans. You buy them in the Azure portal, under your own Microsoft agreement.

Scaling first, with an explicit floor. In a host pool's Autoscale Configuration, the Session hosts running 24/7 setting is the floor: the minimum number of hosts that run regardless of demand. Schedules raise the Min. Hosts for the working day, for example to absorb the morning login storm. Set the 24/7 floor to the number of hosts you've committed to, and your commitment and your scaling agree. Before you commit, the Cost Intelligence recommendations, such as Drain idle hosts and Auto-scaling could reduce running hosts, take out the waste you'd otherwise lock in.

Reservation and savings plan advice, sized for scaling. On the Cost Intelligence page's Savings tab, the Reservations & Savings Plans card shows Azure's own purchase recommendations for your subscription: the VM size or savings plan, the term, the region, the quantity and the estimated monthly saving. Atlas then sizes the reservation recommendations down by the hours its own drain and autoscale recommendations would remove, and marks those rows net of drain, so you don't reserve capacity that's about to be deallocated. Savings plan recommendations are shown as Azure calculates them. The card is part of Cost Intelligence on the Professional plan and above.

See the baseline in your cost history. On the Cost Burn tab, the Cost History chart has an Hour view and Cost by Host Pool breaks spend down per pool. The overnight and weekend floor of a pool's VM cost is its baseline, in money rather than host counts. These figures are estimates: Atlas prices each pool's running VMs from the Azure Retail Prices API every 30 minutes, at pay-as-you-go rates. That's what makes them useful for finding the baseline, and it's also why they won't show your commitment discounts. For billed totals, use Azure Cost Management. Cost Burn is part of Cost Tracking.

Check coverage after you buy. The Reservation / Savings Plan Coverage dashboard widget reads your month-to-date amortized VM cost from Azure Cost Management and shows how much of it is on a commitment and how much is on-demand. Its estimate of additional savings uses an assumed discount, not your price sheet, so treat it as a prompt to look, not a quote.

What Atlas doesn't do: it doesn't chart the number of running hosts hour by hour, and it doesn't report the utilization of reservations and savings plans you already own. Check utilization in the Azure portal's Reservations and Savings plans pages each month.

To model what scaling alone does before you commit, try the AVD Cost Calculator. For the wider cost picture, see AVD cost optimization and Cut Idle AVD Compute: Our Cost Model Shows Up to 60%. And if your hosts still run all night, start with scaling: it's one of the top 10 AVD mistakes.


FAQ

Should I use a Reserved Instance or a savings plan for Azure Virtual Desktop?

Use a reservation for session hosts that run every hour of the week and won't change size or region during the term. Use a savings plan for a baseline that spans several VM sizes or regions, or when you expect the pool to change. Leave hosts that only run during working hours on pay-as-you-go.

Can I use Reserved Instances with AVD autoscaling?

Yes, but only commit to the hosts autoscale never turns off. A reservation bills every hour of its term whether a matching VM is running or not, so a reservation sized to the daytime peak pays for hosts that autoscale has deallocated.

How much do Azure Reserved Instances save?

Microsoft quotes up to 72% for reservations and up to 65% for savings plans compared to pay-as-you-go, as of October 2026. Those maximums are for three-year terms on large M-series VMs. The discount on typical AVD sizes is lower and depends on size, region and term, so check your price sheet before you buy.

Do reservations or savings plans cover the Windows license on AVD session hosts?

No. Both discount compute only. Windows 10 and 11 Enterprise and Enterprise multi-session hosts don't carry a separate Windows license charge when your users are licensed for AVD, so compute is most of their VM cost. For Windows Server session hosts, use Azure Hybrid Benefit for the license if you're eligible.

Can I cancel an Azure savings plan?

No. Savings plans can't be canceled, refunded or exchanged. Reservations can be returned for a prorated refund, up to USD 50,000 of canceled commitment in a rolling 12-month window, and can be traded in for a savings plan.

Can I still exchange Azure VM reservations?

As of October 2026, yes, under a grace period that runs until further notice. Reservations for VMs and other services covered by savings plans that are bought from 1 February 2027 won't be exchangeable. Reservations bought before that date keep one final exchange.

Do reservations work across subscriptions?

Yes. A reservation can be scoped to a resource group, a subscription, a management group, or shared across eligible subscriptions in your billing account or profile. You can change the scope after purchase without changing the term.

Should MSPs buy commitments for customer AVD estates?

Reservations and savings plans apply within the billing scope they're bought in, so they're usually bought in, or for, each customer's own billing account and sized to that customer's baseline. CSP partners can buy reservations on a customer's behalf in Partner Center. Either way, review utilization with the customer every quarter.

Microsoft product details in this article are taken from Microsoft Learn and Azure's pricing pages as of October 2026: What are Azure Reservations?, What are savings plans?, Decide between a savings plan and a reservation, How a savings plan discount is applied, Self-service exchanges and refunds for Azure Reservations, Determine what reservation to purchase and Understand and estimate costs for Azure Virtual Desktop. Commitment terms and prices change, so check those pages before you buy.