Pooled vs Personal Host Pools in AVD: How to Choose (and Mix Them)

Pooled or personal? How the two Azure Virtual Desktop host pool types differ, including breadth-first, depth-first and persistent load balancing, a decision table by user persona, app needs, admin rights, GPU and compliance, why personal desktops cost more at idle and how Start VM on Connect fixes it, hybrid patterns, and patching for each.

By David,

Every Azure Virtual Desktop host pool is created as one of two types, pooled or personal, and the choice can't be changed later. It decides how many users share a VM, where their profile lives, how you patch, and above all what you pay for VMs that are switched on with nobody using them. Most teams get it right for most users and wrong for a few. Then those few personal desktops run all night, every night.

This guide explains both types, gives you a decision table by user persona, shows where idle cost hides and how to take it off the meter, and covers how to run both side by side. It's vendor-neutral until the section on how Atlas AVD fits.

The short version: use pooled host pools on Windows 11 Enterprise multi-session for most users. Several users share each VM, profiles roam with FSLogix, and hosts are rebuilt from an image. Use personal host pools only for users who need admin rights, a GPU of their own, software that keeps state on the machine, or a dedicated machine for compliance reasons. Each personal user gets their own VM, which costs about the same running empty as it does in use, so never leave personal desktops running around the clock. Turn on Start VM on Connect, and deallocate or hibernate them when their user disconnects or signs out.

Microsoft changes AVD features from time to time. Everything below reflects Microsoft Learn as of October 2026, with links to each source so you can check what has changed since.

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


1. Definitions, and the load-balancing modes

A host pool is a set of Azure VMs, the session hosts, registered to Azure Virtual Desktop and normally built from the same image. Users are assigned to it through an application group. The host pool type decides what happens when they connect (Azure Virtual Desktop terminology).

Pooled host pools share their session hosts between users. Each sign-in goes to whichever host the load balancer picks, so a user can land on a different VM every day. Nothing a user does on a host survives beyond the session unless it's in their roaming profile, usually an FSLogix profile container on Azure Files or Azure NetApp Files. Pooled hosts usually run Windows 11 Enterprise multi-session, so each VM holds many concurrent users.

Personal host pools give each user their own session host. Once a user is assigned a VM, they get the same one every time, with their profile, installed apps and files on its disk. There's one user per VM, so personal hosts run the ordinary single-session Windows 11 Enterprise.

The host pool type is fixed when you create the pool. To move users from personal to pooled, or the other way, you create a new host pool and move the users across (Azure Virtual Desktop FAQ).

Load balancing: breadth-first, depth-first and persistent

Pooled host pools choose a host with one of two algorithms (Configure host pool load balancing):

  • Breadth-first spreads new sessions across the pool, so each user gets a less busy host. Microsoft positions it for the best user experience.
  • Depth-first fills the busiest host that still has room, up to the maximum session limit, before starting on the next. It needs a maximum session limit set. Microsoft positions it for cost: fewer hosts need to be on, and empty ones can be shut down.

Personal host pools don't load-balance at all. Their load-balancing type is Persistent, because each user maps to one session host, which is the whole point.

If you use an autoscale scaling plan on a pooled host pool, autoscale applies the load-balancing algorithm from each phase of its schedule instead of the host pool's own setting: typically breadth-first for the morning ramp-up and peak, and depth-first in the evening so sessions consolidate onto fewer hosts. AVD autoscaling covers that in depth.

Personal assignment: automatic or direct

Personal host pools have an assignment type (Configure personal desktop assignment):

  • Automatic is the default. A user assigned to the host pool gets any unassigned session host the first time they connect, and keeps it from then on.
  • Direct means an admin assigns each user to a specific session host. A user assigned to the host pool but not to a host gets a "No resources available" error.

You can switch between the two after the pool is created, and you can unassign a desktop or reassign it to a different user from the Azure portal or PowerShell. With direct assignment, one user can also be given more than one personal desktop in the same host pool, for example one for development and one for testing.


2. Decision table: which users go where

Start with pooled for everyone, then move a user to personal only when one of the rows below applies to them.

FactorPooled host poolPersonal host pool
User personaTask and knowledge workers: office apps, browser, line-of-business apps, call centerDevelopers, engineers, data scientists, admins, executives who insist on a dedicated machine
App needsA standard app set installed for all users in the image or delivered at sign-inApps users install themselves, apps that keep state or licenses on the machine, apps that refuse multi-session
Admin rightsNo. A local admin on a shared host affects every user on itYes, if you must. It's the user's own VM
GPUGPU-enabled multi-session VMs share one GPU between several users. Fine for light 3D, video and modern browsersA full or partitioned GPU for one heavy user: CAD, 3D modelling, simulation, video editing
ComplianceSession isolation within a shared OS. Enough for most regulated workloads with the right controlsA dedicated machine per user, when a policy or contract requires no OS sharing between users
Profile and dataMust roam, usually with FSLogixCan stay on the VM's OS disk, which then needs backing up
CostLowest per user: users share VMs, and hosts scale with demandHighest per user: one VM per user, even when that user is offline
Operating systemWindows 11 Enterprise multi-sessionWindows 11 Enterprise

Three practical notes:

  • Admin rights are the most common reason to go personal, and the most often wrong one. A user who needs to install one app usually needs that app in the image, or delivered with App Attach or WinGet, not admin rights on a desktop of their own. App delivery on AVD covers the options.
  • GPU is not automatically personal. Multi-session GPU VMs, including GPU-partitioned sizes, serve several light graphics users at once. Keep personal GPU desktops for the users whose workload would fill a GPU on its own.
  • The OS follows the pool type. Pooled pools use Windows 11 Enterprise multi-session, personal pools use single-session Windows 11 Enterprise, and the same Microsoft 365 or Windows Enterprise licenses cover both. Windows 11 Multi-Session vs Windows Server covers when Windows Server is the better pooled host.

Once you know which users go where, size each pool: Azure Virtual Desktop sizing guide covers users per vCPU for multi-session hosts and Microsoft's starting sizes for personal desktops.


3. Cost: why personal pools cost more at idle

Azure bills a session host's compute for every hour it's running, whether anyone is signed in or not. That's the same for both pool types. The difference is how much capacity sits idle.

A pooled host pool's idle cost is shared. At 7 p.m. a pool of 20 hosts might be down to 30 users across 3 hosts. Autoscale or a schedule drains the rest and shuts them down, and the hosts that stay on are serving several users each. Overnight, you can run one host, or none.

A personal host pool's idle cost is per user. Each desktop belongs to one person. When that person goes home, their VM keeps running at full price and serves nobody. A typical knowledge worker uses their desktop for 40 to 50 hours a week, out of the 168 hours in it, so an always-on personal desktop is idle about 70% of the time it's paid for. And unlike a pooled host, it can't be shared with someone else in the meantime.

Two things don't go away when a VM is off:

  • Deallocated VMs stop compute charges, but not storage. The OS disk, and any data disk, is still billed. For a personal desktop with a Premium SSD, that's a small but permanent cost per user.
  • A stopped VM that isn't deallocated is still billed for compute. Shutting Windows down from inside the VM leaves it stopped but allocated. It has to be deallocated through Azure.

Taking personal desktops off the meter

Microsoft gives you three tools, and you normally use all of them together:

  1. Start VM on Connect. When a user connects to a personal desktop that's deallocated, AVD starts it for them, so the VM doesn't have to be running in advance (Start VM on Connect). The user waits a minute or two for the VM to boot. It needs the Desktop Virtualization Power On Contributor role assigned to the Azure Virtual Desktop service principal, or to a managed identity on the host pool, at a scope that includes the session hosts. On pooled host pools it behaves differently: it starts a host only when none is available, and turns on more only as earlier ones reach their session limit.
  2. Autoscale for personal host pools. A scaling plan for personal pools can start desktops at the beginning of the working day, or leave them to Start VM on Connect, and deallocate or hibernate a desktop a set number of minutes after its user disconnects or signs out, with separate settings for each phase of the day (Create and assign an autoscale scaling plan). It never signs users out. It acts on desktops whose users have already disconnected or signed out, and it also deallocates a desktop that was started but never signed into.
  3. Hibernation. Hibernating a personal desktop saves its memory to the OS disk and deallocates it, so the user resumes exactly where they left off, with their apps open. It's generally available for personal host pools and not supported on pooled ones. Microsoft's current guidance is not to enable hibernation with FSLogix or App Attach on personal pools, the OS disk must be big enough to hold the VM's memory, and only some VM sizes support it.

Put together, a personal desktop that starts on connect and deallocates 30 to 60 minutes after its user disconnects runs only for the hours it's used, plus a short tail. Reservations make sense only for desktops that really do run every hour. Reserved Instances vs Savings Plans for AVD has a decision matrix by pool type.

For pooled host pools, the equivalent levers are autoscale, depth-first load balancing off-peak, and a sensible minimum host count. AVD autoscaling covers them, and the AVD cost calculator estimates what each pool type costs for your user count.


4. Running both: common hybrid patterns

Most estates of any size end up with both types. A host pool has exactly one type, so "running both" means several host pools, each with its own app groups, published to users through one or more workspaces. The patterns that work:

  • Pooled for the majority, personal for named exceptions. One or more pooled pools for everyone, and a small personal pool for developers or power users. The usual split is 85 to 95% pooled. Add users to the personal pool only through an approval, so it doesn't grow by request.
  • Personal for developers, pooled RemoteApps for shared tools. Developers get their own desktop and still use a line-of-business app published as a RemoteApp from a pooled pool, so the app is installed and patched in one place.
  • A personal GPU pool next to a pooled office pool. Engineers get a GPU desktop for CAD and a pooled desktop or RemoteApps for everything else, so the expensive VM only runs while they're doing GPU work.
  • A personal pool for compliance-scoped users. Users who handle data that mustn't share an OS with other users get personal desktops in their own pool, often in a separate subscription or virtual network with tighter controls. Everyone else stays pooled.
  • Personal as a migration bridge. Users coming from physical PCs or persistent VDI desktops start on personal desktops, then move to pooled once their apps are packaged. It works, but give it an end date: personal desktops are hard to take away once people have customized them.

If users see more than one desktop in the Windows App, name each app group's desktop so it's obvious which one to open: "Engineering workstation" and "Office desktop", not two copies of "SessionDesktop".

Coming from Citrix or VMware Horizon? Static single-session catalogs and dedicated desktop pools map to personal host pools, and random or pooled catalogs map to pooled ones. Citrix to Azure Virtual Desktop migration covers the full mapping.


5. Operations: patching, images and assignments

The two types age differently, and that's where most of the hidden operational cost of personal desktops lives.

Pooled host poolPersonal host pool
ImageThe source of truth. Every host is rebuilt from itUsed only to create the desktop. After that, each desktop drifts on its own
Monthly patchingBuild a new image version, then replace hosts in batches, draining each firstPatch each desktop in place with Windows Update for Business, Intune or Configuration Manager, like a physical PC
Feature upgradesNew image, rolling replacementIn-place upgrade on each desktop, or rebuild with the user's data moved across
Re-imagingRoutine and safe. Hosts hold no user stateDestructive. Anything on the OS disk that isn't backed up is lost
AssignmentUsers are assigned to the app group, not to hostsEach user is tied to a host. Joiners need a desktop, leavers need theirs unassigned and reclaimed
BackupBack up profile storage, not hostsBack up each desktop, or keep user data off the OS disk

What that means in practice:

  • Pooled pools are rebuilt, not patched. An image a month, tested on a pilot pool, rolled out in batches that drain first. Hosts stay identical, and a broken host is replaced rather than repaired. AVD Golden Image Management covers the full cycle.
  • Personal desktops are managed like PCs. Use the same update rings, compliance policies and app deployment as for physical devices, and make sure desktops that are deallocated most of the time still get patched. A desktop that's off on Patch Tuesday and only starts when its user connects needs updates to install on its next start, not wait for next month.
  • Reclaim leavers' desktops. In an automatic-assignment pool, a leaver's desktop stays assigned to them until someone unassigns it. Unassigning frees the VM, but the previous user's profile and files are still on its disk, so rebuild it, or delete it, before it goes to someone else.
  • Watch for drift. Over months, personal desktops gain user-installed apps, browser extensions and local admin changes. Set a policy for how long a personal desktop lives before it's rebuilt from the current image, with the user's data moved across.

6. Where Atlas AVD helps

Atlas AVD runs in your own Azure subscription and manages both pool types from one console. Here's what it does for each, and where it stops.

Both types deploy from the same wizard. In the Deploy Host Pool wizard, choose a Host Pool Type of Pooled or Personal. For a personal pool you also pick an Assignment Type of Automatic or Direct, and Atlas sets the Persistent load balancer and one session per host for you. Pooled pools start on breadth-first, and you can switch them to depth-first or change Max Users per VM in the pool's settings later. VM Provisioning builds each host from your image and confirms it registered with the pool.

Start VM on Connect is on by default. New host pools are created with Start VM on Connect enabled, and Atlas grants the Desktop Virtualization Power On Contributor role to the Azure Virtual Desktop service principal on the pool's resource group, so personal desktops can stay deallocated until their user connects. The Power on Connect setting turns it off for a pool.

Personal desktop assignments are managed in the pool. On a personal pool, the session hosts list shows each desktop's Assigned User. An admin can assign a user to an unassigned desktop, or unassign a leaver's desktop, without going to the Azure portal. To give a desktop to someone else, unassign it, then assign the new user.

Auto On/Off Scheduling works on personal desktops. Auto On/Off Scheduling sets start and deallocate times for any VM, a personal desktop included, by day of week and in the VM's own time zone. Before a scheduled stop on a session host, Atlas drains it and re-reads its live session count from Azure. If anyone is still signed in, even disconnected, the stop is deferred and retried, and you get an alert. So an "off at 8 p.m." schedule never pulls a desktop out from under someone working late.

Idle VMs shows what's running empty, personal desktops included. Idle Host Detection flags every running session host with no sessions after a five-minute startup grace, with how long it's been idle and what that costs per hour. Pool cards call out idle personal desktops as a saving. You can stop a flagged host from the same list.

Idle Timeout Shutdown is for pooled pools. Idle Timeout Shutdown runs inside Atlas's autoscale engine, which applies to pooled host pools only: it deallocates a pooled host after it's been empty for a set time, while keeping the pool's minimum capacity. Atlas doesn't autoscale personal pools, and it doesn't deallocate or hibernate a personal desktop when its user disconnects or signs out. For that, use a Microsoft autoscale scaling plan for personal host pools, alongside Start VM on Connect.

Re-imaging is for pooled pools. Re-Image All deletes each host and redeploys it from the latest image, which is what pooled hosts need every month. On a personal pool it would delete each user's files, apps and assignment along with the VM, so use it only on personal desktops whose user data lives somewhere else. Image Management builds and versions the image either way.


FAQ

What is the difference between pooled and personal host pools in AVD?

A pooled host pool shares its session hosts between users: each sign-in goes to whichever host the load balancer picks, usually running Windows 11 Enterprise multi-session with several users per VM. A personal host pool gives each user their own session host, which they get every time they connect, running single-session Windows 11 Enterprise.

Can I change a host pool from pooled to personal?

No. A host pool's type is fixed when it's created. To move users between types, create a new host pool of the other type, add session hosts to it, and assign the users to its application group.

Are personal desktops more expensive than pooled?

Usually, yes. A personal desktop is one VM per user, and it costs the same running empty as in use, so an always-on personal desktop is idle for most of the hours you pay for. Start VM on Connect plus deallocating or hibernating desktops when users disconnect closes much of the gap, but pooled hosts shared by several users still cost less per user.

What is Start VM on Connect?

Start VM on Connect is an Azure Virtual Desktop host pool setting that starts a deallocated session host when a user connects to it. On a personal host pool it starts the user's own desktop. On a pooled host pool it starts a host only when none is available. It needs the Desktop Virtualization Power On Contributor role assigned to the Azure Virtual Desktop service principal or the host pool's managed identity.

Can personal host pools autoscale?

Yes. Autoscale scaling plans for personal host pools can start desktops on a schedule or leave them to Start VM on Connect, and deallocate or hibernate a desktop a set number of minutes after its user disconnects or signs out. Autoscale never signs users out of a personal desktop.

What is the difference between breadth-first and depth-first load balancing?

Breadth-first spreads new sessions across a pooled host pool's hosts, for the best user experience. Depth-first fills one host up to its maximum session limit before using the next, so fewer hosts need to be running. Personal host pools use Persistent load balancing, because each user always goes to their own desktop.

Should I use FSLogix with personal host pools?

You don't have to. On a personal desktop, the profile can stay on the VM's own disk, because the user always signs in to the same VM. FSLogix still helps if you want to rebuild or replace personal desktops without losing user data, but Microsoft says not to enable hibernation on personal pools that use FSLogix or App Attach.


Sources