# Where the money actually goes in an Azure Virtual Desktop estate

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

**Question:** What drives Azure Virtual Desktop costs, and which levers actually reduce them?

**Short answer:** Session host compute is almost always the largest line in an AVD bill, followed by managed disks, profile storage and, in some designs, networking. The levers that move real money are running fewer host hours through autoscaling, right-sizing the VM SKU to measured session density, matching disk tier to actual IOPS, and committing to reservations or savings plans for the capacity you will genuinely run around the clock.

## The bill, in the order it usually sorts

Before optimizing anything, get the estate's actual cost breakdown by resource type rather than reasoning from a diagram. The ordering below is typical, not universal, and a client with heavy profile storage or a chatty line-of-business app can reorder it.

- **Session host compute:** Hours multiplied by SKU. This is the line autoscaling attacks, and usually the majority of the bill.
- **Managed disks:** Provisioned per host and billed whether or not the host is running. Premium SSD on every host is a common and expensive default.
- **Profile storage:** FSLogix containers on Azure Files or Azure NetApp Files. Sized by user count and retention, not by host count.
- **Networking:** Usually modest for AVD itself, since clients connect outbound to the service. It grows when the design forces traffic through a hub, a firewall, or back on-premises.
- **Monitoring:** Log Analytics ingestion is priced per gigabyte. Verbose diagnostic settings on every host add up quietly.

## Right-sizing beats re-platforming

The instinct is to reach for a cheaper VM family. The bigger win is usually matching users per host to what the hosts actually do. Session density is workload-dependent: a browser-and-Office user is a fraction of the load of a CAD or data-analysis user, and a single mis-sized pool can double a bill.

Measure before changing. Connection counts, session durations and per-host CPU and memory pressure over a full month tell you whether a pool is over-provisioned or whether one department is quietly running something expensive. Guessing at density and then discovering it at 9am on a Monday is how host pools get permanently over-built.

## Disks: the line that keeps billing when everything is off

Because managed disks bill on provisioned capacity regardless of power state, a fleet with aggressive autoscaling can find disks becoming a surprisingly large share of what remains. Standard SSD is adequate for many pooled multi-session hosts whose profiles and data live elsewhere; premium is worth it where boot storms or an application genuinely need the IOPS.

The related lever is host count. Ten smaller hosts carry ten OS disks. Consolidating to fewer, larger hosts reduces both the disk footprint and the per-host operating system overhead, at the cost of a larger blast radius when one host has a problem.

## Reservations and savings plans, applied to the floor only

Reserved instances and savings plans discount capacity you commit to in advance. That is a good trade for the baseline you will run regardless, and a bad one for the peak you only touch at month-end. The safe approach is to reserve the minimum warm capacity that autoscaling never drops below, and leave the elastic portion on pay-as-you-go.

Do the autoscaling work first. Committing to a year of capacity and then reducing the hours you use it is how an optimization project ends up costing money.

> **Order of operations.** Measure, then autoscale, then right-size, then reserve what is left. Reserving first locks in the wrong baseline.

## The levers that only look like levers

Some familiar advice does not move an AVD bill much.

- **Deleting hosts instead of deallocating:** Saves the disk but destroys the host, so it only makes sense with automated rebuild from an image, and reprovisioning has its own cost and risk.
- **Turning off the profile service:** Profile storage is a small fraction of a typical bill and the failure mode is user-visible and immediate.
- **Chasing region pricing:** Moving a workload for a small per-hour delta usually costs more in latency and migration effort than it saves. Microsoft recommends keeping round-trip latency under 150 ms, which constrains region choice anyway.

## Doing this across many clients

For an MSP the difficulty is not any single optimization, it is repeating it across every tenant and proving it happened. rugged.sh reads each customer's Azure cost data in one console, adds measured session usage for tenants with a Log Analytics workspace connected, drives autoscale profiles per tenant, and turns the result into a client-ready quarterly business review. That report leads with billed spend from Azure Cost Management where it can read it, labels the savings figure as modeled, and says which is which on the page, so the client is not handed a projection dressed up as an invoice.

## Questions and answers

**What is usually the biggest cost in an AVD deployment?**

Session host compute, measured as hours multiplied by VM size. That is why autoscaling, which reduces hours, and right-sizing, which reduces the multiplier, are the two largest levers in most estates.

**Should I buy Azure reservations for AVD session hosts?**

Only for the capacity you will run regardless, such as the minimum warm hosts autoscaling never drops below. Reserving the elastic portion of a pool commits you to paying for hours autoscaling is designed to stop.

**Do AVD costs go down if users work from home?**

Not by themselves. AVD costs track session host hours and provisioned storage, not where the client device is. What changes with remote work is the shape of the demand curve, which affects how much autoscaling can safely reclaim.

## 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: Prerequisites for Azure Virtual Desktop (network latency guidance): https://learn.microsoft.com/azure/virtual-desktop/prerequisites (read 2026-09-10)

## Related

- How much does Azure Virtual Desktop autoscaling actually save?: https://rugged.sh/learn/avd-autoscaling-savings/
- What licences does Azure Virtual Desktop actually require?: https://rugged.sh/learn/avd-licensing-requirements/
- Per-user, per-device or per-tenant: how MSP management tools are priced: https://rugged.sh/learn/msp-tooling-pricing-models/

_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/_