Azure Virtual Desktop host pool: types, templates, and management explained
Every Azure Virtual Desktop (AVD) deployment starts with at least one host pool. Get the configuration right and users get consistent performance without runaway Azure costs. Get it wrong and you are either overspending on idle VMs or fielding tickets from users waiting for sessions to spin up.
This guide is written for IT administrators and infrastructure engineers responsible for AVD environments, the people making day-to-day decisions about host pool configuration, image updates, and scaling behavior. It covers host pool types, the component hierarchy, load balancing, auto-scaling, and the 2025 changes that affect existing deployments, all within the context of Windows Cloud (AVD and Windows 365).
What is an AVD host pool?
A host pool is the foundational unit of an AVD deployment. It is a collection of Azure virtual machines, called session hosts, that share a common configuration and deliver desktops or applications to users.
Every decision about how users connect, what they access, and how resources scale happens at the host pool level. Load balancing algorithm, maximum session limits, RDP properties, assignment type, and scaling plans are all set here. Change those settings and every session host in the pool inherits the change.
When a user launches the Windows App client, the AVD broker identifies which host pool that user belongs to, finds a session host with available capacity, and routes the connection. The user never sees any of this; they just get a desktop.
One hard constraint is regarding the host pool type (pooled or personal). It is set at creation and cannot be changed afterward. Plan the right type before provisioning. Changing it later means creating a new pool and migrating users.
Pooled vs. personal host pools: which type do you need?
The choice comes down to whether each user needs their own dedicated VM or if multiple users can share one?
When to use a pooled host pool
Use a pooled host pool when users have standardized workflows and do not need a persistent, dedicated machine. Task workers, call center staff, and knowledge workers who run web-based applications are good candidates.
Pooled host pools work on a multi-session model where multiple users share a single host VM, each running their own isolated session. AVD assigns users to session hosts dynamically. When a user disconnects, their session is cleaned up and the host is available for the next person. Because many users share fewer VMs, per-user compute costs stay low.
When to use a personal host pool
Use a personal host pool when users need a machine that is always theirs. Power users, developers, and anyone running GPU-accelerated workloads or applications that require persistent local configurations should be on personal host pools.
Each user gets a dedicated session host VM in a 1:1 relationship and always returns to the same machine. Personal host pools support two assignment types:
- AVD single-session pooled – Full desktop experience. Users are placed on individual desktop VMs (one user per session host) and a pre-configured number of spare (available) desktops is maintained.
- AVD single-session personal (or dedicated) – Personal (persistent) full desktop experience. A dedicated session host VM is assigned to each user.
As of June 2025, direct assignment also supports assigning a single user to multiple personal desktops within one host pool.
| Characteristic | Pooled host pool | Personal host pool |
| User-to-VM relationship | Many-to-one (multi-session) | One-to-one (dedicated) |
| Session persistence | Non-persistent by default | Persistent |
| Load balancing | Breadth-first or depth-first | Not applicable |
| Assignment type | Dynamic (service-assigned) | Automatic or Direct |
| Auto-scaling support | Power management and dynamic autoscaling | Power management |
| Best for | Task workers, call centers, standardized knowledge workers | Developers, power users, GPU workloads |
| User profile handling | FSLogix recommended for profile persistence | Local profiles persist on the VM |
| Per-user compute cost | Lower (shared resources) | Higher (dedicated VM) |
Personal host pool auto-scaling is generally available and supports start-on-connect and disconnect- or logoff-based hibernation. For a side-by-side breakdown of when each model fits, see session-based vs. personal desktops.
Why enterprises run multiple host pools
Many environments need more than one host pool because different users have different compute needs and different working hours.
Performance requirements vary by user type. A task worker on a web-based CRM does not need the same VM size as a financial analyst running Excel models with 500,000 rows. One host pool with one template VM forces a choice: throttle the analyst, or overprovision for the task worker. Separate host pools sized for each user type eliminate that trade-off.
Geographic distribution creates time zone mismatches. An organization with offices in New York and Los Angeles cannot use the same scaling schedule for both. Scaling down at 6 PM Eastern cuts capacity while West Coast users are still in their workday. Separating host pools per region, each with their own scaling plan, solves this.
The host pool component hierarchy: Golden image, template VM, and session hosts
Host pool management follows a three-layer stack: a Golden image at the top, a template VM in the middle, and session host VMs at the bottom. Changes made at the wrong layer either fail to persist or require rebuilding everything below them.
The Golden image is the master VM image for the entire environment. It contains the operating system, organization-wide applications, security configurations, and agent installations. Keep it broadly applicable. Department-specific or user-specific customizations belong lower in the stack.
The host pool template VM is the standard for one specific host pool. It inherits the Golden image and adds pool-level configurations: VM sizing (CPU, RAM), OS disk size and performance tier, department applications, and group policies for that pool’s users. Every session host in the pool is cloned from this template.
Session host VMs are what users actually connect to. In pooled host pools, treat them as disposable. They are deleted and rebuilt regularly through scaling operations and image updates. Any change made directly on a session host is gone the next time that host is replaced. If a change needs to persist, it belongs on the template VM.
How to manage host pool templates
Every application install, security patch, and configuration change for a host pool should be made on the template VM, not on individual session hosts. That is the core rule. Everything in template management flows from it.
The standard update workflow
The update process follows the same five steps every time:
- Power on the template VM.
- Make your changes: install software, apply updates, adjust configurations.
- Run Sysprep to generalize the image.
- Set the updated template as the new image for the host pool.
- Update session hosts. This replaces existing hosts with new ones cloned from the updated template.
Testing is safe because session hosts are disposable. Spin up a session host, apply the change, and validate. If it works, push it to the template and update. If it breaks, delete the session host and clone a fresh one from the current template. Nothing is lost.
Natively, this is a manual and click-heavy process. Independent testing by Dr. Tritsch IT Consulting found that updating a custom image through the Azure portal takes 146 clicks across multiple portal blades. Reimaging session hosts natively takes 90 clicks. That overhead adds up across every update cycle and every host pool in the environment.
How AVD load balancing works
When a user connects to a pooled host pool, the AVD service decides which session host gets that session. Two algorithms control that decision. The choice affects cost, user experience, and how many VMs are running at any given time.
Breadth-first: balanced distribution
Breadth-first spreads sessions across all available session hosts as evenly as possible. Use it during peak hours when performance matters more than cost consolidation.
The algorithm selects from the half of session hosts with the fewest active sessions. Distribution will not be perfectly even, but load stays reasonably balanced across hosts. Breadth-first is the default. You can set a maximum session limit per host pool, but breadth-first does not require one to function correctly.
Depth-first: cost consolidation
Depth-first fills one session host to its maximum session limit before routing users to the next host. Use it during off-peak hours when reducing the number of running VMs is the priority.
By consolidating sessions onto fewer hosts, depth-first allows other VMs to remain stopped and deallocated, which stops compute charges. That cost saving only works if you explicitly configure the maximum session limit to reflect the VM’s actual capacity. With depth-first enabled and the session limit left at the default, the algorithm fills hosts past their practical capacity, degrading performance without delivering the expected cost reduction.
Two override behaviors apply regardless of which algorithm is active:
- First, the load balancing setting in a scaling plan takes precedence over the algorithm configured on the host pool. If the scaling plan specifies depth-first during off-peak and the host pool is set to breadth-first, the scaling plan wins.
- Second, session hosts in drain mode stop accepting new connections but continue serving active sessions until users sign out. A user with a disconnected session on a draining host will reconnect to that same host, not a different one.
See Microsoft’s load balancing documentation for configuration steps. Load balancing does not apply to personal host pools, since each user always connects to their assigned VM.
How to auto-scale AVD host pools to cut Azure costs
Auto-scaling controls which session hosts are running and when, and that directly determines your Azure compute bill. AVD auto-scaling works through two approaches. Power management autoscale is available for all environments while dynamic autoscaling is in preview and adds real-time responsiveness.
Power management autoscale
Power management autoscale starts and stops session hosts on a defined schedule. It is generally available for both pooled and personal host pools.
You configure it through a scaling plan with four phases: ramp-up, peak, ramp-down, and off-peak. Each phase sets a load balancing algorithm, a minimum percentage of hosts to keep running, and a capacity threshold that triggers additional hosts to start. During off-peak, VMs power down and are deallocated, which stops compute charges for those machines.
Both autoscale approaches require role-based access control (RBAC) permissions assigned to the AVD service principal in your Azure subscription. A common misconfiguration is assigning those permissions at the resource group level rather than the subscription level. For power management this causes scaling failures; for dynamic autoscaling it prevents the feature from starting at all.
Dynamic autoscaling (preview)
Dynamic autoscaling responds to real-time demand rather than a fixed schedule. Instead of waiting for a phase transition, it can start or stop session hosts as user load changes minute to minute.
It requires session host configuration and is currently limited to pooled host pools in Azure; it is not available in Azure Government. It cannot run on the same host pool as other scaling scripts.
Standby hosts
A standby host is a session host that is provisioned but powered off and deallocated. When a user connects and no running host has capacity, Azure boots the standby host instead of provisioning a new VM from scratch. Startup time drops from several minutes to seconds.
Regional host pools: what the preview means for new deployments
Regional host pools keep all host pool metadata in a single Azure region rather than distributing it across a multi-region geography. That changes the failure model: a regional infrastructure issue no longer affects metadata stored in another region because there is no cross-region dependency.
The current geographical model stores metadata across a geography spanning multiple Azure regions. Microsoft has signaled geographical pools will eventually be deprecated.
Regional host pools are currently limited to East US 2 and Central US. They do not yet support App Attach, Private Link, or dynamic autoscaling.
If you are planning a new deployment in East US 2 or Central US, evaluate regional pools now. For existing deployments, no action is needed until Microsoft publishes a migration path and expands regional availability.
How Nerdio Manager reduces host pool management overhead
Nerdio Manager for Enterprise cuts the manual work out of AVD host pool management by replacing multi-step portal workflows with automated, single-console operations across Windows 365, Microsoft Intune, and AVD.
Fewer clicks, less portal work
Natively, updating a custom image takes 146 clicks across multiple Azure portal blades. Nerdio Manager reduces that to 13 clicks, completed in 37 seconds, per Dr. Tritsch IT Consulting testing (previously cited). Reimaging session hosts drops from 90 clicks to 10. Fewer manual steps also means fewer opportunities for configuration errors in production environments.
That reduction compounds across every update cycle, every host pool rebuild, and every scaling configuration change in the environment. Sage, a global payroll and accounting provider, achieved 62–65% savings on VM costs and $1.5 million in annual savings after deploying Nerdio Manager across their AVD environment, scaling from 200 to 1,000 accounting clients without adding headcount. TechTarget’s Enterprise Strategy Group’s September 2024 economic validation found that a modeled organization saw costs and risk reductions 53% lower with Nerdio Manager than with unmanaged VDI.
Nerdio Manager handles image lifecycle management, versioning, and distribution through automated desktop orchestration, built on top of Microsoft’s native control plane.
What changes with Windows 365 and Intune in the same console
With Nerdio Manager, you stop managing Windows 365, Intune, and AVD from three separate consoles. Windows 365 Cloud PC management, Intune policy work, and Azure Virtual Desktop host pool operations all run from the same interface.
For Windows 365, that means Unified Application Management for importing and deploying apps, including deployment to Intune; Cloud PC right-sizing insights to flag oversized VMs and underused licenses; and Intune policy backup and restore.
For related context on how all of this connects, see how AVD deployment works, review the AVD setup guide, or get a broader view of AVD management.
Get a demo to see host pool management, image updates, and auto-scaling from a single console.
Frequently asked questions about AVD host pools
What is the difference between pooled and personal host pools?
Pooled host pools put multiple users on shared, multi-session VMs where each user gets their own isolated session. Personal host pools give each user a dedicated VM they always return to. Pooled is more cost-efficient for standardized workloads. Personal suits users who need a persistent machine with their own configurations or GPU resources.
Can I change a host pool type after it is created?
No. The host pool type is fixed at creation. If you need to switch between pooled and personal, create a new host pool of the correct type and move users to it.
How does load balancing work in a pooled host pool?
The AVD service handles session routing natively. Breadth-first distributes sessions across hosts evenly; use it when performance matters most. Depth-first fills one host before starting the next; use it to reduce the number of running VMs during low-demand periods. Load balancing does not apply to personal host pools.
Does auto-scaling work with personal host pools?
Yes. Personal host pool auto-scaling is generally available and supports start-on-connect. Autoscale only deallocates a personal desktop’s session host after the user has signed out; it does not end active or disconnected sessions.
What is session host configuration?
Session host configuration is a Microsoft feature in public preview that automates how session hosts are updated. Rather than manually replacing hosts after an image change, it stores the VM configuration as a host pool sub-resource and handles rolling updates automatically. It requires managed identity authentication and was announced in November 2024.
What is the managed identity requirement for AVD host pools?
As of November 2025, existing host pools using session host configuration cannot create new session hosts without managed identity configured. New host pools created through the Azure portal since September 2025 must use managed identity. Standard host pools not using session host configuration are not on the same enforcement timeline.
