Azure Private Link Basics

Azure Private Link is a service that provides private, direct connectivity from an Azure virtual network (VNet) to Azure PaaS services (e.g., Azure Storage, SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics, Azure Cosmos DB, Azure Key Vault, Azure App Service, Azure Functions, Azure Container Registry, Azure Service Bus, Azure Event Hubs, Azure Data Factory, Azure Data Lake Storage Gen2, Azure Cognitive Services, Azure Machine Learning, Azure API Management, Azure Backup, Azure Site Recovery) and to customer-owned services (via Private Link Service). The core purpose is to eliminate data exfiltration risks by ensuring traffic never traverses the public internet. Instead, traffic flows entirely within the Microsoft Azure backbone network.

Before Private Link, accessing PaaS services from a VNet required either:

Private Link solves this by placing a private IP address (from your VNet) as the network interface (NIC) for the PaaS service. This NIC is called a Private Endpoint (PE). The Private Endpoint is a special network interface that uses a private IP from your VNet and connects to the PaaS service via Azure's backbone. From the service's perspective, traffic appears to originate from that private IP, not from a public IP. This allows you to block all public access to the service (by disabling public network access) and still have connectivity from your VNet.

The mechanism relies on Azure's Software-Defined Networking (SDN) stack. When you create a Private Endpoint, Azure performs the following steps: 1. Resource Creation: You specify the target Azure resource (e.g., a storage account) and its sub-resource (e.g., blob, file, queue, table). Azure deploys a Private Endpoint resource in your VNet/subnet. This endpoint is assigned a private IP from the subnet's address range (you can specify a static IP or let Azure assign dynamically). 2. DNS Configuration: To ensure that clients in your VNet resolve the service's FQDN (e.g., mystorageaccount.blob.core.windows.net) to the private IP, Azure creates a Private DNS Zone (e.g., privatelink.blob.core.windows.net) and links it to your VNet. The DNS resolution works as follows:

- When a client queries the FQDN, Azure DNS returns a CNAME record pointing to the privatelink zone. - The privatelink zone contains an A record with the private IP of the Private Endpoint. - The client then connects directly to that private IP. 3. Traffic Flow: Packets sent to the private IP are routed within the VNet to the Private Endpoint NIC. The Azure SDN maps this NIC to the target service's backend. The traffic is encapsulated and forwarded over the Azure backbone to the service's regional endpoint. The service sees the source IP as the private IP of the Private Endpoint (not the client's public IP). 4. Network Security Groups (NSGs): You can apply NSGs to the subnet containing the Private Endpoint, but NSGs are not supported on the Private Endpoint NIC itself. Traffic to the Private Endpoint is subject to the NSG rules of the subnet. However, Azure does not support NSG flow logs for Private Endpoint traffic. 5. User-Defined Routes (UDRs): UDRs on the subnet can affect traffic to the Private Endpoint. However, Azure recommends using the default system routes for Private Endpoint traffic to avoid asymmetric routing.

To create a Private Endpoint using Azure CLI:

az network private-endpoint create \
    --resource-group myRG \
    --name myPE \
    --location eastus \
    --vnet-name myVNet \
    --subnet mySubnet \
    --private-connection-resource-id /subscriptions/{sub}/resourceGroups/myRG/providers/Microsoft.Storage/storageAccounts/mystorage \
    --group-id blob \
    --connection-name myConnection

To verify the Private Endpoint:

az network private-endpoint show --name myPE --resource-group myRG

To check DNS resolution from a VM in the VNet:

nslookup mystorageaccount.blob.core.windows.net

Expected output:

Non-authoritative answer:
Name: mystorageaccount.privatelink.blob.core.windows.net
Address: 10.0.0.4 (private IP)

A financial services company hosts a critical Azure SQL Database containing customer financial records. They have a regulatory requirement (e.g., PCI-DSS) that no data can traverse the public internet. They deploy an Azure VNet with a subnet for application VMs. They create a Private Endpoint for the SQL Database in that subnet, associating it with the 'sqlServer' sub-resource. They configure a Private DNS Zone (privatelink.database.windows.net) linked to the VNet. They then disable public network access on the SQL Server. The application VMs connect to the SQL Database using the FQDN (myserver.database.windows.net), which resolves to the private IP 10.0.1.5. All traffic flows within the Azure backbone. The company also uses Azure Policy to enforce that all new SQL Servers must have a Private Endpoint and that public access is disabled. This prevents data exfiltration even if a storage account is accidentally created without proper controls.

A healthcare organization has a custom application hosted on Azure VMs behind an internal Standard Load Balancer. They want to expose this application to a partner organization's VNet without exposing it to the internet. They create a Private Link Service (PLS) attached to the internal load balancer. The partner organization creates a Private Endpoint in their own VNet, specifying the resource ID of the PLS. After approval, the partner's VMs can access the application using the private IP of their Private Endpoint. The healthcare organization can apply NSGs to the PLS subnet to control inbound traffic. They also monitor connection logs to detect any unauthorized access attempts. This setup eliminates the need for VPNs or public endpoints, reducing attack surface.