All Azure Technologies @ one Place

Understanding the Role of the Load Balancer

The Private Link Service was established to facilitate a private connection between different virtual networks, overcoming tenant boundaries and subscriptions, including those with overlapping address spaces. The Standard Load Balancer served as a necessary frontend, providing a consistent entry point for traffic steering and Source NAT (SNAT).

SNAT plays a crucial role in enabling Private Link to function across overlapping networks. If two networks utilise the same IP address range (for example, both networks using 10.0.0.0/16), Azure alters the source address to ensure seamless traffic flow without routing issues. The load balancer was pivotal in this process.

However, for numerous workloads, particularly smaller services, legacy applications, or SaaS platforms that expose individual tenant endpoints, the load balancer contributed unnecessary costs and complexity without adding substantial value. Users often found themselves paying for an element that merely made Private Link feasible in a technical sense.

What Changes with Direct Connect

When Direct Connect is activated, Azure’s Software Defined Networking (SDN) layer directly channels traffic into the backend Network Interface Card (NIC). While NAT still processes this traffic to manage overlapping addresses, it now occurs at the NIC level, eliminating the need for an intermediary load balancer.

A key point to grasp is that Private Link uses destination-side NAT on the provider’s end. The NAT IP address is what your backend service perceives as the source of incoming packets, rather than the consumer’s actual IP address. If your application requires the original consumer IP for purposes such as logging, rate limiting, or auditing, you can enable TCP Proxy v2 on the Private Link Service. This feature adds a proxy protocol header containing both the consumer’s source IP and the Private Endpoint’s link identifier, which your service can decode. Ensure your application is set up to handle this header before activating it, as misconfigured settings can lead to request failures.

Key Specifications: Direct Connect supports up to 10 Gbps throughput per static IP configuration and requires a minimum of two static IP configurations (in even numbers) for high availability. You can allocate up to 8 NAT IP addresses per Private Link Service. Each additional NAT IP enhances the available port pool for TCP connections, thereby scaling throughput during high demand.

Real-Life Scenarios Where This Matters

Implementation Checklist

Prior to deploying Direct Connect with the Private Link Service, ensure the following requirements are satisfied:

• Static IP Configuration: Establish a static private destination IP for the service, as dynamic options are not feasible.
• High Availability: At least two static IP configurations are necessary, in even multiples.
• Subnet Policy: Disable the privateLinkServiceNetworkPolicies setting on the subnet before proceeding with the deployment.
• Feature Registration: Register the preview feature flag on your subscription prior to use.

The feature registration command is:

az feature register –namespace Microsoft.Network –name AllowPrivateLinkserviceUDR

To verify the registration status, use the command:

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

Essential Limitations to Consider Before Deployment

These limitations are well-documented and should be acknowledged during the design phase rather than addressed later:

• IPv4 Only: Private Link Service does not support IPv6, whether utilizing Direct Connect or not.
• TCP and UDP Only: Other IP protocols are unsupported.
• NIC-Based Backend Pools Only: If your Standard Load Balancer backend pool is set up using IP addresses instead of NICs, the Private Link Service will be incompatible. Direct Connect, targeting NICs directly, carries this constraint as well.
• 5-Minute Idle Timeout: Private Link Service disconnects idle connections after approximately 300 seconds. Applications using this service should implement TCP keepalives set below this threshold to avoid unexpected disconnections.
• No Basic Load Balancer Support: A Standard Load Balancer is necessary for the traditional path. While Direct Connect bypasses the load balancer entirely, your overall setup must still meet Standard tier requirements.

A Note on TCP Proxy v2: If TCP Proxy v2 is enabled on a Private Link Service, it will be activated across all load balancers and backend VMs sharing that configuration. If multiple Private Link Services share the same load balancer or backend pool, ensure consistent configuration for all, as discrepancies can lead to health probe failures.

Conclusion

This evolution may not attract headlines but it significantly enhances the experience for many architects. The requirement for a Standard Load Balancer in Private Link was more of a constraint than a deliberate design choice. Removing it is a step in the right direction.

In particular, I would apply this change immediately in overlapping-IP situations where renumbering isn’t feasible, and on multi-tenant SaaS platforms where individual tenant load balancers add up in cost. For both instances, Direct Connect represents a genuine architectural simplification rather than merely a cost adjustment.

Although this feature is still in public preview, I wouldn’t recommend running critical production workloads through it just yet. However, it’s certainly worthwhile to set up a lab, understand the static IP requirements, and familiarize yourself with the feature before it reaches general availability.