Sizing WVD host pools: the math that keeps costs sane

WVD host pool sizing and Windows Virtual Desktop cost field notes: users-per-vCPU by workload, load balancing, autoscale, and telemetry over vendor ratios.

Windows Virtual Desktop went GA last September. By February 2020 every Azure-curious EUC lead has a spreadsheet that promises miracles: extreme density, near-zero idle cost, and happy users. Most of those spreadsheets are fiction. This post is how we size WVD host pools so costs stay sane — users-per-vCPU by workload class, breadth versus depth load balancing, autoscale reality, reserved instances, and why telemetry beats vendor ratios.

Workload classes, not one magic number

We refuse single-number density. At minimum three classes:

  • Task: browser LOB, light Office, short sessions — highest density
  • Knowledge: Outlook + Teams + multi-doc Office — medium
  • Power: fat clients, dev tools, local admin exceptions — low density, separate pools

Mixing power users into a task pool to “save money” burns the savings in tickets and overnight reboots. Separate pools are a cost control, not a luxury.

Users-per-vCPU as a starting point only

Published ratios are marketing midpoints. We start from a hypothesis, then measure:

  1. Build a pilot pool with conservative density
  2. Drive synthetic and real concurrent logons
  3. Watch CPU, memory commit, disk latency on profile storage, and user-reported slowness
  4. Tighten density until P95 login and in-session responsiveness miss targets — then back off one step

Outlook search and Teams media in-session change the math more than Word does. If your estate is mail-heavy, believe your mail-heavy pilot.

Breadth vs depth load balancing

Depth fills a host before the next — great for license packing, bad when one noisy user lands on a half-empty host pattern you did not expect. Breadth spreads users — smoother, sometimes more hosts warm. Match the mode to whether you optimize for minimum host count or minimum blast radius. Document the choice; do not leave the portal default unexamined.

Autoscale without lying to finance

Autoscale can drain idle hosts and grow on schedule or metrics. Cold start is not free in user time. Patterns that work:

  • Schedule-based scale-out before known peaks (shift start)
  • Metric-based scale with enough headroom that users do not queue behind provisioning
  • Scale-in only after drain and idle thresholds that survive bathroom breaks

Finance loves “scale to zero overnight.” Helpdesk hates “first logon of the day is four minutes.” Pick an explicit compromise and write it into the SOW.

Reserved instances and commitment

If a baseline of hosts is always on for core staff, RI or savings-plan style commitments (as available to you in early 2020 Azure commerce) beat pure pay-as-you-go. Burst capacity stays on-demand. Model two lines: steady baseline and elastic peak. One blended number hides bad design.

Profile storage is part of host-pool cost

FSLogix on underpowered Azure Files or a tiny on-prem share will force you to lower density to hide storage pain — you will blame WVD. Size profile IOPS for Monday logon storms. Include storage and snapshots in the monthly unit cost per active user.

The unit metric we report

Cost per active user per month = (compute + disk + profile storage + network egress estimate + management tools) / active users that month.

Active users, not provisioned seats. Empty assigned desktops that never log on are a process problem, not a density win.

Comparison to on-prem VDI

On-prem spreads capital over years and hides power and ops. WVD makes variable cost visible. Visible is better if someone owns FinOps. If nobody owns it, WVD becomes an unowned credit-card bill. Assign an owner before the second host pool.

Extended practice notes (2020)

The remaining gap between a short checklist and a usable field note is usually scenario detail. In practice, the same engagement type described above still requires explicit answers to: what is in scope this quarter, what is deferred with a date, who can halt a wave, and how success is measured in production — not in a lab.

We document those answers before the first production change. When stakeholders disagree, the disagreement is resolved in writing, not on the bridge at cutover. That habit is independent of whether the workload is mail, identity, virtualization, desktop delivery, or security hardening.

Repeatable detail also includes communication: who tells users what changes, when the freeze starts, where status is posted, and how exceptions are requested. Technical excellence without communication still produces an outage from the user's point of view.

If you're facing this

If your WVD business case assumes brochure density and zero idle, rebuild it with workload classes and a measured pilot. We size host pools and cost models for Azure desktop estates — bring concurrent estimates by role and a willingness to instrument before you scale out.

// related notes
// still relevant?

Facing a migration, platform, or AI build like this one?

This note is part of an archive spanning a decade of infrastructure work. The playbook evolved; the discipline didn't. Tell us what you're trying to ship — we reply within one business day.

Start a project →

← Back to notes