Azure Private Link Service NAT — Architecture, Management, and Direct Connect
1. Executive Summary
Azure Private Link Service enables service providers to expose their applications over private endpoints, allowing consumers in separate virtual networks, subscriptions, or Azure Active Directory tenants to access services without traversing the public internet. A critical function of this service is Network Address Translation (NAT), which resolves potential IP address space conflicts between consumer and provider networks while maintaining strict network isolation.
This whitepaper provides a comprehensive technical analysis of how Azure Private Link Service performs NAT, how this NAT is managed and scaled, and how the newly released Private Link Service Direct Connect (public preview) extends these NAT capabilities to scenarios that do not require a load balancer.
The intended audience includes cloud architects, network engineers, and infrastructure teams who need to understand the NAT mechanics underpinning Private Link Service deployments, particularly in multi-tenant, SaaS, or cross-organisational environments where overlapping IP address spaces are common.
2. Overview of Azure Private Link Service
2.1 Architecture Fundamentals
Azure Private Link Service (PLS) allows a service provider to place their application behind a Standard Load Balancer and expose it to consumers via a Private Endpoint. The consumer creates a Private Endpoint in their own virtual network, which receives a NIC with a private IP address. When the consumer sends traffic to this Private Endpoint IP, the Azure Software-Defined Networking (SDN) fabric routes the traffic over the Azure backbone to the provider's Private Link Service, where NAT is applied before the traffic reaches the load balancer and ultimately the backend virtual machines.
The key architectural components are:
- The consumer's Private Endpoint (a NIC in the consumer's VNet)
- The Azure backbone network (encrypted transport layer)
- The Private Link Service resource (which holds the NAT configuration)
- The NAT IP subnet (where source NAT IPs are allocated)
- The Standard Load Balancer (which receives the NAT-translated traffic)
- The backend pool of virtual machines that process the requests
2.2 Standard PLS NAT Architecture
In a standard Private Link Service deployment, consumer traffic flows from the Private Endpoint through the NAT layer to the backend virtual machines. The PLS resource sits between the Azure backbone and the Standard Load Balancer, performing SNAT on every inbound connection.
Figure 1: Azure Private Link Service — Standard NAT Architecture
3. How NAT Works in Private Link Service
3.1 Source NAT (SNAT) Mechanics
When a consumer application sends a packet to the Private Endpoint IP address, the Azure SDN fabric intercepts the packet and routes it across the Azure backbone to the provider's virtual network. At the provider side, the Private Link Service performs Source Network Address Translation (SNAT). This means the original source IP address of the consumer is replaced with a NAT IP address allocated from the provider's designated NAT subnet. Simultaneously, the destination IP is rewritten to the load balancer's frontend IP address.
This dual translation is critical because the consumer and provider may use overlapping RFC 1918 private address spaces. For example, both parties might use the 10.0.0.0/8 range. Without NAT, routing would be ambiguous and packets could not be properly delivered. The NAT layer eliminates this problem entirely by ensuring that from the provider's perspective, all traffic appears to originate from a known, local NAT IP pool.
3.2 Packet Header Transformation
During the NAT process, the source IP is rewritten from the consumer's private IP to a NAT IP in the provider's subnet, while the source port is also remapped to avoid collisions. The destination IP changes from the Private Endpoint NIC IP to the load balancer's frontend IP.
Figure 2: NAT Translation Detail — Packet Header Transformation
3.3 Why NAT Is Essential
The NAT mechanism in Private Link Service serves several critical purposes:
- IP address space isolation — consumer and provider networks can use identical or overlapping address ranges without conflict.
- Multi-tenant safety — all consumer traffic is rewritten to appear as local traffic from the NAT IP pool, so backend applications do not need to accommodate diverse consumer address spaces.
- Consumer identity protection — the original consumer IP address is not exposed to the backend unless TCP Proxy Protocol v2 is explicitly enabled.
3.4 TCP Proxy Protocol v2
In scenarios where the provider's application requires knowledge of the original consumer source IP, Azure Private Link Service supports TCP Proxy Protocol v2. When enabled, a proxy protocol header is prepended to the TCP payload on the initial connection. This header contains the original consumer source IP address and the LinkID of the Private Endpoint, allowing the backend application to identify both the consumer's network origin and the specific Private Endpoint connection.
Important: Enabling TCP Proxy v2 on one PLS resource that shares a load balancer or backend pool requires it to be enabled on all PLS resources sharing those same components, otherwise health probes will fail.
4. Managing NAT in Private Link Service
4.1 NAT IP Configuration
When creating a Private Link Service, you must designate a subnet for NAT IP addresses. Azure allocates private IP addresses from this subnet to serve as the source addresses for all SNAT-translated consumer traffic. The service provider configures one or more NAT IP configurations on the PLS resource, with the first being designated as the primary NAT IP.
Microsoft recommends having at least eight NAT IP addresses available in the NAT subnet to provide adequate capacity for scaling.
4.2 Port Allocation and Capacity
Each NAT IP address provides 64,000 TCP ports (approximately 64k connections) per virtual machine in the backend pool behind the Standard Load Balancer. The total connection capacity of a Private Link Service is therefore a product of the number of NAT IPs, the number of backend VMs, and the 64k port allocation per NAT IP per VM.
A Private Link Service supports up to eight NAT IP addresses, and a Standard Load Balancer can host up to eight Private Link Services. This means a single load balancer deployment can theoretically serve a very large number of concurrent connections when fully scaled.
Figure 3: NAT IP Scaling Model — Port Allocation and Capacity Planning
4.3 Scaling Strategies
Service providers have several strategies for scaling NAT capacity:
- Add additional NAT IP addresses to the PLS resource, up to the maximum of eight. Each additional NAT IP multiplies the available port inventory by providing another 64k ports per backend VM.
- Add more virtual machines to the Standard Load Balancer's backend pool, which increases the total port capacity across all configured NAT IPs.
- Create additional Private Link Service resources on the same Standard Load Balancer, using different frontend IP configurations, up to a maximum of eight PLS resources per load balancer.
At least one NAT IP address must always remain configured on a PLS resource. Azure will prevent deletion of the last remaining NAT IP. NAT IP addresses can be added dynamically without service interruption.
4.4 Connection Lifecycle and Idle Timeout
Private Link Service has an idle timeout of approximately five minutes (300 seconds). Connections that remain idle beyond this threshold are silently dropped, and their NAT port allocations are reclaimed. To prevent unexpected disconnections, applications connecting through Private Link Service should implement TCP keepalives with an interval shorter than 300 seconds.
4.5 Subnet and NSG Considerations
The NAT subnet does not require a dedicated subnet; any subnet within the service provider's virtual network can be used. However, it is recommended to avoid applying Network Security Groups (NSGs) to the NAT subnet, or to ensure that NSG rules explicitly allow the required traffic patterns. If NSGs are misconfigured on either the NAT subnet or backend subnet, new connections may fail silently.
5. Private Link Service Direct Connect
5.1 Overview and Motivation
Private Link Service Direct Connect is a new capability currently in public preview that addresses a longstanding limitation of standard PLS: the requirement for a Standard Load Balancer. In many scenarios, service providers need the SNAT/DNAT capabilities of Private Link Service but have backends that do not naturally sit behind a load balancer. Examples include:
- Azure Container Instances
- API Management instances
- Virtual network appliances
- Databases with static IP requirements
- On-premises resources reachable via VNet peering or ExpressRoute
Direct Connect allows the PLS resource to route traffic directly to a specified, statically allocated private IP address within the provider's virtual network, bypassing the load balancer entirely. This simplifies the architecture, reduces cost, and enables new connectivity patterns that were previously difficult or impossible to achieve with standard PLS.
5.2 Direct Connect NAT Architecture
The consumer experience remains identical: a Private Endpoint in the consumer's VNet connects over the Azure backbone to the PLS resource. However, on the provider side, the PLS is configured with a destination_ip_address parameter instead of referencing a load balancer frontend. The NAT mechanism operates identically to standard PLS — consumer source IPs are translated to NAT IPs from the provider's NAT subnet. The critical difference is that after NAT, traffic is routed directly to the specified destination IP rather than through a load balancer.
Figure 4: Private Link Service Direct Connect — NAT Without Load Balancer
5.3 NAT in Direct Connect
The SNAT mechanism in Direct Connect is fundamentally the same as in standard PLS. Consumer traffic arriving at the PLS has its source IP rewritten to a NAT IP from the configured NAT subnet, and the destination is set to the statically defined destination IP address. The same port allocation model applies, with each NAT IP providing approximately 64k ports for TCP connections.
Direct Connect requires a minimum of two NAT IP configurations (compared to one for standard PLS). This is a platform requirement for the preview feature.
5.4 Configuration and Deployment
Direct Connect PLS resources cannot be created via the Azure Portal in general availability yet; they must be deployed using Azure PowerShell, Azure CLI, or Terraform. The subscription must have the feature flag Microsoft.Network/AllowPrivateLinkserviceUDR registered before deployment.
The Terraform configuration uses the same azurerm_private_link_service resource but omits the
load_balancer_frontend_ip_configuration_ids parameter and instead specifies the
destination_ip_address.
5.5 Limitations and Considerations
As a public preview feature, Direct Connect has several important limitations:
- Maximum bandwidth of 10 Gbps per instance
- Destination IP must be statically allocated; dynamic IP allocation is not supported
- Source Private Endpoint, PLS resource, and client VM must all be in the same region (expected to be lifted at GA)
- Available in limited regions: North Central US, East US 2, Central US, South Central US, West US, West US 2, West US 3, Southeast Asia, Australia East, and Spain Central
- Migration from existing standard PLS to Direct Connect is not supported; a new PLS resource must be created
6. Comparison: Standard PLS vs Direct Connect
| Feature | Standard PLS | Direct Connect (Preview) |
|---|---|---|
| Load Balancer | Required (Standard SKU) | Not required |
| SNAT Applied | Yes — NAT IP pool | Yes — NAT IP pool |
| Min NAT IPs | 1 | 2 |
| Max NAT IPs | 8 | 8 |
| Port Allocation | 64k per NAT IP per VM | 64k per NAT IP |
| Destination Target | LB Frontend IP | Any private routable IP |
| Backend Types | NIC-based LB pool only | ACI, VM, NVA, APIM, on-prem |
| TCP Proxy v2 | Supported | Not yet documented |
| Max Bandwidth | LB SKU limits | 10 Gbps per instance |
| Portal Support | Full | Preview link only |
| Cross-Region | Supported | Same region only (preview) |
| Feature Flag | None required | AllowPrivateLinkserviceUDR |
7. Use Cases for Private Link NAT
7.1 Multi-Tenant SaaS Platforms
SaaS providers serving multiple tenants benefit significantly from Private Link NAT. Each tenant connects via their own Private Endpoint, and all traffic is SNAT-translated to the provider's NAT IP pool. This means tenants with overlapping IP address spaces can all connect without conflict. TCP Proxy Protocol v2 can be used to identify the originating tenant via the LinkID in the proxy header.
7.2 Merger and Acquisition Scenarios
When organisations merge, overlapping RFC 1918 address spaces are a common challenge. Private Link Service provides a decentralised NAT solution that allows systems in both heritage organisations to communicate without a centralised NAT appliance. Direct Connect extends this further by enabling connectivity to on-premises systems reachable via VNet peering or ExpressRoute, without requiring a load balancer.
7.3 Managed Service Connectivity
Direct Connect is particularly useful for connecting managed services (such as Microsoft Fabric, Azure Data Factory, or Azure Machine Learning) to private backends. These managed services often create Managed Private Endpoints in Microsoft's managed virtual networks. Direct Connect allows these endpoints to reach private resources without the overhead of deploying and managing a load balancer.
8. Best Practices and Recommendations
NAT Subnet Sizing
Ensure the NAT subnet has sufficient IP address capacity. Microsoft recommends at least eight available IPs. For high-scale deployments, use a /24 or larger subnet to accommodate future NAT IP additions without subnet expansion.
TCP Keepalives
Configure TCP keepalives on all applications connecting through Private Link Service with an interval shorter than 300 seconds (the idle timeout). This prevents unexpected connection drops and NAT port reclamation.
Monitor SNAT Port Usage
Use Azure Monitor metrics to track SNAT port utilisation across NAT IPs. If port utilisation approaches capacity, add additional NAT IPs or backend VMs before connections begin failing.
NSG Configuration
Leave the NAT subnet without NSGs where possible. If NSGs are required, ensure inbound and outbound rules permit traffic between the NAT subnet and backend subnet. For the backend subnet, allow traffic from the load balancer frontend IP (standard PLS) or from the NAT subnet (Direct Connect).
Direct Connect Readiness
If evaluating Direct Connect for production use, note that it is in public preview with regional and bandwidth limitations. Plan for migration by deploying new PLS resources rather than attempting to convert existing ones. Ensure the destination IP is statically allocated and the feature flag is registered on the subscription.
9. Conclusion
Azure Private Link Service's NAT mechanism is a fundamental component that enables secure, private, cross-network connectivity while eliminating IP address space conflicts. The SNAT translation, managed through a dedicated NAT IP pool, provides scalable capacity (up to 8 NAT IPs × 64k ports × N backend VMs) with clear management primitives for scaling, monitoring, and lifecycle management.
Private Link Service Direct Connect extends these NAT capabilities to new scenarios by removing the load balancer requirement, enabling direct IP routing to any privately routable destination. While currently in public preview with some limitations, Direct Connect represents a significant evolution in the Private Link platform, opening up use cases around managed service connectivity, legacy application integration, and decentralised NAT for overlapping address spaces.
Organisations deploying Private Link Service should carefully plan their NAT subnet sizing, monitor port utilisation, and implement TCP keepalives to ensure reliable, high-performance connectivity. As Direct Connect moves toward general availability, it will become an increasingly important tool for cloud architects seeking simplified, cost-effective private connectivity patterns.
10. References
- Microsoft Learn — What is Azure Private Link Service?
- Microsoft Learn — Configure Private Link Service Direct Connect
- Microsoft Learn — Azure Private Link FAQ
- Microsoft Learn — What is Azure Private Link?
- Microsoft Learn — SNAT for Outbound Connections (Azure Load Balancer)