Azure Virtual Desktop can be deployed two ways: single-session, where each user gets a dedicated VM, or multisession, where multiple users share a host. The second model costs significantly less to run. Most organisations default to single-session and never revisit the decision.
The single-session cost problem
With single-session AVD, each user requires their own VM. The VM runs continuously, or at least through business hours, regardless of whether the user is active, on leave, or in a meeting. Fifty users means fifty VMs.
A Standard_D4s_v3 (4 vCPU, 16 GB RAM) in UK South costs around £190/month at list price. Fifty of them: £9,500/month, £114,000/year. Even with reserved instance pricing, typically 35-40% cheaper on a 1-year commit, that's around £70,000/year for the VM layer alone before storage, networking, or licences.
What multisession changes
Windows 10 and 11 Enterprise multi-session allows multiple concurrent user sessions on a single host. A light-to-medium user needs 2-4 vCPUs and 4-8 GB RAM, so eight users comfortably share a Standard_D8s_v3 (8 vCPU, 32 GB RAM).
The bigger lever is auto-scale. Nobody should run an AVD pool 24x7: users work business hours, so the pool scales up in the morning and down to zero overnight and at weekends. Running roughly a third of the time, a £380/month host costs closer to £125/month in practice. Across eight users that's around £16/user/month, against £190/user/month for an always-on single-session VM.
Consolidating a 50-VM single-session estate this way collapses the running footprint to a handful of auto-scaling hosts. The saving on the VM layer runs well into five figures a year, before counting the management overhead of maintaining ten hosts instead of fifty.
What makes multisession work: de-pinning users from VMs
Multisession only delivers if a user can land on any host and still get their environment. Two things make that possible, and skipping either is why multisession projects stall:
- FSLogix profile containers. The user's profile lives in a container on shared storage, not on a specific machine. Whichever host they connect to, their profile attaches. Without it, you're back to pinning users to VMs.
- Automated application deployment. Apps are baked into the host image or deployed by pipeline, so every host is identical and any user can be served by any host. No app is tied to a particular machine.
Together they break the link between a user and a specific VM. The cost saving is a consequence of that decoupling, not the other way round.
It's not always either/or
The decision isn't strictly single-session versus multisession. The strongest design often runs both: a multisession pool for the bulk of general productivity users, and a separate single-session or custom pool for the workloads that genuinely need dedicated resource. You get the consolidation saving on the majority that fit multisession without forcing the awkward minority onto a model that doesn't suit them.
When single-session is still the right choice
Some workloads don't suit multisession. Applications that store user state locally and don't handle concurrent sessions well, GPU-intensive workloads where each user needs dedicated graphics resource, and security-sensitive use cases where session isolation is a hard requirement, these are legitimate reasons to keep a single-session or custom pool.
The audit question is whether single-session was chosen for one of these reasons or simply because it was the default. In most estates, the majority of AVD users are running standard productivity workloads that multisession handles without issue.
AVD cost optimisation is one of the areas we review in our standard Azure assessment. If you'd like an independent view of your virtual desktop estate, our free cost assessment includes host pool configuration and sizing.