Client Context
The organization used Azure Virtual Desktop to provide remote access to applications and desktop resources. Users connected from multiple locations, including office networks, home networks, and remote sites. Some users connected through managed network paths such as VPN or private connectivity, while others connected across public internet paths.
The Azure Virtual Desktop session hosts were deployed in Azure and depended on normal Azure platform connectivity, identity services, profile access, monitoring, update services, and outbound internet access. The customer also used network security controls such as subnets, route tables, Network Security Groups, and firewall rules to manage traffic.
As the environment grew, the customer needed a clearer way to separate user experience problems from network design problems. A slow session could be caused by several factors, including client-side internet quality, regional distance, packet loss, overloaded session hosts, profile storage performance, blocked UDP traffic, firewall inspection, or inefficient routing. The customer wanted help reviewing the AVD network design so the team could focus on the most likely causes and make targeted improvements.
Customer Challenge
The main challenge was inconsistent Azure Virtual Desktop latency. Some users reported responsive sessions, while others experienced delays during interactive work. The customer did not want to assume that session host sizing was the only issue. They needed a broader review of the connection path, protocol behavior, and network controls.
A second challenge involved RDP Shortpath readiness. The customer understood that Shortpath could improve the user experience by allowing a more direct UDP-based path where network conditions allowed it. However, they needed help understanding when Shortpath was appropriate, what prerequisites mattered, and how to avoid opening unnecessary risk in the network.
A third challenge involved outbound public IP control. Some destinations required the customer to provide fixed public IP addresses for allow-listing. The customer needed to know when Azure NAT Gateway made sense, when Azure Firewall should remain part of the design, and how to handle cases where more than one outbound public IP address was required.
Why AVD Latency Needs a Network Review
Azure Virtual Desktop performance depends on more than virtual machine size. Session host CPU, memory, storage, profile containers, and application behavior all matter, but the network path is often a major part of user experience. Real-time desktop interaction is sensitive to latency, jitter, packet loss, and unnecessary routing hops.
For this customer, BI Cloud Tech reviewed the design from the user’s device to the AVD session host and from the session host to required services. The review considered client locations, Azure region placement, remote access paths, firewall rules, UDP reachability, route tables, and how outbound traffic was controlled.
The goal was to create a structured troubleshooting model. Instead of treating every user complaint as a general “AVD is slow” issue, the customer needed a way to ask better questions: Which users are affected? Where are they connecting from? Is UDP available? Is Shortpath being used? Is traffic hairpinning through a firewall or VPN? Are route tables sending traffic through the expected next hop? Are session hosts close enough to the users they serve?
How We Helped
BI Cloud Tech helped the customer review the Azure Virtual Desktop network architecture and identify areas that could affect latency, reliability, and outbound control. The review included Azure Virtual Desktop host pool networking settings, session host subnet design, Network Security Groups, route tables, firewall paths, DNS behavior, and client connectivity patterns.
The engagement also included a review of RDP Shortpath options. BI Cloud Tech helped explain the difference between managed network scenarios, where a private path such as VPN or ExpressRoute can provide direct line-of-sight connectivity, and public network scenarios, where STUN or TURN can help establish or relay UDP connectivity depending on network conditions.
For outbound access, BI Cloud Tech reviewed where Azure NAT Gateway could help provide controlled, scalable outbound connectivity. The recommendation was not simply to add a gateway everywhere. The design needed to account for whether traffic was leaving directly from the AVD subnet, being forced through Azure Firewall, or following a hub-and-spoke architecture. This type of architecture review helped the customer connect user experience, routing, and security requirements in one design discussion.
RDP Shortpath Readiness Review
RDP Shortpath was a key part of the review because it can help Azure Virtual Desktop sessions use UDP when the network path supports it. UDP-based transport can provide more consistent responsiveness for interactive remote desktop traffic than relying only on TCP-based reverse connect behavior.
BI Cloud Tech helped the customer review which Shortpath mode was appropriate for each connectivity scenario. For managed networks, such as site-to-site VPN, point-to-site VPN, or ExpressRoute, the customer needed to evaluate whether client devices had direct private network reachability to session hosts. In those cases, the design needed to consider listener configuration, firewall rules, and the default UDP port used for managed network Shortpath.
For public networks, BI Cloud Tech helped the customer understand that Shortpath behavior depends on whether direct UDP can be established or whether relayed UDP is needed. The review focused on readiness, not assumptions. The customer needed a way to verify which transport was actually being used by client sessions and whether firewall, NAT, or client network restrictions were preventing UDP from working.
Firewall, NSG, and Route Table Review
Network security controls were reviewed because they can directly affect AVD latency and Shortpath success. AVD environments often include Network Security Groups, user-defined routes, Azure Firewall, private DNS, and on-premises routing. These controls are important, but they can also introduce unnecessary hops or block traffic that is needed for optimal session performance.
BI Cloud Tech reviewed whether session host subnets had the expected outbound access, whether route tables forced traffic through the correct inspection point, and whether firewall rules supported required Azure Virtual Desktop communication. The review also considered whether UDP traffic was permitted where Shortpath was expected to work.
The customer gained a clearer view of which controls were required for security and which controls needed adjustment for performance. The purpose was not to bypass security. The purpose was to align security controls with the correct AVD traffic pattern so the organization could maintain governance without creating avoidable latency.
Outbound IP Design with Azure NAT Gateway
The customer also needed controlled outbound IP behavior. Some external systems required known source IP addresses before allowing connections. Relying on implicit or changing outbound behavior was not appropriate for those scenarios.
BI Cloud Tech reviewed Azure NAT Gateway as an option for explicit outbound connectivity. NAT Gateway can provide a stable outbound IP or outbound IP pool for resources in associated subnets. This made it relevant for workloads where third-party allow-listing, predictable egress, or outbound SNAT scale mattered.
The design discussion included an important point: multiple outbound IP addresses are useful when the customer needs a larger approved source IP pool or more outbound SNAT capacity. However, using multiple public IPs does not automatically mean each user, VM, or application gets a dedicated outbound IP. If the customer needs one-to-one mapping, dedicated egress by workload, or strict per-application outbound identity, the design may require separate subnets, separate NAT Gateway resources, Azure Firewall policy design, or another network virtual appliance approach.
When More Than One Outbound IP Address Is Needed
The customer had scenarios where one outbound public IP address might not be sufficient. Common reasons include third-party allow-listing requirements, outbound connection scale, separation between environments, or the need to provide more than one approved source IP to external partners.
BI Cloud Tech helped the customer think through the difference between an outbound IP pool and a dedicated outbound IP assignment. For many AVD-related workloads, an outbound pool is enough. The organization can provide a short list of approved public IP addresses to third parties and use that list for allow-listing.
For stricter requirements, the design needs more care. For example, if finance applications, development tools, and general browser traffic must leave through different public IP addresses, simply adding more IPs to one NAT Gateway may not meet the business requirement. In those cases, the organization should review subnet separation, route tables, firewall policy, and egress architecture.
Azure Firewall and NAT Gateway Considerations
Azure Firewall and Azure NAT Gateway solve different problems. Azure Firewall is used for inspection, filtering, logging, and policy control. NAT Gateway is used for scalable outbound SNAT and predictable outbound connectivity. The customer needed both concepts explained clearly so the architecture would not mix them incorrectly.
BI Cloud Tech helped the customer review whether outbound traffic from AVD session hosts should go directly through NAT Gateway or be forced through Azure Firewall first. If security inspection and FQDN-based control are required, Azure Firewall may remain the right policy point. If scalable SNAT and outbound IP control are also required, the architecture needs to be reviewed so NAT Gateway is placed where it supports the actual egress path.
This was especially important in hub-and-spoke designs. If the AVD subnet sends internet-bound traffic to a firewall in a hub, placing NAT Gateway on the AVD spoke subnet may not produce the expected result. The route path, firewall subnet, and NAT placement must be reviewed together.
Microsoft Cloud Capabilities Used
The review included several Microsoft cloud capabilities that support Azure Virtual Desktop performance, network control, and operational visibility.
Azure Virtual Desktop was the primary workload being reviewed. RDP Shortpath was evaluated as a way to improve session responsiveness where UDP connectivity and network policy allowed it. Azure Virtual Network, subnets, Network Security Groups, and route tables were reviewed to understand how traffic moved between users, session hosts, Azure services, and the internet.
Azure Firewall was reviewed for controlled outbound access and inspection. Azure NAT Gateway was reviewed for deterministic outbound IP behavior and outbound SNAT scale. Public IP addresses and public IP prefixes were discussed as options for outbound IP pools. Azure Monitor and Log Analytics were considered for validating connectivity behavior and supporting ongoing troubleshooting.
What Improved
The customer gained a clearer understanding of how Azure Virtual Desktop latency should be investigated. Instead of focusing on only one possible cause, the team had a broader review model that included client location, protocol transport, Shortpath readiness, network security rules, firewall routing, and outbound access design.
The customer also gained practical guidance on RDP Shortpath. The review explained when Shortpath could help, what network conditions were required, and how to verify whether sessions were using UDP. This helped the team move from general awareness of Shortpath to an actionable readiness plan.
The outbound IP design also became clearer. The customer understood when NAT Gateway was appropriate, why explicit outbound connectivity mattered, and how to think about multiple outbound public IP addresses without assuming one-to-one IP assignment behavior.
Business Value
The main business value was a more reliable path toward better AVD user experience. Inconsistent latency affects productivity, support volume, and user confidence. By reviewing the network path and Shortpath readiness, the customer could make more informed decisions about which changes were likely to improve responsiveness.
The review also supported better operational control. With a clearer outbound IP design, the organization could support third-party allow-listing requirements more confidently. This reduced confusion when vendors asked for source IPs and helped technical teams avoid relying on unpredictable outbound behavior.
The engagement also improved communication between infrastructure, security, and operations teams. AVD performance, firewall policy, routing, and NAT design often overlap. BI Cloud Tech helped frame these topics together so the customer could make decisions that supported both security and performance.
Why This Matters
Azure Virtual Desktop is often judged by end-user experience. Even when the platform is configured correctly, users may describe latency, delays, or disconnections as an application problem. In many cases, the underlying issue is a combination of network path, protocol fallback, routing, firewall policy, and endpoint conditions.
RDP Shortpath can help, but it should be reviewed carefully. It is not a replacement for good network architecture, correct region placement, adequate session host sizing, or proper monitoring. It is one part of a broader AVD performance strategy.
Outbound IP design also matters. As organizations connect cloud workloads to external services, vendors, APIs, and SaaS platforms, predictable egress becomes more important. NAT Gateway and Azure Firewall can both play important roles, but they need to be placed and configured according to the actual traffic path.
Recommended Next Step
Organizations using Azure Virtual Desktop should consider an AVD network and latency review when users report inconsistent responsiveness, when UDP transport is blocked or uncertain, or when remote access paths vary across locations.
A review is also useful when the organization needs predictable outbound IP addresses for partner allow-listing or when one outbound IP address is not enough. In those cases, the design should include NAT Gateway, Azure Firewall, route tables, subnet boundaries, and monitoring together rather than treating each component separately.
BI Cloud Tech can help review Azure Virtual Desktop latency, RDP Shortpath readiness, and outbound IP architecture so the customer can improve user experience while maintaining secure and controlled networking and connectivity operations. For organizations that need ongoing support after the review, Azure Operations can help maintain visibility and operational follow-through. To discuss an AVD latency or outbound IP design project, Book a Call with BI Cloud Tech.