Azure Private Link Gets Direct Connect

Azure Direct Connect for Private Link Service it removes the mandatory Standard Load Balancer from the Private Link path entirely. Services can now be exposed directly from a backend Network Interface (NIC). That's a bigger deal than the feature announcement makes it sound.

Why the Load Balancer Was There in the First Place

Private Link Service was designed to project a private service from one virtual network into another: across tenant boundaries, across subscriptions, even across overlapping address spaces. The Standard Load Balancer acted as the mandatory frontend: Private Link needed a stable entry point to perform traffic steering and Source NAT (SNAT).

SNAT is the key mechanism that makes Private Link work across overlapping networks. When two networks share the same IP range (say, both use 10.0.0.0/16), Azure rewrites the source address so traffic can flow without routing conflicts. The load balancer was the anchor for that process.

The problem is that for many workloads (especially smaller services, legacy apps, or SaaS platforms exposing individual tenant endpoints) the load balancer added real cost and complexity without providing meaningful value. You were paying for a component whose only job was to make Private Link technically possible.

What Direct Connect Actually Changes

With Direct Connect enabled, Azure's Software Defined Networking (SDN) layer injects traffic directly into the backend NIC. The NAT still happens. That's still how Azure solves the overlapping address problem. But it now happens at the NIC level rather than requiring an intermediate load balancer.

One thing worth understanding clearly: Private Link performs destination-side NAT on the provider side. The NAT IP address is what your backend service actually sees as the source of incoming packets — not the consumer's real IP. If your application needs the original consumer IP (for logging, rate limiting, or auditing), you can enable TCP Proxy v2 on the Private Link Service. That adds a proxy protocol header carrying both the consumer's source IP and the Private Endpoint's link identifier, which your service can parse. Just make sure your application is configured to handle that header before enabling it — mismatched configuration causes request failures.

❌ Traditional Private Link Path

Consumer VNet

↓

Private Endpoint

↓

Standard Load Balancer

↓

Backend NIC

↓

Service

✅ Direct Connect Path

Consumer VNet

↓

Private Endpoint

↓

Backend NIC (direct)

↓

Service

Key specs Direct Connect supports up to 10 Gbps throughput per static IP configuration and requires at least two static IP configurations (in multiples of two) for high availability. You can assign up to 8 NAT IP addresses per Private Link Service — each additional NAT IP expands the port pool available for TCP connections, which is how you scale throughput under heavy load.

Where This Actually Matters: Two Real Scenarios

Scenario 1: The Overlapping Network Problem

This is the one that comes up constantly in enterprise work: two networks that need to communicate privately, but both use the same IP address space. VNet peering won't work. You can't route between them normally. The traditional workarounds (NAT appliances, VPN hairpins, renumbering one side) are all painful.

Private Link was already the cleanest answer to this problem because of SNAT. Direct Connect makes it even cleaner by removing the load balancer from the equation:

VNet A
10.0.0.0/16

⇄

VNet B
10.0.0.0/16

Azure rewrites the source address transparently so both sides can communicate without knowing about the overlap. This is especially useful in enterprise M&A scenarios, multi-tenant SaaS platforms, and partner integrations where you have no control over the other side's address space.

With Direct Connect Traffic flows from Private Endpoint → Backend NIC. No load balancer to provision, no frontend IP to manage, no extra cost tier to justify.

Scenario 2: Application Gateway Integration

Application Gateway can integrate with Private Link Service, which is a useful pattern for exposing web applications privately across tenant boundaries. But historically, this required a Standard Load Balancer sitting in front of the backend, even when Application Gateway itself was already handling traffic distribution.

Direct Connect removes that requirement. With a static private IP destination configured on the Private Link Service, Application Gateway connects directly to the backend resource. The architecture stays private end-to-end, and you've eliminated a component that wasn't adding value in that topology.

Note on static IPs Direct Connect requires a static private IP destination. Dynamic IP assignment is not supported in this mode. Plan your IP allocation before deployment.

Implementation Checklist

Before you deploy Direct Connect with Private Link Service, verify these requirements are met:

• Static IP configuration: Define a static private destination IP for the service. Dynamic is not supported.
• High availability: Minimum of two static IP configurations required, in multiples of two.
• Subnet policy: Disable the privateLinkServiceNetworkPolicies setting on the subnet before deploying.
• Feature registration: Register the preview feature flag on your subscription before use.

The feature registration command:

az feature register --namespace Microsoft.Network --name AllowPrivateLinkserviceUDR

Verify registration status:

az feature show --namespace Microsoft.Network --name AllowPrivateLinkserviceUDR --query properties.state

Limitations Worth Knowing Before You Deploy

The docs are clear on these, and they matter at design time rather than after the fact:

• IPv4 only. IPv6 is not supported on Private Link Service, with or without Direct Connect.
• TCP and UDP only. Other IP protocols are not supported.
• NIC-based backend pools only. If your Standard Load Balancer backend pool is configured by IP address rather than by NIC, Private Link Service will not work. Direct Connect also targets NIC directly, so this constraint carries over.
• 5-minute idle timeout. Private Link Service drops idle connections at approximately 300 seconds. Any application connecting through it should use TCP keepalives set below that threshold to avoid unexpected disconnects.
• No Basic Load Balancer support. Standard Load Balancer is required for the traditional path. Direct Connect bypasses the load balancer entirely, but your overall setup still needs to meet Standard tier requirements.

Heads up on TCP Proxy v2 If you enable TCP Proxy v2 on a Private Link Service, it activates across all load balancers and backend VMs sharing that configuration. If multiple Private Link Services share the same load balancer or backend pool, all of them need to be configured consistently — otherwise health probes will fail.

My Take

This is the kind of change that doesn't make headlines but quietly makes life better for a lot of architects. The Standard Load Balancer requirement for Private Link was never a design philosophy. It was an implementation constraint. Removing it is the right move.

The two scenarios where I'd reach for this immediately: overlapping-IP environments where renumbering isn't an option, and multi-tenant SaaS platforms where per-tenant load balancers were adding up on the monthly bill. For both of those, Direct Connect is a genuine architectural simplification, not just a cost tweak.

It's still public preview, so I wouldn't run critical production workloads through it just yet. But it's absolutely worth spinning up the lab, understanding the static IP requirements, and getting ahead of the feature before it reaches GA.

References
Azure Private Link Service - Microsoft Docs