Network topology and connectivity for Azure Virtual Desktop
The design and implementation of Azure Virtual Desktop Azure networking capabilities is critical for your Azure Virtual Desktop landing zone. This article builds on several Cloud Adoption Framework enterprise-scale landing zone's architectural principles and recommendation to manage network topology and connectivity at scale.
The design foundations include:
- Hybrid integration for connectivity between on-premises, multi-cloud, edge, and global users. For more information, see Enterprise-scale support for hybrid and multi-cloud.
- Performance and reliability at scale for consistent, low-latency experience, and scalability for workloads.
- Zero-trust based network security to secure network perimeter and traffic flows. For more information, see Network security strategies on Azure.
- Extensibility for easily expanding network footprint without design rework.
Networking components and concepts
Azure Virtual Network is the fundamental building block for private networks in Azure. With Azure Virtual Network, many types of Azure resources, such as Azure Virtual Machines (VMs), can securely communicate with each other, the internet, and on-premises datacenters. A virtual network is similar to a traditional network that you operate in your own datacenter, but has the Azure infrastructure benefits of scale, availability, and isolation.
Hub-spoke network topology, a hub virtual network acts as a central point of connectivity to several spoke virtual networks. The hub can also be the connectivity point to on-premises datacenters. The spoke virtual networks peer with the hub and helps to isolate workloads.
Azure Virtual WAN is a networking service that brings networking, security, and routing functions together in a single operational interface.
The capabilities of Azure Virtual Wide-Area Network (WAN) include:
- Branch connectivity automation from Virtual WAN partner devices such as SD-WAN or customer premises equipment (CPE) based virtual private networks (VPNs)
- Site-to-site VPN connectivity
- Remote user point-to-site VPN connectivity
- Private Azure ExpressRoute connectivity
- Intra-cloud connectivity like transitive connectivity for virtual networks
- VPN ExpressRoute interconnectivity
- Azure Firewall
- Encryption for private connectivity
Network virtual appliance (NVA) is a network device that supports functions like connectivity, application delivery, wide-area network (WAN) optimization, and security. NVAs include Azure Firewall and Azure Load Balancer.
In Forced tunneling scenario all internet-bound traffic originating on Azure VMs is routed or "forced" to go through an inspection and auditing appliance. Unauthorized internet access can potentially lead to information disclosure or other types of security breaches without the traffic inspection or audit.
Network Security Group (NSG) is used to filter network traffic to and from Azure resources in an Azure virtual network. A network security group contains security rules that allow or deny inbound network traffic to, or outbound network traffic from, several types of Azure resources.
Application Security Group (ASG) enable you to configure network security as a natural extension of an application's structure. It allows you to group virtual machines and define network security policies based on those groups. You can reuse your security policy at scale without manual maintenance of explicit IP addresses.
User Defined Routes (UDR) can be used to override Azure's default system routes, or to add additional routes to a subnet's route table.
To establish the Azure Virtual Desktop landing zone, the design and implementation networking capabilities is critical. Azure networking products and services support a wide variety of capabilities. Which architecture to choose and how to structure services depends on your organization's workloads, governance, and requirements.
The following key requirements and considerations that affect your Azure Virtual Desktop deployment decision:
- Internet ingress and egress requirements.
- NVA use in the current architecture.
- Azure Virtual Desktop connectivity to a standard hub virtual network or Virtual WAN hub.
- Session host connection model (native and Remote Desktop Protocol (RDP) Shortpath).
- Traffic inspection requirements for:
- Internet egress from Azure Virtual Desktop.
- Internet ingress to Azure Virtual Desktop.
- Azure Virtual Desktop to on-premises datacenters.
- Azure Virtual Desktop to other Azure Virtual Network.
- Traffic within the Azure Virtual Desktop virtual network.
The following scenarios describe the most common networking for Azure Virtual Desktop. This list isn't exhaustive. For more scenarios.
The most common networking scenarios for Azure Virtual Desktop include:
Scenario: Hub & Spoke with hybrid connectivity
This scenario is ideal if:
- You don't need traffic inspection between Azure Virtual Desktop networks and other Azure virtual networks.
- You don't need traffic inspection between Azure Virtual Desktop networks and on-premises datacenters.
- You don't need traffic inspection of internet outbound traffic from Azure Virtual Desktop networks.
- You don't need to control the public IPs use to SNAT Azure Virtual Desktop internet outbound connections.
- You don't enforce Azure Virtual Desktops networks internal traffic.
- You have pre-existing hybrid connectivity to on-premises (Express Route or S2S VPN).
- You have pre-existing AD DS and DNS custom servers.
- You consume Azure Virtual Desktop with standard connection model (No RDP Shortpath).
You can implement this scenario with:
- AD DS servers and custom DNS servers.
- Network security groups.
- Network Watcher.
- Outbound internet via default Azure vNet path.
- Express route or VPN virtual network gateway for hybrid connectivity to on-premises.
- Azure private DNS zone.
- Azure private endpoints.
- Azure files service on storage accounts.
- Azure key vault.
- This scenario doesn't account for client direct network connectivity to session public or private (no RDP Shortpath) hosts.
- Azure Virtual Desktop control plane Gateway (public endpoint) manages client connections. Therefore AVD clients can create outbound connections to required AVD URLs (check required URL list under general design considerations and recommendations).
- No public IPs or any other public inbound path to session hosts is needed, traffic from clients to session hosts flows through Azure Virtual Desktop control plane gateway.
- No virtual network peering between Azure Virtual Desktop spokes, all the traffic goes through the connectivity hub.
- Outbound internet connection from Azure Virtual Desktop session hosts goes through the default Azure outbound NAT using dynamic Azure public IPs (no customer control on outbound public IPs used).
- Connections from session hosts to Azure files (storage accounts) are established using private endpoints.
- Azure private DNS zones are used to resolve private endpoint namespaces:
- Storage account file service (privatelink.file.core.windows.net).
- Key vaults (privatelink.vaultcore.azure.net).
- Even though for this scenario network filtering is not enforced, NSGs are placed on all subnets to enable monitoring and insights by using network watcher NSG flow logs and traffic analytics.
General design considerations and recommendations
Here are some general design considerations and recommendations for Azure Virtual Desktop network topology and connectivity:
Hub-spoke vs. Virtual Wide Area Network (WAN) network topology
Virtual WAN supports transit connectivity between VPN and ExpressRoute, but doesn't support hub-spoke topology.
Identity services connectivity requirements of Azure Virtual Desktop session hosts depends on the identity model that is chosen.
- Azure AD Domain Services (AD DS) joined VMs: Azure Virtual Desktop networks must have connectivity to the network where the identity service is hosted.
- Azure AD (Azure AD) joined VMs: Azure Virtual Desktop session hosts create outbound connections to Azure AD public endpoints, therefore no private connectivity configurations required.
Azure Virtual Desktop session hosts have the same name resolution requirements as any other IaaS workload, therefore connectivity to custom DNS servers or access (via vNet network link) to Azure Private DNS zones is required. Additional Azure private DNS zones are required to host the private endpoint namespaces of certain (storage accounts, key) Platform As A Service (PaaS) services.
To facilitate end user Azure Virtual Desktop client configuration (subscription to RDS feed), it is recommended to set up email discovery in the public DNS domain and set up email discovery to subscribe to your RDS feed.
Bandwidth and latency
Azure Virtual Desktops use Remote Desktop Protocol (RDP). To know more about RDP, see Remote Desktop Protocol (RDP) bandwidth requirements.
The connection latency varies depending on the location of the users and the virtual machines. Azure Virtual Desktop services continuously rolls out to new geographies to improve latency. To minimize the latency perceived by Azure Virtual Desktop clients, use the Azure Virtual Desktop Experience Estimator to get round trip time (RTT) sample from clients. You can use this information to place session hosts in the closest region with the lowest RTT to the end users (interpreting results from estimator tool).
Quality of Service (QoS) with RDP Shortpath
RDP Shortpath for managed networks provides a direct UDP-based transport between Remote Desktop Client and Session host. RDP Shortpath for managed networks enables configuration of Quality of Service (QoS) policies for the RDP data. QoS in Azure Virtual Desktop allows real-time RDP traffic that's sensitive to network delays to "cut in line" in front of traffic that's less sensitive.
You can learn more information on QoS, see Implement Quality of Service (QoS) for Azure Virtual Desktop
Azure Virtual Desktop compute resources and clients require access to specific public endpoints that creates the need for internet-bound connections. Network scenarios like forced tunneling to enhance security and filtering are supported when Azure virtual Desktop requirements are met.
See Required URL list and check tool to understand the requirements for AVD session hosts and client devices.
Ports and protocols requirements
The Azure Virtual Desktop connection flow uses:
Business continuity and disaster recovery (BCDR)
A networking setup with the same capabilities as the one on the source environment or that at least has connectivity to identity and DNS services is required to deploy and recover these resources to a target environment.
Follow Azure networking best practices
For networking design process, see:
- Plan virtual networks. Learn how to plan for virtual networks based on your isolation, connectivity, and location requirements.
- Azure best practices for network security. Learn about Azure best practices that can help you enhance your network security.
- Best practices for networking when you migrate workloads to Azure. Get more guidance about how to implement Azure networking to support workloads.