If you're already running Azure Virtual Desktop, the platform decision is behind you. What's in front of you is the monthly bill, and for most organisations it's higher than it needs to be. Not because AVD is expensive by nature, but because host pools are usually configured once, at launch, and rarely revisited.

In short: The five quickest wins on an Azure Virtual Desktop bill are turning on autoscaling scaling plans, right-sizing VM SKUs to real utilisation, using pooled multi-session hosts where the workload allows, matching FSLogix storage tiers to actual demand, and committing Reserved Instances or a Savings Plan against your steady-state baseline. They're configuration changes, not re-architecture, and they stack.

The five changes below are the ones we come back to on almost every AVD cost review. None of them require re-architecting anything. They're configuration and habit changes, and they compound.

1. Turn on autoscaling for your host pools

The single most common cause of AVD overspend is session hosts running around the clock when nobody is using them. A host pool sized for Monday morning peak doesn't need to stay at that size overnight, at weekends, or through lunch. AVD's autoscale feature (via scaling plans) can ramp hosts down, and for many pools right down to zero, outside working hours, then bring them back up ahead of your first login wave each morning.

This is usually the biggest single lever available, and it's also the cheapest to pull: it's a configuration change, not new infrastructure. If you've never set a scaling plan up, or set one up years ago and haven't touched it since usage patterns shifted, this is where to start.

2. Right-size your VM SKUs to actual usage

Host pools are very often provisioned "just in case", sized for a worst-case concurrent load that rarely, if ever, materialises, then left alone because nobody wants to be the one who made it too small. Pull the real CPU and memory utilisation data for your session hosts over a few working weeks. In the cost reviews we run, it's common to find hosts sitting well under 50% utilisation on both, even at peak.

Where there's consistent headroom, step down to a smaller SKU rather than the one you happened to pick at deployment. This is a lever worth revisiting periodically too, usage patterns and the applications running on the hosts both change over time, and a size that was right a year ago may not be right now.

Five icons representing the five AVD cost levers: autoscaling, right-sizing, multi-session pooling, storage tiering, and reserved capacity
Five levers, and they stack: autoscale, right-size, pool, tier storage, reserve.

3. Use pooled multi-session hosts wherever the workload allows

For standard office workloads, email, Teams, browser, Office apps, pooled multi-session Windows hosts serve many users from a single VM far more cost-efficiently than giving each user their own dedicated machine. If you're still running one VM per user for general knowledge-worker desktops, that's licence and compute cost that a multi-session pool would absorb across dozens of users instead.

"Dedicated, single-session hosts have a place. The mistake is defaulting to them for everyone, when most users would never notice the difference."

Reserve single-session, dedicated hosts for the workloads that genuinely need them, specialist or licensed software with strict per-machine or hardware-binding requirements, workloads needing GPU passthrough, or the handful of power users who need guaranteed, isolated resources. For everyone else, multi-session is the more economical default.

4. Match your storage tier to how FSLogix profiles are actually used

FSLogix profile containers on Azure Files are frequently left on a premium storage tier by default, because that's what the reference deployment used, and nobody's revisited it since. Premium performance matters for some environments, but plenty of profile workloads run perfectly well on a standard tier, particularly where user counts are moderate and IOPS demand isn't spiky.

Review what your profile containers actually need in terms of throughput and latency, and match the storage tier and Azure Files redundancy option to that reality rather than to habit. It's a small line item next to compute, but it's also one of the easiest to get right with almost no risk.

5. Commit to Reserved Instances or a Savings Plan for your baseline capacity

Once autoscaling and right-sizing are in place, you'll have a clearer picture of your baseline: the core number of hosts that run the same predictable hours every working week. Paying pay-as-you-go rates for that baseline leaves savings on the table. A one- or three-year Reserved Instance or Azure Savings Plan against that steady-state capacity, topped up with pay-as-you-go for the burst that autoscaling handles at peak, is the standard way to close that gap.

This only works well once the first two levers are done, committing to a reservation before you've right-sized locks in the wrong number. Sequence it last, after your baseline has settled.

Bringing it together

Each of these delivers a meaningful reduction on its own, and autoscaling is usually where businesses see the biggest single win first. But they're not alternatives to each other, they stack. A right-sized, autoscaled, mostly multi-session host pool with sensible storage tiering and a reservation against its baseline looks like a genuinely different cost profile to the same pool left as originally deployed.

If you'd like a second pair of eyes on your own AVD environment, cost optimisation is one of the things our end-user computing service does as a matter of course, not a one-off exercise. Our free assessment will tell you exactly which of these five levers is worth pulling first for your environment.

RM
Ryan Mangan

Founder & CTO of Systech IT Solutions, Microsoft MVP and Chartered Fellow of the BCS, and author of the bestselling Mastering Azure Virtual Desktop. Ryan has spent nearly two decades helping organisations adopt Azure, Microsoft 365 and modern workspace technology pragmatically.