7.4 Azure Private Link Service for Multi-Tenant Solutions

Azure Private Link Service for Multi-Tenant Solutions

While Private Endpoints are widely known for securing Azure first-party PaaS services, Azure Private Link Service (PLS) extends this exact same software-defined architecture to your own custom applications, third-party Independent Software Vendor (ISV) solutions, and multi-tenant Software-as-a-Service (SaaS) offerings.

By creating a Private Link Service in a provider virtual network, you enable consumers in different virtual networks, different Azure subscriptions, and even different Microsoft Entra ID tenants to connect directly to your application using a standard Azure Private Endpoint. Connectivity is private, secure, and operates entirely over the Microsoft global SDN fabric.

1. Provider vs. Consumer Architecture & Overlapping IP Elimination

Traditional multi-VNet connectivity architectures—such as Virtual Network Peering or cross-tenant VPN tunnels—require complex IP address coordination to avoid address space collisions. If both the service provider and the consumer use 10.0.0.0/16, VNet peering is impossible.

Azure Private Link Service completely eliminates overlapping IP address conflicts by decoupling provider and consumer network address spaces through Layer 4 Source Network Address Translation (SNAT).

+-----------------------------------------------------------------------------+
|                   AZURE PRIVATE LINK SERVICE ARCHITECTURE                   |
|                                                                             |
|   CONSUMER VNET (10.0.0.0/16)                 PROVIDER VNET (10.0.0.0/16)   |
|   (Notice Overlapping IP Space!)              (Same IP range supported!)    |
|   +-------------------------------------+     +-------------------------+   |
|   | Subnet-Client (10.0.1.0/24)         |     | PLS NAT Subnet          |   |
|   | [Client VM: 10.0.1.10]              |     | (10.0.50.0/24)          |   |
|   |       |                             |     | [NAT IP: 10.0.50.4]     |   |
|   |       v                             |     +-------------------------+   |
|   | Subnet-Endpoints (10.0.2.0/24)      |                  |                |
|   | [Private Endpoint: 10.0.2.15]       |                  v                |
|   +-------------------------------------+     +-------------------------+   |
|                      |                        | Standard ILB Frontend   |   |
|                      |                        | [Private IP: 10.0.10.5] |   |
|                      v                        +-------------------------+   |
|            =====================                           |                |
|            Azure SDN Fabric Mesh                           v                |
|            =====================              +-------------------------+   |
|                      |                        | Backend Pool Workloads  |   |
|                      +----------------------->| [VMSS / AKS Pods]       |   |
|                                               +-------------------------+   |
+-----------------------------------------------------------------------------+

Core Benefits for SaaS Providers and Enterprises:

• No IP Address Overlap Constraints: Consumers and providers can use the exact same CIDR blocks (e.g., 10.0.0.0/16 or 192.168.0.0/16) without conflicts.
• Unidirectional Consumer-to-Provider Exposure: Consumers can access only the specific service exposed behind the load balancer frontend; consumers gain zero access to any other VMs or subnets in the provider VNet.
• Simplified Routing: No User-Defined Routes (UDRs), Virtual Network Gateways, or BGP peering sessions are required.

2. Standard ILB Integration, Dedicated NAT Subnet & Sizing

Creating an Azure Private Link Service requires specific prerequisite network configurations in the service provider's virtual network.

1. Standard Internal Load Balancer (ILB) Requirement

A Private Link Service must attach to the frontend IP configuration of a Standard SKU Internal Load Balancer.

• Basic SKU Load Balancers are not supported.
• Public Load Balancers are not supported.
• The ILB frontend must use a private IP from a provider subnet.

2. Dedicated NAT IP Subnet Configuration

When incoming packets from a consumer's Private Endpoint arrive at the provider network, the Private Link Service performs Source NAT (SNAT), replacing the consumer's private source IP with a NAT IP address drawn from the provider's dedicated NAT subnet.

+-----------------------------------------------------------------------------+
|                     NAT SUBNET SIZING AND SCALE RULES                       |
|                                                                             |
|   Metric                             Value / Rule                           |
|   --------------------------------   ------------------------------------   |
|   Concurrent TCP Ports per NAT IP    64,000 concurrent connections          |
|   Minimum Recommended Subnet Size    /27 (provides 8+ assignable IPs)       |
|   Enterprise Recommended Subnet Size /24 (allows massive dynamic scale)     |
|   Maximum NAT IPs per PLS            Up to 8 NAT IP configurations          |
|   Network Policies on NAT Subnet     Must disable PrivateLinkServiceNetwork-|
|                                      Policies if managing via legacy APIs   |
+-----------------------------------------------------------------------------+

Subnet Sizing and Scaling Guidance:

• Each configured NAT IP address provides 64,000 ephemeral TCP ports for concurrent connection tracking.
• If a SaaS provider expects 200,000 concurrent TCP sessions from multiple consumers, the PLS requires at least 4 active NAT IP addresses ($4 \times 64,000 = 256,000$ available connection states).
• Always allocate at least a /27 subnet (or /24 for high-growth SaaS) to ensure sufficient room for adding additional NAT IPs as workload demand scales without tearing down and re-provisioning infrastructure.

3. Subscription Allowlists, RBAC & Connection Approval Lifecycle

To control which customers or business units can connect to your Private Link Service, Azure provides granular access control models.

Access Control Settings

1. Role-Based Access Control (RBAC): If the consumer subscription is within the same Entra ID tenant or managed by the same organization, granting the consumer RBAC Read permissions on the Private Link Service resource allows them to create Private Endpoints with Auto-Approval.
2. Subscription Allowlist: For external, cross-tenant SaaS customers, the provider specifies allowed Azure Subscription IDs in the PLS access configuration.
   • Specific Subscriptions: Only explicitly listed Subscription IDs can request connections.
   • Wildcard Allowlist (*): Allows any Azure subscription to request a connection (useful for public marketplace SaaS offerings). Connections still require manual approval unless auto-approval subscriptions are defined.

+-----------------------------------------------------------------------------+
|                   PLS CONNECTION LIFECYCLE MANAGEMENT                       |
|                                                                             |
|   State            Description & Data Plane Status                          |
|   --------------   ------------------------------------------------------   |
|   Pending          Consumer requested connection; data plane BLOCKED.       |
|   Approved         Provider approved request; data plane ACTIVE & FLOWING.  |
|   Rejected         Provider denied request; data plane TERMINATED.          |
|   Disconnected     Connection severed by provider/consumer; session CLOSED. |
+-----------------------------------------------------------------------------+

Private Link Service Alias

When a Private Link Service is created, Azure generates a globally unique identifier called the Private Link Service Alias (e.g., pls-prod-eastus-01.8a7b6c5d-4e3f.eastus.azure.privatelinkservice).

• Consumers can create a Private Endpoint by supplying this Alias string instead of the underlying Azure Resource ID.
• This allows SaaS providers to keep their internal Azure Subscription IDs and Resource Group names completely confidential.

4. PROXY Protocol Version 2 (PPv2) & Client Identity Preservation

Because the Private Link Service translates the client's source IP address to a provider NAT IP address (Source NAT), backend application servers (VMs, NGINX reverse proxies, Envoy, IIS) only see the PLS NAT IP in incoming TCP headers.

The Source IP Visibility Problem

In multi-tenant SaaS environments, backend servers must know the original client IP address and tenant identity for:

• Security logging, SIEM auditing, and regulatory compliance.
• Rate limiting and DDoS protection per consumer.
• Tenant-specific request routing and customization.

+-----------------------------------------------------------------------------+
|                      PROXY PROTOCOL V2 HEADER INJECTION                     |
|                                                                             |
|   WITHOUT PROXY PROTOCOL V2:                                                |
|   [Consumer: 10.0.1.10] ---> [PLS NAT: 10.0.50.4] ---> [Backend App VM]    |
|   Backend sees Source IP = 10.0.50.4 (Client identity is LOST!)            |
|                                                                             |
|   WITH PROXY PROTOCOL V2 ENABLED ON PLS:                                    |
|   [Consumer: 10.0.1.10] ---> [PLS NAT: 10.0.50.4]                          |
|                                    |                                        |
|                                    v (Prepends binary PPv2 header)          |
|                              [Backend App VM / Reverse Proxy]               |
|                              - Extracts True Client IP: 10.0.1.10           |
|                              - Extracts Unique LinkID: 0x1A4F               |
+-----------------------------------------------------------------------------+

How PROXY Protocol v2 Operates:

1. Enabling PPv2: Set the enableProxyProtocol property to true on the Azure Private Link Service configuration.
2. Binary Header Prepending: Before forwarding the TCP handshake to the backend VM or container, the Azure load balancing fabric prepends a standardized PROXY Protocol Version 2 binary header to the payload.
3. Transmitted Metadata:
   • Original Source IP Address & Port: The consumer's actual private IP (e.g., 10.0.1.10:52410).
   • LinkID (Type-Length-Value / TLV vector): A unique 32-bit integer generated by Azure that represents the specific Private Endpoint connection.
4. Backend Server Configuration: Backend services (e.g., NGINX proxy_protocol directive, HAProxy, or custom application code) must be configured to parse and strip the PPv2 header to extract client metadata before processing standard HTTP/TCP requests.