Azure Virtual Desktop Sizing Guide: Users per vCPU, VM Sizes and Storage

By David, 2026-09-30

"How big should the session hosts be?" is the question every Azure Virtual Desktop project asks right before it builds, and the one most often answered with a guess. Guess too small and users get lag, slow logons and frozen Teams calls. Guess too big and you pay for idle vCPUs every hour the pool runs.

There's no single right answer, but there is a reliable method. Start from Microsoft's workload guidance, pick a VM family that matches the bottleneck, size storage and network alongside compute, then prove the density in a pilot before you scale out. This guide walks through each step and ends with a 200-user pool sized end to end.

The short version: classify your users as light, medium, heavy or power. Microsoft's ceilings are 6, 4, 2 and 1 users per vCPU respectively. Use 8 to 16 vCPU general-purpose VMs for most pooled desktops, cap sessions per host below the ceiling, give each user about 30 GB of FSLogix profile storage on a tier that matches the workload, and treat the first density figure as a hypothesis your pilot has to confirm.

Microsoft figures below reflect Microsoft Learn as of October 2026, with links at the end. VM prices are the approximate pay-as-you-go rates our AVD cost calculator uses; check the Azure pricing page for your region before you commit.

New to AVD? What Is Azure Virtual Desktop? explains host pools, session hosts and FSLogix first.

Step 1: Classify the workload

Density depends less on the VM than on what people do inside it. A data-entry clerk and a developer running builds on the same 8 vCPU host are different planning problems. Microsoft groups users into four workload types and publishes a maximum users-per-vCPU figure for each one on multi-session hosts (Session host virtual machine sizing guidelines):

Three things about this table are easy to miss.

• They're maximums, not targets. Microsoft calls them generic guidelines for initial estimates. Running a pool at the ceiling leaves no headroom for the 9 a.m. logon wave or a heavy afternoon.
• "Medium" is lighter than most offices. Microsoft's medium user runs Word and static web pages. Someone living in Outlook, Teams, a browser full of SaaS tabs and a line-of-business app all day is closer to heavy. Classify by what people actually run, not by job title.
• Logons are the peak, not steady state. Microsoft calls logon a CPU-intensive operation. A host that comfortably holds 20 working users may struggle when 20 users sign in within ten minutes of each other.

For single-session (personal) desktops, Microsoft's starting points are 2 vCPU and 8 GB for light users, 4 vCPU and 16 GB for medium and 8 vCPU and 32 GB for heavy, with a minimum of two physical cores. If you're still deciding between the two models, What Is Azure Virtual Desktop? explains them, and Pooled vs Personal Host Pools in AVD has a decision table by user persona.

Step 2: Choose a VM size and family

How big each host should be

Microsoft recommends keeping multi-session VMs between 4 and 24 vCPUs, and never above 32 cores:

• Below four cores is unstable. Windows UI rendering relies on at least two parallel threads, so several users on a 2-core VM makes the UI and apps unstable. Four cores is the lowest Microsoft recommends for a stable multi-session host.
• Above about 16 cores, returns fall. Synchronization overhead grows with core count. Microsoft says two 16-core VMs give a better experience than one 32-core VM, and that two 8-core VMs handle 30 or more users signing in within ten minutes better than one 16-core VM.
• Smaller hosts scale in better. With many smaller VMs, it's more likely some have no active users, so autoscale can shut them down. A few large VMs almost always have someone signed in.

In practice, 8 vCPU is the sweet spot for most pooled desktops, 16 vCPU suits larger pools with steady load, and 4 vCPU suits small pools where granularity matters more than headroom.

On price, the per-vCPU rate is the same up and down a family. A D8as_v5 at about $0.384 an hour costs exactly twice a D4as_v5 at about $0.192, and holds roughly twice the users. So size is a decision about stability, logon storms and scale-in, not about a cheaper hourly rate.

Which family

When a GPU is worth it

A GPU earns its cost when the application needs it (CAD, 3D modelling, rendering, video editing, GIS), and it's worth considering when users drive large or multiple high-resolution displays. Microsoft notes that CPU-only hosts encode the remote display in software, and above 3840 × 2160 total resolution users may see blocking, pixelation or freezing. Moving those users to a GPU host fixes it.

A GPU isn't worth it for Office, Teams or a browser. Teams media optimization already offloads calls to the user's device (see Microsoft Teams on Azure Virtual Desktop). Partitioned GPU sizes such as NV6ads_A10_v5 let a few designers share one GPU instead of paying for a whole card each. For engineering and design teams, see AVD for engineering and CAD.

Step 3: Memory, disks and network

Memory

Microsoft notes that when memory is the limit, adding RAM at low capacities can more than double the users a host supports (8 GB to 16 GB in their example). Plan on the OS and agents taking a few gigabytes, then budget per user. 1 to 2 GB covers light and medium users, and heavy users with modern browsers and Teams can need well over that. If pilot hosts page heavily while CPU sits idle, move from D to E-series before you add more hosts. Before you do, check that Edge isn't the cause: optimizing Microsoft Edge on multi-session hosts covers the policies that cut its per-user footprint.

OS disk

Session hosts are stateless when profiles live in FSLogix, so the OS disk only needs room for Windows, apps and temp files. Microsoft's multi-session minimum is 32 GB. Disk speed affects logon and app launch, so Premium SSD is the usual choice for running hosts. A host that's switched off still pays for its disk, though, and a pool that scales in overnight spends many hours on premium storage it isn't using. Atlas AVD's Smart Disk Tiering moves the disks of deallocated hosts down to Standard HDD, and back up to the pool's performance tier before a host starts.

Network

Remote display traffic depends on activity, not on users. Microsoft's measurements for one 1080p monitor range from almost nothing for an idle session, to 100 to 500 Kbps for Word and Excel, to several Mbps for rich web pages, PowerPoint and video (RDP bandwidth requirements). Two practical consequences:

• Inside Azure, size the subnet for hosts plus headroom for re-imaging and scale-out, and keep hosts in the same region as the profile storage and the apps they talk to.
• At the user's end, latency matters more than raw bandwidth for most office work. Microsoft's sizing guide sets the bar at under 200 ms of user input delay. Pick the Azure region closest to your users and enable RDP Shortpath where you can.

Step 4: Size FSLogix storage

Every pooled user's profile lives in an FSLogix container on a file share, so storage is sized per user, not per host.

Capacity. Microsoft's sizing tables give a minimum of 30 GB of profile storage per user for every workload type, and FSLogix's default maximum container size is 30 GB. Multiply by named users, not concurrent users, because every profile exists whether or not its owner is signed in. Then add headroom for growth, Office containers if you split them out, and snapshots.

Performance. Logon is when profile storage gets hammered: every user attaching a container at 9 a.m. is a burst of IO the share has to absorb. Microsoft's tier guidance (Storage options for FSLogix profile containers):

Azure Files or Azure NetApp Files?

• Azure Files is Microsoft's default recommendation for most customers. It's available in every region, starts at a 1 GiB share, and scales to 100 TiB per share. Premium (SSD) shares are billed on provisioned size, and standard shares are billed on usage and transactions.
• Azure NetApp Files suits large or IO-heavy estates. It has lower latency and more IOPS per volume, but it's only in select regions, needs a minimum capacity pool of 1 TiB, and gets its performance from tier times provisioned capacity. It usually pays off from the high hundreds of users upwards, or when Premium Azure Files can't keep logons fast.

Whichever you pick, watch free space. A full share doesn't slow down gracefully: it fails logons. Our FSLogix troubleshooting guide covers what that looks like, and the FSLogix Capacity Monitor flags a share running out of space before users hit it.

Step 5: Validate with a pilot, then keep measuring

Every number so far is a starting hypothesis. Microsoft describes two ways to test it. You can run a pilot with real users, adding load while you watch performance, or simulate users with load-testing tools. Pilots are usually cheaper and more realistic for small and mid-sized estates.

Run the pilot like this:

1. Pick representative users, including your heaviest ones. A pilot made only of IT staff will flatter the density.
2. Set the host pool's max session limit to your planned density and use breadth-first load balancing, so users spread across hosts.
3. Run it for at least two full working weeks, so you capture Monday logons, month-end and whatever else makes your business spiky.
4. Watch four signals at peak: CPU, memory and paging, logon duration, and user input delay. Average CPU looks fine long after users have started to complain, so look at the busiest hosts and the busiest 15 minutes.
5. Adjust one variable at a time. If CPU is the limit, lower the session limit or go up a size. If memory is the limit, switch to E-series. If logons are slow while hosts are idle, look at storage and profiles first (see why logons are slow).

Density is never set-and-forget. Workloads drift as apps update, browsers grow, new teams join, and Teams adds features. A limit that was right at go-live can be too tight a year later, or too generous after a migration moves heavy users elsewhere. Review host metrics monthly, and re-check whenever you change the image, the VM size or the user population.

How Atlas AVD adjusts density from real usage

Watching CPU, memory and session counts across every pool every month is the part most teams stop doing after go-live. Atlas AVD turns it into a policy instead.

• Adaptive Density™ checks every five minutes how full each opted-in pool's running hosts are. It averages session demand (active sessions against the limit) over an evaluation window, raises the pool's max-users-per-host limit when demand stays above the scale-up threshold, and lowers it when demand falls below the scale-down threshold. It never goes past the minimum and maximum you set, or above what a smaller VM size can carry. When hosts' CPU stays above your threshold, it can start another session host instead of packing more users on. Every decision is recorded with its reason, the session demand, and host CPU and memory.
• Density Templates supply those thresholds and step sizes. Atlas ships Light, Medium and Aggressive templates, each working within a range of 5 to 20 users per host, and you can define your own and apply them across pools.
• Adaptive SKU goes after the other half of the problem: it flags pools that consistently run well under the capacity their VM size provides, and recommends a smaller size with the projected monthly saving.

Your pilot gives you a starting density, and the engine keeps it right as usage changes, with an audit trail of why each change happened.

A worked example: 200 users, sized end to end

Here's the whole method applied to a realistic pool. The organization has 200 named users in finance and operations. They work in Outlook, Teams, Excel, a browser and a line-of-business app, mostly between 8 a.m. and 6 p.m., Monday to Friday.

1. Workload. That's more than Microsoft's "medium" (Word and static web pages) and less than "heavy" (development and content creation). Plan as medium, with the ceiling treated as a limit you won't reach: at most 4 users per vCPU.

2. Concurrency. Sign-in data from the current environment shows a peak of 170 concurrent users (85% of named users). Size for the peak, not the headcount.

3. VM size. D8as_v5 (8 vCPU, 32 GB): Microsoft's recommended size range, enough RAM for Teams and browsers, and the price is about $0.384 an hour pay-as-you-go.

4. Session limit. Microsoft's ceiling would allow 32 users (8 × 4). But Microsoft also notes that 20 or more users on one host often perform better split across smaller hosts, especially at logon. Set the max session limit to 20 (2.5 users per vCPU, about 1.6 GB of RAM per user), and let the pilot prove whether it can go higher.

5. Host count. 170 ÷ 20 = 8.5, so 9 hosts carry the peak. Add 1 spare for draining, patching and logon spikes: 10 hosts.

6. Compute cost. At $0.384 an hour:

Schedule-only scaling brings compute to about $4.16 per named user per month. Autoscaling that also drains and stops hosts as demand falls at the edges of the day goes further. The calculator's methodology models that reduction at 30 to 60% of session-host compute.

7. Storage. 200 named users × 30 GB = 6,000 GB of profile capacity before growth headroom. That's a medium workload with 200 users, so per Microsoft's table this means Premium Azure Files, or Azure NetApp Files Premium if the region supports it and logon IO needs it. Price it on the Azure Files pricing page for your region.

8. Validate. Pilot 30 representative users on 2 hosts for two weeks. If peak CPU and logon times stay healthy, the limit of 20 holds, or can rise. If not, drop to 16 and re-run the host count: 170 ÷ 16 = 10.6, so 11 hosts plus a spare.

9. Keep it right. Turn on Adaptive Density with the Medium template so the limit follows real demand, and let Adaptive SKU tell you if D8as_v5 turns out to be more than the pool needs.

Run your own numbers. Put your users, hours, VM size, storage tier and scaling mode into the AVD cost calculator for a full monthly estimate and a shareable report. For the cost levers beyond sizing, see Cut Idle AVD Compute: Our Cost Model Shows Up to 60%, the AVD cost optimization guide, and Reserved Instances vs Savings Plans on AVD for hosts that run all day.

FAQ

How many users per vCPU can 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. Treat them as ceilings: most production pools run below them to leave room for logon peaks, then use pilot data to find the real figure.

What is the best VM size for Azure Virtual Desktop?

For most pooled desktops, an 8 vCPU general-purpose VM such as D8as_v5 or D8s_v5. Microsoft recommends multi-session hosts between 4 and 24 vCPUs and never above 32. Choose E-series when memory is the bottleneck, and NV-series GPU sizes for CAD, 3D and video work.

How many users can one AVD session host support?

Multiply the host's vCPUs by the users-per-vCPU figure for your workload, then stay below it. An 8 vCPU host serving medium users tops out at 32 by Microsoft's guidance. Many pools cap it around 16 to 20, because Microsoft notes that 20 or more users on one host often perform better spread across smaller hosts.

How much FSLogix storage do I need per user?

Microsoft's sizing guidance gives 30 GB of profile storage per user as the minimum for every workload type, which matches FSLogix's default maximum container size. Multiply by named users, not concurrent ones, and add headroom for growth and snapshots.

Should I use Azure Files or Azure NetApp Files for FSLogix?

Azure Files suits most deployments: Standard for light workloads under 200 users, and Premium for medium, heavy and power users. Azure NetApp Files suits large or IO-heavy estates that need lower latency, provided it's available in your region and you can use a capacity pool of at least 1 TiB.

Do I need a GPU for Azure Virtual Desktop?

Not for Office, Teams or web apps. Teams calls are offloaded to the user's device. Use GPU sizes for CAD, 3D, rendering and video editing, or when users run displays above 3840 × 2160 total resolution, where CPU-only hosts can show artifacts.

Sources

• Microsoft Learn: Session host virtual machine sizing guidelines
• Microsoft Learn: Storage options for FSLogix profile containers in Azure Virtual Desktop
• Microsoft Learn: Remote Desktop Protocol bandwidth requirements
• Microsoft: Azure Virtual Desktop pricing