Optimising AVD Networking: Outbound Paths, NVAs, and Private Endpoints

In Summary - TL;DR

• Outbound traffic through NVAs or Azure Firewall can add latency, throughput limits, and even session drops in AVD.
• From 31 March 2026, default outbound access is being retired, meaning you must configure explicit egress.
• Options include NAT Gateway, public IPs, or NVAs that all have different trade-offs in cost, scalability, and complexity.
• Private Endpoints are essential for FSLogix profiles, keeping data off the public internet and ensuring better performance.
• For AVD specifically, always prioritise reliability, user experience, and security over cost savings.

Introduction

Slow Azure Virtual Desktop (AVD) sessions aren't always caused by the host. Sometimes, the real bottleneck is the network architecture.

Routing outbound traffic through Network Virtual Appliances (NVAs) or Azure Firewall can add latency and drag down performance. It is a common design choice albeit one that can quietly undermine the user experience.

With Microsoft’s default outbound access changes arriving on 31st March 2026, getting this right has never been more important.

In this post, I’ll share how outbound routing impacts AVD in the real world, why NVAs aren’t always the answer, and how Private Endpoints can secure traffic without slowing it down.

Let's get into it! 🏁

Why NVAs Can Slow AVD Down

Network Virtual Appliances (NVAs) like Azure Firewall or third-party firewalls (e.g. WatchGuard Firebox Small) are a common way to secure Azure environments. They inspect and filter traffic, provide advanced rule sets and can meet strict compliance needs.

But for AVD, routing outbound traffic through an NVA can come with noticeable performance drops. Even well-sized appliances can introduce latency, throughput bottlenecks and in some cases, dropped connections.

Key Performance Concerns:

• Added Latency - With traffic passing through an extra hop for inspection before leaving the Azure network, round-trip time is increased.
• Throughput Limitations - NVAs have hardware and SKU limits; once reached, they can throttle or drop traffic under heavy load.
• Single Points of Failures - Without high-availability or load-balancing (looking at you WatchGuard), a failed appliance can take down outbound connectivity entirely.
  • I will highlight why this matters even more, later in the blog, so stick around.
• Scaling Behaviours - Azure Firewall scale-ins can cause active sessions to be disconnected, which can disrupt AVD users' mid-session.
• Operational Complexity - Additional configuration, patching and monitoring requirements for the appliance and any associated infrastructure.

Private Endpoints Explained

Private Endpoints let you connect Azure resources over a private IP address inside your virtual network. This keeps traffic off the public internet and flowing entirely over the Microsoft backbone.

Unlike Service Endpoints, which extend an entire Azure service into your virtual network, Private Endpoints are more precise. They assign a single resource (like a specific Storage Account) a private IP address in your VNet.

Why This Matters for AVD

For Azure Virtual Desktop, Private Endpoints are the perfect way to secure outbound traffic to services like Azure Storage. A common example, one which I will use for this blog post, is connecting to FSLogix profile containers.

Connecting the AVD Session Hosts directly to the storage account over the private link, avoiding public endpoints entirely is a great way to improve security, maintain performance and keep your data within your network!

Key Points to Know

• Granular Scope: Targeting one resource not an entire service.
• Private IP Allocation: Integrating a resource directly into your VNet.
• Security Policies: Network policies can be applied at setup, meaning your secure from the off.
• Traffic Isolation: Your data is private, within your VNet. No internet traversal reducing the external attack surface.

It's Always DNS

Any IT Pro who has spent time troubleshooting a network, whether on-premises or in Azure, 9 times out of 10, it's DNS.

In a real-world case, I had to add a Conditional Forwarder on an "on-premises" domain controller hosted in Azure. The fix was to point those storage account queries directly to Azure’s DNS service at 168.63.129.16. Once the conditional forwarder was in place, the name resolved to the private IP of the endpoint, traffic stayed on the private network path, and the application worked as intended.

Cost Considerations

Private Endpoints are not free, but the cost is low and comes from the resource itself and the data transfer.

Using the Azure calculator, I built a rough estimate. The service itself has no charge, but the calculator asks for runtime hours. Since a Private Endpoint is always active once created, I’ve used 730 hours to cover a full month.

Even with a heavy load of 100 GB inbound and 100 GB outbound, the total comes to around £7 per month to keep your profile data private.

Validating Your Private Endpoint

It's really easy to validate that your private endpoint is working. I've included some images below which show you the commands to run and the expected result.

The first step is to check DNS resolution. Run the following command to confirm that your storage account name resolves to a private IP:

nslookup storageaccountname.file.core.windows.net

If the private endpoint is working, you should see an IP address from your virtual network instead of the public Azure address.

Next, confirm network connectivity to the storage account over port 443 by running:

Test-NetConnection storageaccountname.file.core.windows.net -Port 443

This ensures that your virtual machines can successfully connect to the storage account using the private endpoint.

Default Outbound Access - What's Changing

Microsoft is retiring default outbound internet access for new VNets and subnets after March 31st 2026. This change removes the automatic ability for resources without explicit outbound configuration to reach the internet.

Why Is This Changing?

The current default outbound model relies on IPs that can change without notice. This isn't aligned to security, compliance or best practice and by removing this feature; Microsoft are enforcing explicit outbound connectivity that is secure, compliant and shifts some responsibility to the customer.

What Is Changing?

• Before: Resources without a public IP or outbound configuration could reach the internet using a hidden Azure-provided IP.
• After 31st March 2026: This automatic fallback is removed. If you need outbound connectivity, you must configure it explicitly.

What Do Microsoft Recommend?

Microsoft recommends using the NAT Gateway service for outbound internet access, as it provides scalability, resiliency and static IP addresses.

However, this isn't the only outbound access option that customers and organisations have access to.

The main three are:

• NAT Gateway
  • Provides scalable, resilient outbound connectivity with predictable IPs.
  • Microsoft’s preferred solution for most production workloads.
  • NAT Gateways are priced for the service and the data processed. A quick UK South estimate is below.

• Public IP on the Resource
  • Assigns a public IP directly to a VM or resource.
  • Simple, but exposes resources directly to the internet and does not scale well.
  • A Standard Public IP address will cost approx. £4 per month.
• Network Virtual Appliance (NVA) such as Azure Firewall
  • Provides outbound control with advanced inspection, logging, and security features.
  • Scales for enterprise needs, and avoids single points of failure if deployed in HA.
  • Other vendor NVAs are available i.e. WatchGuard Firebox Small. Prices for Azure and vendor offerings differ based on workload, size and licensing.

What I Recommend

This one is difficult for me, which usually results in a vague answer. But the right choice depends heavily on the use case and the organisation's goals.

• Mixed workloads (App Services and VMs): A NAT Gateway often provides the best balance. It avoids the hassle of changing outbound IPs when scaling App Service plans and offers a clean, predictable egress path.
• Small, lightweight deployments: For a single VM or low-traffic workload that only needs outbound connectivity occasionally, a static public IP on the NIC with NSG rules can be a cheaper and simpler option.

Since this is primarily an AVD-focussed blog, my recommendation needs to be framed around AVD.

Normally, I’d recommend routing AVD traffic over the Microsoft backbone rather than pushing everything through a single NVA. With default outbound access being retired, that option disappears, so we’re left with NAT Gateway or NVAs.

Both can work. Some organisations will prefer Azure Firewall, WatchGuard, or other third-party NVAs, while others will lean toward NAT Gateway for its simplicity. The deciding factors are budget, operational familiarity, and the level of control required.

For AVD scenarios, my advice is simple: Choose a solution that can sustain high throughput, deliver high availability, and won’t introduce performance bottlenecks.

Final Thoughts

Outbound connectivity in Azure is not a one size fits all decision. Whether your business chooses a NAT Gateway, an NVA or a simpler option for smaller workloads, the key is aligning with your operational model, budget and performance requirements.

One area often overlooked is standardisation. With default outbound access being retired, now is the perfect time to define a clear model for your organisation. Classify which workloads should use which solution, document the reasoning, and share this with your support teams and the wider business.

Standardisation not only reduces confusion but helps justify decisions to internal stakeholders and customers.

For AVD in particular, the choice should always be driven by reliability, user experience, and security. Don’t compromise those for cost.