By David, , updated
Microsoft's maximum for Azure Virtual Desktop multi-session hosts is 6 users per vCPU for light workloads, 4 for medium, 2 for heavy and 1 for power users, so an 8 vCPU host tops out at 48, 32, 16 or 8 users. Those are ceilings for a first estimate, not targets: most production pools of office workers run 8 vCPU hosts at 16 to 20 sessions, because logon storms, Teams and browsers need headroom the ceiling doesn't leave.
The short version: classify users by what they run, multiply the host's vCPUs by Microsoft's figure to get the ceiling, then set the host pool's max session limit below it. For an 8 vCPU host of typical Outlook, Teams and browser users, start at 16 to 20 sessions. Prove the number in a two-week pilot by watching peak CPU, memory, logon time and user input delay, then keep re-checking it as usage changes.
Microsoft figures reflect Microsoft Learn as of November 2026, with links at the end. VM prices are the approximate pay-as-you-go rates our AVD cost calculator uses.
This post goes deep on one step of our Azure Virtual Desktop sizing guide, which covers the whole method from workload to storage.
Users per vCPU by workload
Microsoft's session host sizing guidelines give a maximum number of users per vCPU for each of four workload types on multi-session hosts. Multiplied out for common host sizes:
| Workload | Typical apps | Max users per vCPU | 4 vCPU host | 8 vCPU host | 16 vCPU host |
|---|---|---|---|---|---|
| Light | Data entry, line-of-business apps, command-line tools | 6 | 24 | 48 | 96 |
| Medium | The above plus Word and static web pages | 4 | 16 | 32 | 64 |
| Heavy | The above plus Outlook, PowerPoint, dynamic web pages, development tools | 2 | 8 | 16 | 32 |
| Power | The above plus photo and video editing, CAD and CAM | 1 | 4 | 8 | 16 |
Two things to read into the table before you use it:
- Most offices are "heavy" by Microsoft's definitions. Microsoft's medium user runs Word and static web pages. A user who lives in Outlook, Teams and a browser full of SaaS tabs is running Microsoft's heavy app list. Classify by the apps people actually run, not by job title.
- The bigger columns are theoretical. Microsoft also says that with 20 or more users on one VM, several smaller VMs usually perform better than one or two large ones. A 16 vCPU host of light users at 96 sessions is a number you'll never want to run.
Why the ceiling isn't the number to run
Microsoft calls these generic guidelines for initial estimates, and its own sizing page lists the reasons a real host carries fewer users:
- Logons are the peak, not steady state. Microsoft calls user logon a CPU-intensive operation. A host that comfortably holds 20 working users can struggle when 20 users sign in within ten minutes of each other at 9 a.m.
- CPU doesn't scale linearly. Doubling the cores doesn't double capacity. Microsoft puts the scaling factor for each doubling typically between 1.5 and 1.9, and it falls as core counts grow: going from 4 to 8 cores gains more than going from 8 to 16.
- A vCPU isn't a physical core. Azure vCPUs are hyperthreads, and Microsoft's internal testing puts the capacity cost of running on a VM at 15 to 20% compared with bare metal.
- Burst capacity matters. Microsoft's example: 12 users on a 4-core VM is 3 users per core, while 14 users on an 8-core VM is 1.75 per core. The second host has far more room for an app that briefly spikes CPU, so it feels faster even though it's "less full".
- Memory can run out first. Users per vCPU only measures CPU. Microsoft notes that when memory is the limit, going from 8 GB to 16 GB can more than double the users a host supports. If memory is your bottleneck, the right VM family matters more than the session count.
Starting session limits that work in practice
The max session limit is the number you actually set on the host pool. These are our starting points for a pilot, not Microsoft figures. Each sits below Microsoft's ceiling to leave room for logons, and the pilot tells you whether to move it:
| Workload | 4 vCPU host | 8 vCPU host | 16 vCPU host |
|---|---|---|---|
| Light | 12 to 16 | 20 to 24 | Split into two 8 vCPU hosts |
| Medium | 10 to 12 | 16 to 20 | Split into two 8 vCPU hosts |
| Heavy (most Microsoft 365 users) | 6 to 8 | 12 to 16 | 20 to 24 |
| Power | Use a GPU size | Use a GPU size | Size per user |
Power users are usually better on GPU-backed sizes, sized per user rather than per vCPU: see GPU VMs for Azure Virtual Desktop. Users who need a whole machine to themselves belong in a personal pool, which Pooled vs Personal Host Pools covers.
How to turn users per vCPU into a host count
- Use peak concurrent users, not named users. Sign-in logs from the current environment, or your VPN or Citrix concurrency reports, tell you the busiest hour. Every named user still needs a profile on storage, but only concurrent users need a session on a host.
- Divide by the session limit and round up. That's the number of hosts that carry the peak.
- Add a spare. One extra host covers draining, patching and the odd failed host without pushing the rest over their limit.
- Set the limit and the load balancing. In the Azure portal it's the host pool's Max session limit, or in PowerShell
Update-AzWvdHostPool -ResourceGroupName <rg> -Name <pool> -MaxSessionLimit 20. Use breadth-first load balancing during the pilot so users spread across hosts and you see each host under realistic load.
A worked example: 300 users
A firm has 300 named users running Outlook, Teams, a browser and a line-of-business app, with a peak of 240 concurrent users (80%), on D8as_v5 hosts (8 vCPU, 32 GB) at about $0.384 an hour. They work 10 hours a day, 5 days a week, which is 216.5 host-hours a month. Here's what the session limit does to the bill:
| Session limit | Users per vCPU | Hosts for the peak, plus a spare | Monthly compute, business hours |
|---|---|---|---|
| 32 (Microsoft's medium ceiling) | 4 | 8 + 1 = 9 | 9 × 216.5 × $0.384 = $748 |
| 20 | 2.5 | 12 + 1 = 13 | 13 × 216.5 × $0.384 = $1,081 |
| 16 | 2 | 15 + 1 = 16 | 16 × 216.5 × $0.384 = $1,330 |
Running at the ceiling looks $333 a month cheaper than a limit of 20, but these users are closer to Microsoft's heavy profile (2 per vCPU, 16 per host) than its medium one. Packing 32 of them onto a host is the configuration that produces slow logons and frozen Teams calls. A limit of 20 is a reasonable pilot starting point, and 16 is the fallback if the pilot shows CPU or user input delay climbing at peak. The compute difference between them is about $0.83 per named user per month, a small price for a desktop people don't complain about.
Put your own users, hours and VM size into the AVD cost calculator to see the full monthly estimate, including storage and autoscaling.
How to measure the real number in a pilot
Pick representative users, including your heaviest, run for at least two working weeks, and watch these signals on the busiest hosts in the busiest 15 minutes. Averages hide the problem.
| Signal | Where to look | What it tells you |
|---|---|---|
| CPU | Host CPU percentage | Sustained high CPU at peak means the limit is too high for this size |
| Memory | Available memory and paging | Paging while CPU has room means memory is the limit, not users per vCPU |
| Logon duration | AVD Insights or sign-in timing | Slow logons with idle CPU usually point at profiles and storage, not density |
| User input delay | The User Input Delay per Session performance counter | Microsoft's bar for a good experience is under 200 ms |
Change one thing at a time. If CPU is the limit, lower the session limit or go up a size. If memory is the limit, move to a memory-optimized size. If logons are slow while hosts are idle, look at storage first: why AVD logons are slow and Premium Azure Files sizing for FSLogix cover that side.
Keep the number right after go-live
Users per vCPU drifts. Browsers get heavier, Teams adds features, a new team joins the pool, or a migration moves your heaviest users elsewhere. A limit that was right at go-live can be too tight a year later or too generous after a reorganization. Review peak host metrics monthly and re-run the pilot checks after any image, VM size or user-population change.
Atlas AVD automates that review. Adaptive Density™ checks every five minutes how full each opted-in pool's running hosts are, raises or lowers the pool's max-users-per-host limit when session demand stays above or below your thresholds, and never goes outside the minimum and maximum you set. Density Templates supply those thresholds: Atlas ships Light, Medium and Aggressive templates, each working within a range of 5 to 20 users per host. Every change is recorded with its reason, the session demand, and host CPU and memory.
FAQ
How many users per vCPU does Azure Virtual Desktop support?
Microsoft's maximums for multi-session hosts are 6 users per vCPU for light workloads, 4 for medium, 2 for heavy and 1 for power users. They're ceilings for an initial estimate, and most production pools run below them.
How many users can an 8 vCPU AVD session host support?
By Microsoft's ceilings, 48 light, 32 medium, 16 heavy or 8 power users. In practice, most pools of Outlook, Teams and browser users cap an 8 vCPU host at 16 to 20 sessions to leave room for logon peaks.
Should I size AVD for named users or concurrent users?
Size session hosts for peak concurrent users, because only signed-in users need a session. Size FSLogix profile storage for named users, because every user's profile exists whether or not they're signed in.
What is the max session limit in Azure Virtual Desktop?
It's the host pool setting that caps how many sessions each session host accepts. Set it below Microsoft's users-per-vCPU ceiling for your host size, then raise or lower it from pilot data.
Is it better to use bigger or smaller session hosts?
Smaller, within reason. Microsoft recommends multi-session hosts of 4 to 24 vCPUs, and says several smaller VMs handle 20 or more users better than one or two large ones. Smaller hosts also scale in more easily, so autoscale can shut down more of them overnight.
Does users per vCPU apply to personal host pools?
No. A personal host pool gives each user their own VM, so it's one user per host. Microsoft's single-session starting points are 2 vCPUs and 8 GB for light users, 4 vCPUs and 16 GB for medium and 8 vCPUs and 32 GB for heavy.
Last updated 9 November 2026. Microsoft details are drawn from Microsoft Learn as of November 2026: Session host virtual machine sizing guidelines, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts and Update-AzWvdHostPool. VM prices are approximate pay-as-you-go rates; check the Azure pricing page for your region.