Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Windows 365 is a globally distributed SaaS offering enabling organizations to provide secure, reliable, and high-performance desktop environments to users across multiple regions. A significant factor that determines the quality of the Windows 365 end user experience is network efficiency and lowest latency between their physical device and their Cloud PC.
Microsoft operates one of the world’s largest global networks. This network connects to Windows 365 service entry points, including RDP gateways and TURN relays, which are distributed across datacentres worldwide.
This infrastructure ensures the service is available close to users to reduce latency and lets Microsoft manage connectivity most of the path from the user’s location to their Cloud PC. It also then provides the benefit of connectivity on the return journey to the user being within Microsoft's global backbone.
This article explains how Windows 365 connectivity works, how to use its global infrastructure effectively, and why it requires a different optimization approach than standard internet traffic.
Windows 365 connectivity goals
A key goal of Windows 365 connectivity is to optimize the end user experience by enabling optimized connectivity between clients and the closest connectivity infrastructure. The quality of end user experience is directly related to the performance and responsiveness of the connectivity between the end user and their Cloud PC.
Windows 365 has a notable element in terms of a SaaS service, in that connectivity to this infrastructure is customer configurable on both sides of the connection. With SaaS services, the provider typically manages the service side, as is the case with Microsoft 365.
Windows 365 offers simple deployment options that significantly reduce the service-side elements you need to configure and manage. However, when configuring your environment, you still need to consider certain Cloud PC configurations that can affect connectivity.
Factors such as misconfigured VPNs, Secure Web Gateways (SWGs), or proxy settings can significantly disrupt service performance and reliability.
The primary objective of your network design should be to ensure secure connectivity to the service with the minimal latency possible. A key factor in achieving this outcome, is reducing the round-trip time (RTT) between client devices and the Microsoft Global Network, Microsoft’s high-performance public backbone that interconnects its global datacenters. This network delivers low latency, so data moves quickly between endpoints with minimal delay, and high availability, meaning services remain accessible even during failures or maintenance. Windows 365 also uses globally distributed entry points at the network edge, placing them close to your users for better performance. You can learn more about the Microsoft Global Network at How Microsoft builds its fast and reliable global network.
Windows 365 can be configured for the best possible performance by following a few key principles:
Provision the Cloud PC as close as possible to the user if possible to do so.
Identify Windows 365 network traffic.
Allow local egress of Windows 365 network traffic from each location where users connect to the service.
Allow key Windows 365 traffic to bypass proxies and inspection tools, and route it directly to Microsoft infrastructure.
For more information on Windows 365 network connectivity principles, see Windows 365 Connectivity principles.
Traditional network architectures and SaaS
Traditional on-premises network architectures for client/server workloads are based on the assumption that traffic between clients and endpoints remains within the corporate network perimeter. In many enterprises, all outbound internet traffic goes through the corporate network. It exits at a centralized egress point, usually a security appliance like a proxy server. This device inspects and filters the traffic before it reaches the internet.
In traditional network architectures, higher latency for generic Internet traffic is a necessary trade-off to maintain network perimeter security. Performance optimization for Internet traffic typically involves upgrading or scaling out equipment at network egress points. However, this approach fails to meet the performance needs of SaaS services like Windows 365. It becomes even more challenging because of extra connectivity elements within Azure. As such, service specific connectivity optimizations are required to ensure high performance and reliability for end users.
You may already use similar optimizations for services like Microsoft 365. Windows 365 can easily align with the same approach.
Identifying Windows 365 network traffic
Microsoft is making it easier to identify Windows 365 network traffic and making it simpler to manage the network identification.
We now highlight within the endpoint requirements documentation which endpoints require special treatment in terms of optimization and which ones can take a standard internet path with no special treatment. The endpoint requirements for the service can be found in the Network Endpoint Requirements page.
Securing Windows 365 connections
The goal of traditional network security is to harden the corporate network perimeter against intrusion and malicious exploits. Most enterprise networks enforce network security for Internet traffic using technologies like proxy servers, firewalls, Transport Layer Security (TLS) break and inspect, deep packet inspection, and data loss prevention systems. These technologies provide important risk mitigation for generic Internet requests but can dramatically reduce performance, scalability, and the quality of end user experience when applied to critical Windows 365 endpoints.
Some endpoints gain no benefit from TLS inspection or routing through proxies, VPNs, or Secure Web Gateways (SWGs). Instead, these methods can harm service reliability and user experience if not avoided.
See the Remote Desktop Protocol (RDP) security documentation for details on how RDP connectivity is secured. TLS inspection of RDP traffic isn’t required and provides no benefit.
Why is Windows 365 networking different?
Windows 365 is designed for optimal performance using endpoint security and encrypted network connections, reducing the need for perimeter security enforcement. Windows 365 runs on Microsoft’s global infrastructure. The service uses multiple methods to connect clients to the nearest and best-performing service endpoints.
This local front door for the service allows a low latency connection from the user to Microsoft’s infrastructure and high-performance global backbone, regardless of where their Cloud PC resides.
Common performance issues are created when certain Windows 365 traffic is subject to packet inspection and centralized egress:
Inefficient routing, proxies, or inspection increase latency. This latency causes poor desktop performance, low throughput, and delayed user input, leading to a poor user experience.
Routing connections from a nonlocal location bypasses Microsoft’s dynamic routing and efficiency, adding latency and round-trip time. It can also cause frequent disconnections because the path isn't optimized for long distances.
Decrypting and re-encrypting TLS traffic for Windows 365 offers no benefit, introduces security risks, and can cause protocol errors. It also increases the chance of RDP session disconnects and puts heavy load on the inspecting device. For these reasons, TLS inspection of Windows 365 RDP traffic isn't supported.
When a Cloud PC initiates connectivity, endpoints that reside on Microsoft’s infrastructure, such as RDP, can completely avoid the public internet if traffic exits locally. Routing this traffic via a Proxy, Secure Web Gateway or VPN not only causes significant performance degradation, but it also negates this direct path avoiding the internet.
In the example provided, Contoso configure optimal Windows 365 connectivity following best practice guidance. Local and direct egress for RDP at the Contoso India location, and on the Cloud PC side deployed in the USA means that multiple positive optimizations occur.
Local and direct egress means the most efficient path via the local Internet Service Provider (ISP) to reach Microsoft’s global network within a few milliseconds in India.
Local RDP Gateways and TURN relays can be used for the connection, meaning low latency from the user to these service front doors. In this example, the user is connected to the service entry point in around 10 ms.
The geographically long distance from India to the Cloud PC location in the USA is traversed entirely on Microsoft’s managed backbone, providing the highest level of performance and reliability possible.
This traffic doesn’t traverse Contoso’s global WAN. That capacity remains available for workloads that require it.

Diagram 1: RDP Optimization with local breakout
This image demonstrates the following:
- Local egress of RDP traffic in Chennai ensures the traffic enters Microsoft’s global network at the Chennai peering location.
- Local service front doors (Remote Desktop Gateways and TURN Relays) minimize latency by keeping connections close to the user.
- The long distance backhaul element from the service front door to the Cloud PC in Central US runs entirely on Microsoft’s network, providing an optimised, high-bandwidth, low-latency path with redundant links.
- This design delivers the lowest possible latency, high performance, reduced risk of disconnects, and an excellent user experience, avoiding the public internet for the majority of the path.
- When configured correctly, RDP traffic from the Cloud PC to the service front door stays entirely on Microsoft’s network and never traverses the public internet.
Summary
Optimizing Windows 365 network connectivity really comes down to removing unnecessary impediments and utilizing Microsoft’s global infrastructure. Configure key Windows 365 connections as trusted traffic to maintain low latency and prevent bandwidth contention on proxies. Allowing local connections between both the physical device and Cloud PC into Microsoft’s infrastructure enables traffic to be dynamically routed through the Microsoft Global Network and take advantage of local service front doors.