Plan and implement an Azure Virtual Desktop infrastructure
Follow the resource chain
An AVD deployment is a chain, and most questions ask which link controls a behavior: host pool (session hosts plus load balancing) → application group (what is published: full desktop or RemoteApp programs) → workspace (what the user sees in the client). Session hosts are ordinary Azure VMs registered to the pool by the AVD agent. The service brokers connections over a reverse-connect channel, so hosts need outbound TCP 443 to the service and no inbound RDP from the internet.
Pooled versus personal
Pooled pools share hosts and use breadth-first (spread sessions evenly, more resilient) or depth-first (fill hosts before adding more, cheaper together with scaling plans); max session limit caps sessions per host. Personal pools give each user a dedicated host, assigned automatically or directly.
Sizing and placement
Use per-concurrent-user guidance - light ≈ 2 vCPU, medium ≈ 4 vCPU, heavy ≈ 6–8 vCPU - multiplied by concurrency, not headcount, plus N+1 headroom. Build one image in Azure Compute Gallery, spread hosts across availability zones or fault domains, and prefer Trusted Launch.
Traps
Host pool type cannot be changed after creation - you recreate the pool. Registration keys expire, so regenerate before adding hosts. Drain mode blocks new sessions but leaves existing sessions running. A personal pool still needs an application group and workspace before anyone can connect.
Rule of thumb: if max session limit × healthy hosts is less than peak concurrency, you are one failed host away from an outage - size for N+1.