Network Capacity and Design
Azure Virtual Desktop is a network-heavy service. Every pixel, every keystroke, every mouse movement travels over the network. Get the networking wrong and your users will feel it instantly.
Why networking matters for AVD
Imagine streaming a live video call, but instead of just video, you are streaming an entire desktop.
Every click, every window resize, every Teams call — it all travels over the network. If the road (network) is too narrow or too bumpy, your users see lag, frozen screens, and dropped connections. AVD networking is about building the right roads: wide enough for the traffic, smooth enough for real-time interaction, and with enough lanes to handle rush hour.
Bandwidth requirements by workload
Microsoft provides recommended bandwidth per user based on workload type:
| Workload Type | Example Use Cases | Recommended Bandwidth | Notes |
|---|---|---|---|
| Light | Text-based apps, data entry, simple web browsing | 1.5 Mbps per user | Basic Office apps, email |
| Medium | Standard Office suite, web apps, line-of-business apps | 3 Mbps per user | Outlook, Excel, Teams (no video) |
| Heavy | Teams video calls, multimedia, rich web apps | 5 Mbps per user | Video conferencing, screen sharing |
| Power | CAD/CAM, video editing, 3D rendering, GPU workloads | 15+ Mbps per user | Requires GPU VMs, high bandwidth |
🏢 Raj’s calculation: “TerraStack has 2,000 users in the first AVD phase. Most are medium workload (Office + CRM), but 50 are CAD engineers. That is 2,000 x 3 Mbps + 50 x 15 Mbps = 6,750 Mbps ≈ 6.75 Gbps peak. Plus headroom. That is the number I take to Dmitri, the network engineer.”
Exam tip: The Experience Estimator
Microsoft provides the Azure Virtual Desktop Experience Estimator tool. It measures round-trip time (RTT) from the user’s location to Azure regions. Use it to determine which Azure region to place session hosts in — always choose the region closest to your users with the lowest RTT.
The exam may ask you to recommend a tool for assessing network readiness — the Experience Estimator is the answer.
Latency targets
| Metric | Target | Impact If Exceeded |
|---|---|---|
| Round-trip time (RTT) | Less than 150ms (ideal: less than 100ms) | Input lag, delayed mouse/keyboard response |
| Packet loss | Less than 1% | Visual artefacts, audio glitches |
| Jitter | Less than 30ms | Inconsistent audio/video quality |
🌐 Priya’s challenge: “Our team in Tokyo had 280ms RTT to West US 2. The desktops were unusable. We moved their host pool to Japan East — RTT dropped to 15ms. Always deploy session hosts close to your users.”
Network architecture for session hosts
Session hosts need connectivity in three directions:
1. Outbound to AVD control plane (required)
Session hosts must reach the AVD service endpoints over HTTPS (TCP 443). These include:
*.wvd.microsoft.com— control plane serviceslogin.microsoftonline.com— Entra ID authenticationgcs.prod.monitoring.core.windows.net— session host agent monitoring*.prod.warm.ingest.monitor.core.windows.net— diagnostics
Key point: The reverse connect transport means session hosts initiate outbound connections to the gateway — no inbound ports need to be opened.
2. Outbound to the internet (for users)
Users on session hosts typically need internet access for:
- Microsoft 365 services (Exchange, SharePoint, OneDrive)
- Web browsing
- Line-of-business SaaS applications
Route internet traffic through Azure Firewall, a network virtual appliance (NVA), or a web proxy for security and compliance.
3. Internal connectivity (on-premises and Azure resources)
Session hosts often need to reach:
- On-premises file servers (via VPN or ExpressRoute)
- Active Directory domain controllers (if AD DS joined)
- Application back-ends in other VNets
Use VNet peering, VPN Gateway, or ExpressRoute for this connectivity.
Deep dive: DNS configuration
DNS is critical for AVD. Session hosts need to resolve:
- AVD service FQDNs — use Azure-provided DNS or custom DNS that forwards to Azure DNS (168.63.129.16)
- AD DS domain controllers — if domain-joined, custom DNS pointing to your DCs is required
- File share FQDNs — for FSLogix profile storage
A common mistake is using on-premises DNS servers that cannot resolve Azure private endpoints. If you use Private Link, configure DNS conditional forwarders or Azure Private DNS zones.
VNet design patterns
| Pattern | When to Use | How It Works |
|---|---|---|
| Single VNet | Small deployments, proof of concept | All session hosts in one VNet with subnets |
| Hub-spoke | Enterprise, multi-region, on-premises connectivity | Shared services (firewall, DNS) in hub; session hosts in spoke VNets |
| Hub-spoke with Azure Virtual WAN | Large-scale, multi-region, complex routing | Managed hub with automatic routing between spokes |
🏢 Raj’s network design: “Dmitri set up a hub-spoke topology. The hub has Azure Firewall and the VPN Gateway to our Christchurch data centre. Each AVD host pool gets its own spoke VNet peered to the hub. Clean, secure, auditable.”
Subnet sizing
Plan your subnets to accommodate current session hosts plus growth:
| Host Pool Size | Minimum Subnet | Recommended Subnet | IP Addresses |
|---|---|---|---|
| Up to 50 VMs | /26 | /25 | 64 / 128 |
| 50-200 VMs | /24 | /23 | 256 / 512 |
| 200-500 VMs | /23 | /22 | 512 / 1024 |
| 500+ VMs | /22 or larger | /21 | 1024 / 2048 |
Azure reserves 5 IP addresses per subnet. Always plan for growth — changing subnet sizes later requires recreating resources.
Priya's NomadTech team in Singapore reports slow desktop performance. RTT to the host pool in West Europe is 320ms. What should Priya do first?
Raj is designing the network for TerraStack's AVD deployment. Session hosts need to connect to on-premises Active Directory domain controllers and reach the AVD control plane. Which network topology should he recommend?
Next up: RDP Shortpath, Multipath and QoS — boost performance with UDP-based transport, multi-path resilience, and traffic prioritisation.