Plan an Azure Virtual Desktop Host Pool Architecture

Recommendations for Management Groups, Subscriptions, Resource Groups, and Operational Design

Designing Azure Virtual Desktop (AVD) at scale is less about “creating a host pool” and more about building a repeatable platform: consistent images, clean separation of workloads, predictable networking, and governance that won’t collapse when you add regions, host pools, and thousands of session hosts.

This guide turns the core concepts (host pools, app groups, workspaces) into a practical architecture you can implement and operate.

---

1) Core building blocks (how AVD is organized)

Host Pools

A host pool is a collection of session host VMs that share a common configuration and are registered into AVD using the AVD agent/bootloader.

Two main types:

Personal host pool

• One user is assigned to one VM (dedicated desktop).
• Best for users who need admin rights, custom app sets, dev tools, or persistent customization.

Pooled host pool

• Many users share multi-session VMs.
• Best for standardized app sets and cost efficiency.

Design rule: All session hosts in a host pool should come from the same base image to keep the user experience consistent and simplify troubleshooting.

---

App Groups

An app group is how you publish resources to users from a host pool.

Desktop app group

• Publishes the full desktop experience.
• A default Desktop app group is typically created with the host pool.

RemoteApp app group

• Publishes individual applications (Word, Excel, line-of-business apps).
• You can create multiple RemoteApp groups per host pool to match different user personas.
• RemoteApp groups can overlap (same app published in multiple groups).

Important assignment behaviors:

• A user can be assigned to multiple app groups, and they will see a combined feed.
• A user can be assigned to both Desktop and RemoteApp in the same host pool, but they typically cannot run both types simultaneously in the same session experience the way people expect.

---

Workspaces

A workspace is a container that exposes one or more app groups to users.

Rule of thumb: Users see resources through the workspace. If an app group is not associated with a workspace, users won’t see it.

---

2) Host pool architecture decisions (the decisions that matter)

A design matrix for when you need separate host pools

You almost always need separate host pools when any of these change:

Change driver	Why it forces a new host pool
Region	Session hosts are region-bound. Latency and resiliency patterns differ.
Type (Pooled vs Personal)	Multi-session vs dedicated resource model.
VM size family	Different CPU/RAM/GPU requirements, different scaling, different cost model.
App set	You want fewer images and cleaner troubleshooting; app drift is real.
RDP properties policy	Clipboard, drive redirection, printers, Teams optimization settings differ.
Compliance/security boundary	NSGs, routing, inspection, private endpoints, segmentation requirements.

Practical takeaway: You don’t build “one big host pool.” You build multiple host pools aligned to personas, regions, and application sets.

---

3) Recommended Azure hierarchy: Management Groups and Subscriptions

Management Groups (governance layer)

Use management groups to apply consistent policy and guardrails:

Typical pattern:

• MG-Platform: shared networking, identity integration, shared monitoring
• MG-AVD-Prod: production AVD subscriptions
• MG-AVD-NonProd: dev/test/pre-prod AVD subscriptions

Apply at MG level:

• Azure Policy (approved VM extensions, allowed SKUs, tagging requirements)
• RBAC model for platform team vs AVD operators
• Cost management policies, budgets, alerts
• Defender for Cloud baselines, logging requirements

Subscriptions (scale and blast-radius layer)

A dedicated subscription for AVD resources is a common recommendation because it:

• Simplifies RBAC, policy assignments, and cost reporting
• Keeps quotas and scaling behavior predictable
• Reduces blast radius from unrelated workloads

When to use multiple subscriptions:

• You are approaching scaling thresholds for VMs per region
• You need separate billing or strict isolation
• You operate multi-region AVD at enterprise scale

Design principle: Subscriptions are your scaling and isolation unit. Management groups are your governance unit.

---

4) Resource group structure (how to organize for operations)

A clean RG strategy reduces admin overhead and prevents RBAC sprawl.

Recommended RG layout (by ownership and lifecycle)

A) Host pool RG (per host pool)

Create a dedicated RG per host pool to contain:

• Session host VMs, NICs, disks
• Host pool objects and app groups (depending on how you manage AVD objects)
• Scaling automation artifacts (runbooks, schedules, scaling plans) if scoped to this host pool

Why:

• Clean RBAC for operators of that host pool
• Clean lifecycle management (delete a host pool RG, remove the pool cleanly)
• Clean monitoring and tagging

B) Image RG (shared, controlled)

One RG for image pipeline artifacts:

• Azure Compute Gallery (or image builder resources)
• Image definitions and versions
• Automation accounts / pipelines that produce images

Why:

• Strong change control (image updates affect many pools)
• Enables versioning, rollbacks, and controlled rollout

C) Shared services RG (per region or per environment)

• Log Analytics workspace, storage accounts used by tooling
• Key Vault
• Shared monitoring/diagnostics settings

---

5) Networking architecture: hub-and-spoke for AVD

Recommended topology

• Hub VNet: shared services, firewall/NVA, VPN/ExpressRoute gateway, DNS, inspection
• Spoke VNet(s): AVD session hosts

Why:

• Centralizes routing and security inspection
• Makes it easier to add regions and spokes
• Keeps AVD subnets isolated and governed

Subnet strategy in the spoke

Minimum recommended subnets:

• Pooled-Subnet
• Personal-Subnet
• Optional: management subnet, private endpoints subnet (if used), file services subnet (if you host profile storage inside Azure)

Guidance:

• Multiple host pools can share a subnet if compliance allows and if you’re comfortable with shared NSG boundaries.
• Use NSGs and route tables intentionally. Treat session host subnets as controlled zones.

---

6) Publishing strategy: how to structure app groups and workspaces

Recommended approach

• Use workspaces as the user-facing entry point (often aligned to business unit or persona).
• Use RemoteApp app groups to publish tightly-scoped app sets for standardized roles.
• Use Desktop app group when users truly need a full desktop.

Examples:

• Workspace: “Finance”
  • RemoteApp group: “Finance Apps”
  • Desktop group: “Finance Desktop” (only if needed)
• Workspace: “Developers”
  • Personal desktops only, with a dedicated host pool and stricter entitlement

---

7) Performance planning (what directly impacts user experience)

AVD performance depends on multiple variables. The most important ones to design for:

Latency (RTT)

• Target RTT from user location to host pool region: ideally under ~150ms for acceptable interactive experience.
• Region selection matters. Place session hosts close to users.

Bandwidth (user activity drives it)

RDP traffic varies wildly:

• Code editing can be low bandwidth
• Video conferencing, high-res graphics, printing, and media are high bandwidth

Baseline planning bands often start with:

• Light: ~1.5 Mbps
• Medium: ~3 Mbps
• Heavy: ~5 Mbps
• Power: ~15 Mbps

Best practice: Treat these as starting points. Validate using pilots and real telemetry.

On-premises dependency bandwidth

If session hosts must access on-prem apps, AD DS, file shares, or databases:

• Size VPN/ExpressRoute for peak traffic
• Avoid routing bottlenecks through undersized appliances

---

8) Capacity planning: sizing pooled vs personal

Step-by-step sizing method

Step 1: Group users into personas

Examples:

• Task workers (light)
• Knowledge workers (medium)
• Analysts (heavy)
• Engineers (power)

Step 2: Determine concurrency

Not all users are connected simultaneously. Define:

• Peak concurrent percentage (example: 60%)
• Peak hours window (example: 9–11 AM)

Step 3: Map persona to per-user resource needs

Use assessment data where possible:

• CPU per user
• RAM per user
• GPU needs (if any)
• App set requirements

Step 4: Decide pooled density (users per VM)

For pooled hosts, density is usually constrained by:

• CPU contention
• memory pressure
• app behavior (some apps behave poorly in multi-session)
• Teams/AV optimization load
• profile/container I/O (FSLogix)

Step 5: Set max session limit per host

Use max session limits as a control:

• Prevent overpacking
• Stabilize performance
• Simplify autoscaling decisions

---

Worked example: pooled (simple and realistic)

• 100 users
• 60% peak concurrency → 60 concurrent users
• Each user needs roughly: 2 vCPU and 4 GB RAM (based on assessment)

Pick a host VM size:

• Example: 8 vCPU, 32 GB RAM

Potential density:

• CPU: 8 vCPU / 2 = 4 users
• RAM: 32 / 4 = 8 users

CPU becomes the constraint → 4 users per VM
To support 60 concurrent users → 60 / 4 = 15 VMs (plus buffer)

Add buffer (N+1 or 10–20% depending on SLA) → ~17–18 VMs

This produces a sizing that is resilient and avoids “perfect math” failure.

---

Worked example: personal

• 100 users
• Each user needs: 2 vCPU, 8 GB RAM
• Personal means 1 user per VM
  → 100 VMs (then optimize cost with Start VM on Connect and schedules)

---

9) Operational recommendations (how to keep AVD stable)

Image and change management

• Maintain a golden image pipeline with versioning
• Roll out image versions gradually:
  • pilot host pool
  • then production ring deployments
• Document rollback steps: deploy previous image version and replace hosts

Load testing and validation

Before production:

• Use load simulation tools (for example, Login VSI) to validate:
  • login storms
  • app launch time
  • Teams behavior
  • FSLogix profile attach times
  • steady-state performance and peak load

Monitoring

Monitor:

• Session host health and drain mode usage
• FSLogix attach times and profile I/O latency
• CPU/RAM and disk queue length
• User connection failures and gateway health signals
• Network latency and packet loss indicators

---

10) Reference architecture summary (recommended baseline)

Management Groups

• Platform
• AVD-Prod
• AVD-NonProd

Subscriptions

• AVD-Prod-Region1
• AVD-Prod-Region2 (if needed)
• AVD-NonProd
• Shared Platform (hub networking, security)

VNets

• Hub VNet per region (gateway/firewall/DNS)
• Spoke VNet per region for AVD

Resource Groups

• RG-AVD-HP–
• RG-AVD-Images
• RG-AVD-SharedServices

Host Pools

• Separate per region, per type, per VM size, per app set, per RDP profile boundary

---