Azure Private Link Service

Azure Private Link Service enables you to expose your own service (running behind an Azure Standard Load Balancer) to consumers privately, using Private Endpoints. The consumer's traffic reaches your service without traversing the public internet, remaining entirely within the Microsoft Azure backbone network. This is the equivalent of Azure Private Link but for custom services you own, rather than consuming Azure PaaS services like Azure SQL Database or Storage.

The primary driver for Private Link Service is security and compliance. Many organizations require that all traffic between their network and a partner's or customer's service never leaves the Microsoft network. By using Private Link Service, you can offer your service to clients who enforce a policy of no public internet exposure. This is common in regulated industries such as finance, healthcare, and government.

To understand Private Link Service, you must first grasp the flow of traffic. The service provider creates a Private Link Service attached to a Standard Load Balancer that fronts the actual service instances (e.g., VMs or containers). The consumer creates a Private Endpoint in their own virtual network, which gets a private IP address from their subnet. The Private Endpoint is associated with a connection request to the provider's Private Link Service.

When the consumer sends traffic to their Private Endpoint's private IP, the following happens: 1. The consumer's VM sends a packet destined to the Private Endpoint's IP (e.g., 10.0.1.4). 2. The Azure platform intercepts this packet because the Private Endpoint is a special network interface (NIC) with an IP that belongs to the consumer's VNet but is managed by Azure. 3. The Azure platform encapsulates the packet and forwards it over the Microsoft backbone to the provider's region where the Private Link Service is deployed. 4. The provider's Private Link Service receives the encapsulated traffic and forwards it to the backend pool of the associated Standard Load Balancer. 5. The Load Balancer distributes the traffic to the actual service instances (e.g., VMs in a backend pool).

The return traffic follows the reverse path. The key point is that the traffic never leaves Azure's network; it is tunneled between the consumer's Private Endpoint and the provider's Private Link Service.

To create a Private Link Service using Azure CLI:

# Create a Standard Load Balancer and backend pool
az network lb create --resource-group myRG --name myLB --sku Standard --public-ip-address myPIP --frontend-ip-name myFrontend --backend-pool-name myBEPool

# Create a Private Link Service
az network private-link-service create \
  --resource-group myRG \
  --name myPLS \
  --load-balancer-name myLB \
  --load-balancer-frontend-ip-configs myFrontend \
  --private-ip-address-version IPv4 \
  --auto-approval-subscriptions "<consumer-subscription-id>" \
  --enable-proxy-protocol false

To create a Private Endpoint:

# Create a Private Endpoint in the consumer's VNet
az network private-endpoint create \
  --resource-group consumerRG \
  --name myPE \
  --vnet-name consumerVNet \
  --subnet consumerSubnet \
  --private-connection-resource-id /subscriptions/providerSubId/resourceGroups/providerRG/providers/Microsoft.Network/privateLinkServices/myPLS \
  --connection-name myConnection \
  --group-id default

To approve a pending connection (provider side):

az network private-link-service connection approve \
  --resource-group providerRG \
  --name myPLS \
  --private-endpoint-connection-name myConnection \
  --description "Approved by admin"

To verify the connection state:

az network private-link-service show --resource-group providerRG --name myPLS --query privateEndpointConnections

A SaaS company hosts a multi-tenant application on Azure VMs behind a Standard Load Balancer. Their customers are financial institutions that require all traffic to remain within the Microsoft network and never traverse the internet. The SaaS provider creates a Private Link Service attached to the load balancer. Each customer creates a Private Endpoint in their own VNet and connects to the provider's service. The provider configures auto-approval for each customer's subscription. The customers configure private DNS zones so that the SaaS application's FQDN resolves to the Private Endpoint IP. This setup ensures that traffic from the customer's on-premises network (via ExpressRoute) to the SaaS app stays entirely within Azure's backbone. The provider scales the load balancer backend pool to handle thousands of concurrent connections. A common misconfiguration is forgetting to disable private endpoint network policies on the consumer's subnet, which causes the Private Endpoint creation to fail.

A large enterprise uses a hub-spoke network topology with Azure Firewall in the hub. They have a shared service (e.g., a central logging service) running in the hub VNet. They want to expose this service to multiple spoke VNets without routing traffic through the firewall or using public IPs. They create a Private Link Service in the hub VNet, attached to an internal Standard Load Balancer. Each spoke VNet creates a Private Endpoint to connect to the service. This allows spoke resources to send logs directly to the logging service without traversing the firewall, reducing latency and cost. The hub team manages the Private Link Service and can control which spokes are approved. A common issue is that spoke VNets may have overlapping IP address spaces, but Private Endpoints use their own IPs from the spoke's subnet, so there is no conflict. However, DNS resolution must be carefully managed to avoid the spoke's DNS resolving the service FQDN to a public IP.

A managed service provider (MSP) offers a monitoring solution to multiple customers, each in their own Azure AD tenant. The MSP deploys the service in their tenant and creates a Private Link Service with manual approval. Each customer creates a Private Endpoint in their own tenant, referencing the MSP's Private Link Service resource ID. The MSP then manually approves each connection. This allows the customers to access the monitoring service privately without exposing it to the internet. Performance considerations include the number of concurrent connections (max 1000 per Private Link Service) and the latency added by the encapsulation (typically <1ms). A common failure is when the customer's Private Endpoint creation fails due to insufficient permissions on the provider's resource – the customer must have 'Microsoft.Network/privateLinkServices/read' permission on the provider's subscription (granted via Azure RBAC or a delegated resource).