# How much does Azure Virtual Desktop autoscaling actually save?

_Updated 2026-09-10. Canonical page: https://rugged.sh/learn/avd-autoscaling-savings/_

**Question:** How much does Azure Virtual Desktop autoscaling actually save?

**Short answer:** Autoscaling saves the compute hours you do not run. Azure bills a session host VM for every hour it is allocated to a host, so the saving comes entirely from reaching the Deallocated power state: a host that runs 260 hours a month instead of 730 stops incurring about 64 percent of its compute charge. Two things do not stop: managed disks and networking keep billing while the VM is deallocated, and per-user Windows licensing is unaffected. A VM shut down from inside Windows lands in Stopped (allocated), which Azure still bills in full.

## The only state that saves money is Deallocated

Azure Virtual Desktop session hosts are ordinary Azure VMs, and Azure bills them by power state, not by whether anyone is logged in. Microsoft's own states-and-billing table is unambiguous about which states cost money.

The distinction that catches people is Stopped versus Deallocated. If a user or a script shuts Windows down from inside the guest, the VM is powered off but still holds its lease on the underlying hardware. Azure calls that Stopped, or Stopped (allocated), and bills it exactly like a running machine. Only a deallocate operation through the Azure control plane releases the lease and stops the compute charge.

_Session host power states and whether Azure bills compute (Microsoft, states and billing)_

| Power state | What it means | Compute billed |
| --- | --- | --- |
| Running | Fully up, the normal working state | Yes |
| Stopping | Transitional, running to stopped | Yes |
| Stopped (allocated) | Powered off but still allocated on a host, typically a guest OS shutdown | Yes |
| Deallocating | Transitional, running to deallocated | No |
| Deallocated | The lease on the underlying hardware is released | No |

> **The single most expensive mistake in a desktop estate.** A nightly guest-OS shutdown feels like it is saving money and saves nothing at all. Check the power state, not the login screen. Anything that reports Stopped rather than Deallocated is still on the bill.

## The arithmetic, without a price list

Compute savings are just the ratio of hours. A month is about 730 hours. An office-hours host pool that runs 12 hours a day on weekdays is roughly 260 hours, which is around 36 percent of the month, so about 64 percent of the compute charge goes away. Cut it to 10 hours a day and you are near 70 percent.

That is the ceiling, not the result. Real pools do not scale to zero: you keep a minimum number of hosts warm so the first user of the morning is not waiting on a boot, ramp-up starts before the workday does, and a host with an active session should not be drained mid-task. Every one of those gives back part of the ceiling, and how much depends entirely on when that client's people actually work. Do not quote a client a percentage before you have measured their real connection pattern for a full month, including the month-end week and whoever logs in from home on a Sunday.

- **Pooled multi-session:** Benefits most. Sessions concentrate onto fewer hosts as demand falls, and the emptied hosts deallocate.
- **Personal desktops:** Benefit on a schedule, not on load. Each desktop belongs to one user, so the lever is start and stop times, not consolidation.
- **Always-on workloads:** Shift workers, overseas staff and after-hours access shrink the window. Measure the real connection times before promising a number.

## What keeps costing money while a host is off

Microsoft footnotes the billing table with the part that surprises people: some Azure resources, including disks and networking, continue to incur charges while the VM is deallocated. Budgeting a deallocated host at zero is wrong.

- **Managed disks:** The OS disk is provisioned storage. It bills whether or not the VM is running, and a premium SSD OS disk on a deallocated host is often the largest residual line.
- **Static public IPs and other networking:** Reserved addresses and gateways keep billing. Session hosts should not have public IPs anyway.
- **Profile storage:** FSLogix profile containers on Azure Files or Azure NetApp Files are sized for the user population, not for how many hosts are awake.
- **Windows licensing:** AVD entitlement rides on the user's Microsoft 365 or Windows subscription. Turning hosts off does not reduce it.

## Schedule-based and load-based, and why you usually want both

A schedule handles the shape of a working day: ramp up before people arrive, ramp down after they leave, run a smaller off-peak footprint overnight. It is predictable and easy to explain to a client on an invoice.

Load-based scaling handles the days the schedule is wrong: month-end, a training session, a snow day when everyone works remotely at once. It watches session density against a capacity threshold and adds or drains hosts to match.

In practice the schedule sets the floor and the ceiling, and the load rule moves within it. A pool driven only by load is slow to respond to a predictable morning rush, because it can only react after users are already queuing.

> **Two constraints that shape the schedule.** Autoscale does not turn session hosts off during the ramp-up phase, and it only forces users to sign out during ramp-down, and only if you enable that setting. Separately, when we validated scaling plan templates against real ARM on 2026-07-01, a schedule missing a ramp-up capacity threshold was rejected outright: both rampUpCapacityThresholdPct and rampDownCapacityThresholdPct must be present and between 1 and 100.

## Draining users is the hard part, not stopping VMs

Deallocating an empty host is trivial. Deciding that a host should become empty is the hard part. The sequence that avoids interrupting someone mid-task is: stop new sessions landing on the host, wait for existing sessions to end or send a notification with a grace period, handle disconnected sessions on their own timer, and only then deallocate.

Disconnected sessions deserve their own policy. A user who closed their laptop at 5pm still holds a session that will reconnect tomorrow. Signing them out reclaims the host, but it also discards unsaved work if the application does not handle it. A long disconnect timeout during business hours with an aggressive one overnight is a reasonable starting point, and it is worth agreeing it with the client rather than deciding it for them.

## How rugged.sh handles this

rugged.sh runs schedule and load-based autoscale profiles per customer tenant and deallocates rather than stops, which is the distinction this whole page is about. Schedule-based scaling works with nothing else connected; the load-based half needs a Log Analytics workspace on that tenant, because it scales on measured session data rather than guesswork. It shows the projected saving for that tenant next to the flat per-tenant fee. Be clear about what that figure is: a model, derived from the tenant's managed resources and a default savings factor, not a measurement of hours actually reclaimed. The quarterly business review states the same thing on its face, and pairs it with the tenant's billed Azure spend where Cost Management can supply one. Whether the saving covers the fee on a given client is something to check against that client's own bill, not a promise made here: the free tier covers one tenant, so run it on a real one first.

## Questions and answers

**Does shutting down a VM from inside Windows stop the Azure bill?**

No. A guest OS shutdown leaves the VM in the Stopped (allocated) state, which Microsoft's states-and-billing table lists as billed. Only a deallocate through the Azure control plane releases the hardware lease and stops the compute charge.

**Do I still pay for anything when an AVD session host is deallocated?**

Yes. Managed disks and networking continue to incur charges while the VM is deallocated, so the OS disk and any reserved addresses stay on the bill. Windows and Microsoft 365 licensing is per user and is unaffected by whether hosts are running.

**Is autoscaling worth it for personal desktops, or only pooled host pools?**

Both, but for different reasons. Pooled host pools save the most because sessions consolidate onto fewer hosts and the emptied ones deallocate. Personal desktops are one user each, so the saving comes from schedules: starting them before the workday and deallocating them after it.

**How much can autoscaling realistically save on an AVD estate?**

The ceiling is arithmetic: a 12-hour weekday pattern is roughly 260 of 730 hours, so about 64 percent of the compute charge. What you actually reach is lower, because pools keep a minimum warm capacity, ramp up before the workday, and do not drain hosts with active sessions. There is no general figure for the gap; it depends on when that client's people work, so measure a full month before quoting a number.

## Sources

- Microsoft Learn: States and billing status for Azure Virtual Machines: https://learn.microsoft.com/azure/virtual-machines/states-billing (read 2026-09-10)
- Microsoft Learn: Autoscale scaling plans for Azure Virtual Desktop: https://learn.microsoft.com/azure/virtual-desktop/autoscale-scenarios (read 2026-09-10)

## Related

- Where the money actually goes in an Azure Virtual Desktop estate: https://rugged.sh/learn/avd-cost-optimization/
- Per-user, per-device or per-tenant: how MSP management tools are priced: https://rugged.sh/learn/msp-tooling-pricing-models/
- Windows 365 or Azure Virtual Desktop: which one for which client: https://rugged.sh/learn/windows-365-vs-azure-virtual-desktop/

_Published by rugged.sh, a multi-tenant control plane MSPs use to deploy and scale AVD and Windows 365 and to manage Microsoft 365 configuration across customer tenants. Priced per customer tenant, not per user (Microsoft 365 management: $10/tenant/month; Azure (AVD / Windows 365): $50/tenant/month; Microsoft 365 + Azure: $60/tenant/month), with a free tier for 1 tenant and 5 users. https://rugged.sh/_