A customer recently sought guidance on the optimal connectivity model for Azure Virtual Desktop (AVD), specifically whether client sessions should use a local internet breakout at a regional office or be routed over an existing MPLS network to break out in the region hosting the session hosts.

In this post, we will cover the following:

Setting the Scene

In this scenario, there is a regional office located in the Philippines and users are accessing AVD desktops hosted in Australia (Australia East).

This office has two available connectivity options:

• Option 1: Local internet breakout using a locally provided ISP
• Option 2: Carrier-managed wide area network (MPLS), providing private connectivity between geographically dispersed sites with predictable performance and quality of service (QoS). There is an internet breakout in Australia provided by the carrier.

Managed Network connectivity will not be covered in this post.

Establishing First Contact

When a client initiates a session to AVD, it establishes a secure TLS connection to an AVD gateway through Azure Front Door (AFD). The service measures latency to all available gateways, groups them into 10-millisecond latency bands, and selects the lowest-latency gateway with the fewest active connections to broker the session.

Local Internet Breakout

When using a local internet breakout, client traffic is routed via AFD to the nearest Microsoft edge locations. In the above scenario this would most commonly be Singapore. Consequently, the AVD gateway that brokers the session will also reside in one of these regions.

MPLS Internet Breakout

When using MPLS, client traffic is backhauled across the WAN and egresses near the Microsoft edge location. In this scenario, AFD would direct the connection to an Australian edge, resulting in the AVD gateway brokering the session from Australia.

Plotting the Course

Microsoft recommends using the public internet as the default connectivity model for AVD due to the following characteristics of the service:

• Globally distributed control plane – The AVD control plane is a Microsoft-managed, globally distributed service designed to optimise connectivity and resiliency.
• Outbound-only session host connectivity – Session hosts initiate outbound connections only, removing the need to expose inbound ports and reducing the overall attack surface.
• End-to-end encrypted traffic – All client and session traffic is secured using industry-standard encryption protocols, ensuring confidentiality and integrity in transit.
• Operational simplicity – Leveraging the public internet significantly reduces network complexity, resulting in simpler deployments, easier operations, and more straightforward troubleshooting.

When using the public internet, AVD supports multiple connection methods for establishing client-to-session-host connectivity to provide the optimal user experience, including:

• Reverse Connect
• RDP Shortpath

Reverse Connect

The default connection method for RDP sessions in AVD is Reverse Connect. Reverse Connect establishes outbound connectivity over TCP port 443 and does not require inbound listeners on either the client or session host. By relying solely on outbound connections, this model simplifies network configuration and improves security posture.

Connectivity to the session host is brokered through the AVD Gateway service, which manages session establishment and routing as part of the Microsoft-managed control plane.

Shortpath

Should additional performance optimisations be requried, RDP Shortpath can be enabled. This is an optional performance enhancement, not a replacement for Reverse Connect.

When enabled and a public network connection is used, there are two possible connection types. These are attempted in the following order of preference:

• Direct UDP
• Relayed UDP

Direct UDP

This connection uses the Session Traversal Utilities for NAT (STUN) protocol, established directly between the client and the session host.

Under the Local Internet Breakout scenario, the RDP session is initially established using TCP-based Reverse Connect transport via the AVD gateway in Singapore. Direct UDP connectivity will then be attempted and if successful and determined to be the fastest path, all dynamic virtual channels, such as graphics, input, and device redirection, switch to the new UDP transport.

Under the MPLS scenario, the RDP session is initially established using TCP-based Reverse Connect transport via the AVD gateway in Australia. Direct UDP connectivity will then be attempted and if successful and determined to be the fastest path, all dynamic virtual channels, such as graphics, input, and device redirection, switch to the new UDP transport.

Relayed UDP

Relayed UDP connection using the Traversal Using Relays around NAT (TURN) protocol, where traffic is relayed between the client and the session host.

If a TURN relay is used, it’s important to note that TURN relay infrastructure is available only in a limited number of regions, which may affect how the end-to-end network path is interpreted.

The Most Logical Outcome 🖖

Now that we understand how AVD connectivity is established over the public internet, we can revisit the original question: should client sessions use a local internet breakout at the regional office, or should traffic be routed over an existing MPLS network to break out in the region hosting the session hosts.

There are a number of questions that first need to be answered before making a decision:

Latency to the AVD session host

The first consideration is the network latency between the end user and the AVD session host when using a local internet breakout compared to an MPLS-based path.

According to Microsoft guidance, user experience in AVD is highly sensitive to round-trip latency (RTT) , with different workload types tolerating different thresholds:

• Less than 100 ms Required for real-time and latency-sensitive workloads such as Microsoft Teams, CAD applications, and GPU-accelerated scenarios.
• Up to 150 ms Generally acceptable for standard productivity workloads that do not involve real-time rendering or video.
• 150 ms to 200 ms Typically suitable for text-centric and low-interaction workloads, such as document editing or basic line-of-business applications.
• Greater than 200 ms Likely to result in a noticeable degradation of user experience and should be avoided where possible.

RTT can be validated by reviewing the Connection Information details within an active AVD session, which provide real-time metrics such as round-trip latency.

Measurements should be taken for both connectivity options under comparable conditions. As a general principle, the network path that delivers the lowest and most consistent latency should be preferred, as it will provide the best overall AVD user experience.

It is also important to consider service guarantees. An MPLS circuit typically includes defined service-level agreements (SLAs) covering uptime, latency, packet loss, and jitter up to the point where traffic egresses to the public internet. By contrast, a local internet breakout provides limited or no visibility and control over the end-to-end network path, and therefore does not offer equivalent performance guarantees.

Understanding Bandwidth and Its Impact on User Experience

While latency often determines how responsive an AVD session feels, sufficient and consistently available bandwidth is essential to maintain visual quality, media performance, and overall session stability. Ensuring adequate bandwidth headroom is therefore a critical component of delivering a high-quality AVD user experience.

The Remote Desktop Protocol (RDP) bandwidth requirements can be used as a baseline to estimate the bandwidth needed to support AVD end-user sessions. Once these requirements are understood, the following considerations should be evaluated:

• Do the existing local internet breakout and/or MPLS connectivity options provide sufficient bandwidth to support the expected user load?
• If not, what is the cost of increasing the available bandwidth to meet the additional demand?
• Is the cost of increasing bandwidth a determining factor when selecting the preferred connectivity model?

Taking a structured approach to bandwidth planning helps ensure that the chosen connectivity option can support current workloads while providing sufficient capacity for future growth, without compromising user experience or cost efficiency.

Reliability

The reliability of the chosen connectivity model is also a critical consideration. If a local internet breakout experiences reliability or performance issues, an MPLS-based approach may be better suited. MPLS provides more predictable performance characteristics, including consistent latency, guaranteed packet loss and jitter thresholds, and defined service-level agreements (SLAs).

Aspect	Local Internet Breakout	MPLS
End-to-end SLA	No	Yes (within provider network)
Latency predictability	Variable	Consistent
Packet loss & jitter	Best effort	Guaranteed
Control over routing	Limited	High (provider-managed)
Cost	Low	High
Scalability	High	Limited

Cost

Many remote offices today are deployed with a local internet breakout as their primary connectivity model. In most cases, this approach is sufficient to meet core business requirements, including support for modern cloud services such as Azure Virtual Desktop.

Introducing a new MPLS circuit solely to support AVD workloads can significantly increase operational costs, often without delivering a proportional improvement in user experience. However, where an MPLS circuit already exists, the incremental operational cost of supporting AVD workloads may be minimal, making it a viable option depending on performance, capacity, and contractual considerations.

Connectivity Model	Cost per Mbps	Scalability	SLA Coverage
Local Internet Breakout	Low	High	Limited (access link only)
MPLS	High	Limited	End-to-end (within provider network)

The Most Logical Outcome

AVD is designed to operate over the public internet as its default connectivity model. In scenarios where strict performance guarantees, regulatory requirements, or existing contractual obligations apply, an MPLS-based approach may be justified. However, MPLS is rarely the most cost-effective option when used solely to support Azure Virtual Desktop connectivity.

In the next article in this series, I will explore the use of a managed network approach for connectivity.