AVD Autoscale and Automated Host Pools: A Cost Model

Every Azure Virtual Desktop bill I review has the same shape: compute is the largest line by a wide margin, and a surprising share of it was running at 2 a.m. for nobody. Autoscale is the feature that fixes this, and the arrival of automated host pools and dynamic autoscaling that I covered in the June 2026 Azure Virtual Desktop update roundup made it better. But the question I get from US IT teams is not “does autoscale save money”; it is “how much, for us, and what do we have to change”. This guide answers that with a cost model you can copy into a spreadsheet: the cost components, how the two autoscale methods differ, a worked example with formulas, the levers ranked by impact, the guardrails that stop savings from turning into help desk tickets, and how to measure the result in Azure Cost Management. Every feature claim is checked against the Microsoft Learn pages linked inline and listed under Sources. Unit prices are left as placeholders on purpose: they vary by region and agreement, and the right numbers for you are the ones you pull from the Azure Pricing Calculator after signing in.

Where Azure Virtual Desktop money goes

Microsoft’s Azure Virtual Desktop pricing page describes the bill as two parts: user access rights, and Azure infrastructure made up of virtual machines, storage for OS images, data disks and user profiles, and networking, billed pay-as-you-go or through reservations. In practice I break it into seven lines, because they behave differently when autoscale is switched on.

Two licensing points matter for the model. First, for Windows 11 Enterprise multi-session session hosts the eligible licences are Microsoft 365 E3, E5, A3, A5, F3, Business Premium and Student Use Benefit, Windows Enterprise E3 and E5, Windows Education A3 and A5, and Windows VDA per user; the licensing page is explicit that you must provide one for each user who accesses the service, and the multi-session FAQ notes that this per-user Windows licensing replaces RDS Client Access Licenses. Second, Windows Server session hosts need an RDS CAL with Software Assurance or an RDS User Subscription License, and that is where Azure Hybrid Benefit for Windows Server comes in later. Neither licence line moves when you autoscale, which is why the headline percentage on compute is always larger than the percentage on the total bill.

Power management autoscale versus dynamic autoscale

What each does

The autoscale glossary defines the two scaling methods. Power management autoscaling “powers on and off session hosts to adjust to the available capacity in a host pool”, and is the method for host pools with standard management. Dynamic autoscaling “powers on and off session hosts and creates and deletes session hosts to adjust to the available capacity in a host pool”, and can only be used for pooled host pools with a session host configuration. Both run the same schedule: ramp-up, peak, ramp-down and off-peak phases, each with a load-balancing algorithm, a minimum percentage of hosts and a capacity threshold. Both use identical consolidation logic during ramp-down; Microsoft’s scenario walkthrough says “the only difference is that Power Management deallocates session hosts while Dynamic Autoscaling can delete session hosts.”

Two availability notes from the same page. Power management autoscaling is available in Azure and Azure Government in every region where you can create host pools. Dynamic autoscaling is only available in Azure, is not supported in Azure Government, and is still labelled preview on the Learn pages as I write this.

Prerequisites

All of this comes from the create and assign a scaling plan guide, which also warns that assigning the roles below subscription scope “prevents autoscale from working properly”. The management approach itself is decided once: the host pool management approaches page cautions that it “is set when you create a host pool and can’t be changed later. If you create a host pool without a session host configuration, you can’t add one afterwards.”

When each applies

If you run a standard host pool and build hosts with your own Terraform, Bicep or pipelines plus a registration token, power management is your only option, and it is generally available. If you run a session host configuration host pool, dynamic autoscaling is the natural fit, and the autoscale FAQ explains how to shape it: set Minimum host pool size equal to Maximum host pool size and it behaves like power management; set Minimum percentage of active hosts (%) to 100 and it only creates and deletes. Hosts that dynamic autoscaling creates use “the latest valid/stable image version defined in the default session host configuration”, so your image pipeline feeds autoscale directly. Personal host pools get a different schedule: deallocate, hibernate or do nothing after a session is disconnected or signed out for 0 to 360 minutes, with Start VM on Connect for the morning. FSLogix and App Attach do not support hibernate, so personal pools using either should deallocate instead.

The cost model

Variables

The model below is the one I hand to clients. It is deliberately simple: hours are the term autoscale changes, so the model isolates hours.

Formulas

P          = U × C                                           peak concurrent sessions
H          = ceil( P / (S × T) )                             hosts running at peak
Hours_on   = N × 730                                         always-on host-hours per month
Hours_as   = D × (R × h_up + H × h_peak + R × h_down + F × h_off) + W × F × 24
Compute    = Hours × p_vm
Disks      = DiskMonths × p_disk                             persistent OS disks
Profiles   = GiB_prov × p_gib + IOPS_prov × p_iops + MiBps_prov × p_tp   (Azure Files provisioned v2)
Egress_GB  = P × h_active × D × kbps × 0.45 / 1000           0.45 MB per kbps-hour
Egress     = max(Egress_GB - 100, 0) × p_egress
Licences   = U × your per-user licence (outside the Azure bill for internal users)

The H formula is Microsoft’s own. The autoscale FAQ states “Required Hosts = Total Sessions / (Max Session Limit x Capacity Threshold %)”, rounded up. It is written for consolidation during ramp-down, but the same arithmetic governs how many hosts autoscale keeps on at steady state, because it turns hosts on whenever used capacity exceeds the threshold.

Worked example

Plugging in the example values:

The 30 GiB per user comes from the minimum profile storage column of the sizing guidelines; the 150 kbps is the midpoint of Microsoft’s RDP bandwidth estimates for active Word and Excel work in default mode, which range from 100 to 200 kbps at 1080p. Video, PowerPoint and image-heavy browsing are measured in megabits per second on that page, so if your users do those things, model them separately.

How autoscale changes the hours term

Autoscale moved the compute line from 23,360 to 8,011 host-hours, 34% of the original, a reduction of roughly two thirds, and it did so with no discount, no resizing and no change to anything users see during the day. Everything else in the model stayed the same. That is the honest headline: autoscale is a compute lever, and if compute is 60% of your bill, a two-thirds compute saving is a 40% total saving.

Two sensitivities are worth knowing before you tune. Each extra peak hour across 30 hosts adds 30 × 21 = 630 host-hours a month, so a schedule that starts ramp-up at 6:00 for a team that logs on at 8:30 is paying for 1,260 host-hours of air. Each extra host on the overnight floor adds 10 × 21 + 24 × 9.4, about 436 host-hours a month; moving the floor from two hosts to four costs 871 host-hours, 11% of the entire autoscaled bill. The floor is where good intentions go to die, so size it from Insights data on genuine after-hours sessions, not from fear.

Dynamic autoscaling does not change the hours term further; a running host costs the same whether it was powered on or created. What it changes is the disk term and the stopped-VM footprint. With power management, 32 persistent OS disks bill all month; with dynamic autoscaling only the minimum pool size exists all month, and with ephemeral OS disks the storage charge for created hosts disappears entirely.

Levers ranked by impact

This is my ranking for a typical US knowledge-worker pool. Your order may differ if you already have one of these in place.

1. Schedule hours and the floor. Shown above. Start ramp-up when the first real logons appear, start ramp-down when the last real logoffs happen, and set the off-peak minimum percentage of hosts to 0% if your after-hours sessions are genuinely zero. Nothing else comes close.
2. Density assumptions: C and S. Most environments I inherit assume 100% concurrency and a cautious session limit. Measure C from Insights session counts over a month. For S, the sizing guidelines give maximum users per vCPU of 6 for light, 4 for medium, 2 for heavy and 1 for power workloads, recommend 8 vCPU and 16 GB as the minimum multi-session host, and say to keep multi-session hosts between 4 and 24 vCPU because “user experience is better with two 16-core VMs instead of one 32-core VM.” They also note that many smaller hosts leave more hosts with no users to switch off, which is exactly what autoscale needs.
3. Right-size the VM family. The same page says CPU scaling is not linear (a factor of 1.5 to 1.9 per doubling) and that moving from 8 GB to 16 GB of memory “can more than double the number of users you can support” when memory is the constraint. Use the Insights host performance tab to see which resource saturates first before you change size. Pick v5 or v6 D-series sizes with local storage so ephemeral OS disks remain an option.
4. Commitment discounts on the baseline only. Azure Reservations offer up to 72% off pay-as-you-go for one- or three-year terms, are applied hourly, and cover only the VM compute meter: “It doesn’t cover additional software, Windows, networking, or storage charges.” Because unused reservation hours are lost, a host that runs h hours a month only breaks even when h ÷ 730 > 1 − discount. In the example, the two floor hosts run 730 hours and are obvious reservation candidates; the 30 peak hosts run about 14 hours on 21 weekdays, 294 hours or 40% of the month, which only pays off with a discount above 60%. Check the actual percentage in the Pricing Calculator for your size and term rather than assuming. Instance size flexibility lets a reservation float across sizes in the same group, which protects you if you later resize. For the variable layer, an Azure savings plan for compute is an hourly dollar commitment that applies across sizes, regions and compute services; it too excludes software, networking and storage, and purchases cannot be cancelled or refunded. Microsoft’s own sequence is right-size first, exchange or trade in underused reservations, then buy new reservations for stable usage, then add a savings plan. For Windows Server session hosts, Azure Hybrid Benefit removes the Windows Server software charge if you have core licences with Software Assurance, with a minimum of 8 core licences per VM. Windows 11 multi-session hosts carry their Windows rights through the user’s licence instead.
5. Ephemeral OS disks. The ephemeral OS disks page is clear that the stop-deallocated state and stop/start are “Not Supported”, so they do not combine with a plan that deallocates hosts. They do combine with dynamic autoscaling’s create-and-delete behaviour, and they suit AVD because the host is stateless once profiles live in FSLogix. Constraints: the image must fit the VM’s cache, temp or NVMe disk (up to 2,040 GiB), and VM Image Capture, disk snapshots, Azure Disk Encryption, Azure Backup, Azure Site Recovery and OS disk swaps are unsupported. If you pick a Standard SSD or Premium SSD base disk for the higher SLA, you pay that base disk charge.
6. Deallocation policy. A VM that is Stopped (allocated) still bills compute; only Stopped (deallocated) stops the meter. Autoscale deallocates, which is what you want. For personal pools, set the disconnect and sign-out actions to deallocate (not hibernate, if FSLogix is in play) and enable Start VM on Connect so users can bring their own desktop back.
7. FSLogix storage tier. The FSLogix storage comparison recommends Azure Files for most customers, standard file shares for light workloads under 200 users and premium for everything else, and says Azure NetApp Files performance “is a function of tier times capacity”, so provisioning more capacity at a lower tier can be the cheaper way to hit an IOPS target. Azure Files billing guidance says to use the provisioned v2 model for all new deployments and that Azure Files reservations can discount storage by up to 36%.
8. Region choice. VM, disk and egress prices differ by region, and egress rates differ by continent. The scaling plan’s configuration must live in the same region as the host pool configuration, but session hosts can be in any region, so you can keep metadata where it is and place hosts where the price and latency balance works. Do not chase a cheaper region at the expense of round-trip time; the sizing guidance names latency, loss and jitter as direct user experience factors.

Guardrails

Ramp-up and ramp-down timing

Autoscale will not turn off hosts during ramp-up, so a ramp-up that starts too early simply burns hours. Start it 30 to 60 minutes before the first wave of logons with a higher minimum percentage of hosts, which the dynamic autoscaling guide recommends carrying into peak. In ramp-down, forced sign-out only happens in that phase and only after the wait time you configure; the FAQ gives the failure mode exactly: “if the ramp-down phase is 15 minutes long, and the wait time before signing out users and shutting down VMs is 20 minutes long, the schedule shifts to the off-peak phase and the user sessions won’t be forced to sign out.” Make the ramp-down phase longer than the wait time. If your schedule only covers Monday to Friday, the Friday off-peak settings carry through the weekend until Monday’s ramp-up, which is what you want for the floor.

Drain mode and exclusion tags

Autoscale overwrites drain mode: “autoscale still turns VMs in drain mode on or off, no matter who put it in drain mode.” For maintenance, tag the host with the scaling plan’s exclusion tag (Microsoft’s example is excludeFromScaling) and autoscale will not start, stop or change drain mode on it. Two cautions from the Learn page: tagged hosts still count toward the minimum percentage of hosts, and if you tag every host and power them off, users see “No resources available” because autoscale has nothing left to start.

User experience during scale-in

Autoscale only turns off hosts with no sessions unless force sign-out is enabled in ramp-down, and when it does select a host it puts it in drain mode first, sends the notification message you configured, waits, then signs out and deallocates. Because the host is in drain mode, a user who reconnects lands on a surviving host rather than the one about to go. Use breadth-first load balancing in ramp-up and peak for performance and depth-first in ramp-down and off-peak so sessions consolidate onto fewer hosts, which is the pattern the FAQ recommends. Pair this with the Group Policy or Intune setting Set time limit for disconnected sessions (15 to 30 minutes in Microsoft’s example) so disconnected sessions do not hold hosts open all night.

Capacity for login storms

Start VM on Connect is not a login storm tool; for pooled pools it starts at most one VM every five minutes and users who arrive in that window get “No resources available”. Your defence is the ramp-up phase with a sensible minimum percentage of hosts. If you are in a region where capacity is tight, an on-demand capacity reservation guarantees the VM size and quantity you name, with no term commitment, but you pay the VM rate for reserved capacity whether or not a VM is using it, and both used and unused reserved capacity are eligible for reservation and savings plan discounts. Reserve the peak tranche, not the whole pool, and only where deployment failures have actually bitten you.

Measuring

Azure Cost Management views

Cost analysis smart views give you KPIs, anomaly insights and a drill-down from subscription to resource group to resource to meter; the Reservations view shows amortized utilization over the last 30 days. Create a budget on the AVD resource group with alerts, enable the anomaly alert on the subscription, and check weekly; Microsoft suggests daily for the first week or two after any change, which is exactly when a new scaling plan goes live.

Tags

Group costs by host pool with tags on the session host resource group and the host pool. On Enterprise Agreement, Microsoft Customer Agreement and Microsoft Partner Agreement accounts, turn on tag inheritance so resource group and subscription tags are applied to child usage records within about 24 hours; after that you can build budgets filtered on the inherited tag. Hosts that dynamic autoscaling creates inherit the VM tags from the session host configuration, so set the tags there rather than on individual VMs.

Insights and the autoscale workbook

Azure Virtual Desktop Insights needs a dedicated Log Analytics workspace, diagnostic settings on the host pool and workspace, and the Azure Monitor Agent with a data collection rule on the session hosts; the configuration workbook at aka.ms/avdi sets all of it up. Add the Autoscale logs for pooled host pools category to the host pool diagnostic setting and the Autoscale tab appears in Insights, showing power state changes over time. The underlying table is WVDAutoscaleEvaluationPooled, which records SessionOccupancyPercent, ActiveSessionHostCount, the schedule phase and ScalingReasonMessage for every evaluation. This query tells you whether your capacity threshold and floor are right:

WVDAutoscaleEvaluationPooled
| where ResultType == "Succeeded"
| summarize max(SessionOccupancyPercent), max(SessionCount), max(ActiveSessionHostsPercent), max(ActiveSessionHostCount)
    by _ResourceId, bin(TimeGenerated, 1d), ConfigScheduleName, ConfigSchedulePhase
| order by _ResourceId asc, TimeGenerated asc, ConfigScheduleName, ConfigSchedulePhase asc

Failed evaluations join to WVDErrors on CorrelationId. Personal pools cannot use the Insights tab; send their autoscale logs to a storage account or Event Hub instead.

What to review monthly

• Compute host-hours per host pool against the model, and the hours by schedule phase from WVDAutoscaleEvaluationPooled.
• Peak SessionOccupancyPercent per phase. If it never approaches the threshold, raise the threshold or lower the minimum percentage of hosts.
• Off-peak ActiveSessionHostCount. If it is above the floor, find the disconnected sessions holding hosts open.
• Reservation and savings plan utilization in Cost analysis; anything under 100% on a reservation is money you prepaid and did not use.
• Disk-months versus host count; with dynamic autoscaling they should diverge.
• Log Analytics ingestion in GB, which creeps as you add counters.
• Image version in the session host configuration, so autoscale is not creating hosts from an old build.

What to do about it

1. Export last month’s AVD costs by meter from Cost analysis and fill in the seven cost lines; note the compute percentage.
2. Pull 30 days of session counts from Insights and calculate your real concurrency ratio and your real after-hours session count.
3. Confirm the host pool management approach. Standard means power management autoscaling; session host configuration means dynamic autoscaling is available.
4. Set a custom MaxSessionLimit from the sizing guidelines for your workload type and host size; the default blocks autoscale.
5. Assign Desktop Virtualization Power On Off Contributor (plus Desktop Virtualization Virtual Machine Contributor for dynamic) at subscription scope.
6. Build the schedule from the data: ramp-up 30 to 60 minutes before first logons, ramp-down longer than the force sign-out wait, off-peak minimum 0% if after-hours sessions are zero.
7. Deploy Set time limit for disconnected sessions through Intune or Group Policy so the pool can actually reach the floor.
8. Define the exclusion tag in the scaling plan and write it into your maintenance runbook.
9. Enable Insights, add the autoscale log category and run the occupancy query after two weeks; adjust threshold and floor once.
10. Only then buy reservations for hosts above the break-even utilization, a savings plan for the rest, Azure Hybrid Benefit for any Windows Server hosts, and Azure Files reservations for profile storage you will keep.
11. If the pool uses a session host configuration, test ephemeral OS disks on a new image version and let dynamic autoscaling create the hosts.
12. Put a budget and an anomaly alert on the resource group, and tag the session host configuration so the next created host is already allocated to a cost centre.

Frequently asked questions

How much does Azure Virtual Desktop autoscale save? It depends on how many hours your hosts currently run for nobody. Autoscale itself has no charge; the FAQ answers “Will I be charged extra for using autoscale?” with “No.” In the worked example, a 32-host pool running 24 hours a day consumes 23,360 host-hours a month and the same pool on a weekday schedule with a two-host floor consumes about 8,000, a reduction of roughly two thirds on the compute line. Profile storage, licensing and egress do not change, so the saving on the total bill is smaller than the saving on compute.

What is the difference between power management autoscaling and dynamic autoscaling in AVD? Power management autoscaling powers hosts on and off (deallocates them) and is the method for host pools with standard management. Dynamic autoscaling also creates and deletes hosts and only works with pooled host pools that have a session host configuration. Both use the same phases, capacity threshold and consolidation logic; the difference is the final action, deallocate versus delete, which is what changes the OS disk cost.

Should I buy Azure reservations for AVD session hosts that autoscale? Only for hosts that run most of the month. A reservation is applied hourly and unused hours are lost, so a host that runs h hours a month breaks even when h ÷ 730 is greater than one minus the discount. Reserve the overnight floor and hosts that run all business day, consider a savings plan for the variable layer, and remember that neither covers Windows software, storage or networking.

Can I use ephemeral OS disks with AVD autoscale? Not with a plan that deallocates. The Learn page marks stop-deallocate and stop/start as not supported for ephemeral OS disks. They fit dynamic autoscaling, which creates and deletes hosts from the session host configuration, and they remove the OS disk storage charge for stateless hosts. You need a VM size with local storage and you give up Azure Backup, Site Recovery and disk snapshots on those hosts.

Why does autoscale keep session hosts running after hours when nobody is working? Because disconnected sessions count. Autoscale assumes a disconnected user may reconnect and keeps Required Hosts = Total Sessions ÷ (Max Session Limit × Capacity Threshold) running for them. To reach zero hosts you need zero sessions, including disconnected ones: set Set time limit for disconnected sessions so they sign out before ramp-down ends, and set the off-peak minimum percentage of hosts to 0%.

If you are still deciding whether AVD is the right platform for a given user group before you tune it, the Windows 365 versus Azure Virtual Desktop comparison covers the fixed-price-per-user case, and the Azure Virtual Desktop what’s new series tracks the autoscale and session host configuration changes as Microsoft ships them.

Need a second pair of hands? Big Hat Group provides Azure Virtual Desktop architecture and cost reviews for organizations in the United States and Canada, from a two-week autoscale health check to a full host pool redesign. Book a discovery call to talk through your environment.

Sources

• Autoscale scaling plans and example scenarios in Azure Virtual Desktop
• Create and assign an autoscale scaling plan for Azure Virtual Desktop
• Azure Virtual Desktop autoscale glossary
• Azure Virtual Desktop autoscale FAQ
• Host pool management approaches
• Licensing Azure Virtual Desktop
• Windows Enterprise multi-session FAQ
• Session host virtual machine sizing guidelines
• Remote Desktop Protocol bandwidth requirements
• Storage options for FSLogix profile containers in Azure Virtual Desktop
• Understand Azure Files billing
• Ephemeral OS disks for Azure VMs
• States and billing status of Azure Virtual Machines
• What are Azure Reservations?
• Virtual machine size flexibility with Reserved VM Instances
• What are Azure savings plans?
• Decide between a savings plan and a reservation
• Explore Azure Hybrid Benefit for Windows VMs
• On-demand capacity reservation in Azure
• Drain session hosts for maintenance in Azure Virtual Desktop
• Configure Start VM on Connect for Azure Virtual Desktop
• Enable Insights to monitor Azure Virtual Desktop
• Monitor Autoscale operations with Insights in Azure Virtual Desktop
• Set up diagnostics for Autoscale in Azure Virtual Desktop
• Quickstart: Start using Cost analysis
• Group and allocate costs using tag inheritance
• Azure Virtual Desktop pricing
• Azure Pricing Calculator
• Windows Virtual Machines pricing
• Managed Disks pricing
• Azure Files pricing
• Bandwidth pricing