Azure Private Link for Enterprise: Secure Private Access to PaaS and Partner Services

Overview

Azure Private Link provides private IP-based access to supported Azure services such as Storage, Key Vault, SQL Database, App Service, and many partner offerings. Instead of reaching a public endpoint, clients connect through a private endpoint in a virtual network, keeping traffic on the Microsoft backbone and reducing exposure to internet-based threats, data exfiltration, and overly broad firewall rules.

Enterprises use Azure Private Link to support zero trust segmentation, regulatory controls, and hybrid connectivity. It is especially valuable when central security teams must enforce private-only access to sensitive services while application teams retain managed PaaS benefits.

Architecture

Core components

• Private Link service: The Azure capability that maps a service to private connectivity.
• Private endpoint: A NIC with a private IP in your VNet that represents the target service.
• Private DNS zone: Resolves service FQDNs to private IPs, for example privatelink.blob.core.windows.net.
• Consumer VNet: The network hosting workloads that access the service.
• Provider service: Azure PaaS resource, customer service, or partner service.

Deployment models

• Single VNet: App and private endpoint reside in the same VNet.
• Hub-and-spoke: Shared private DNS and centralized governance in hub; endpoints deployed in spokes or centrally.
• Hybrid: On-premises clients resolve private DNS through conditional forwarders and reach endpoints over ExpressRoute or VPN.
• Cross-subscription / cross-tenant: Supported with approval workflow and RBAC controls.

Data flow

1. Client resolves the service FQDN.
2. DNS returns the private endpoint IP from the linked private DNS zone.
3. Traffic flows from client subnet to the private endpoint over the VNet.
4. Azure maps the connection to the target service over the Microsoft backbone.

Implementation Guide

1. Create a resource group and VNet.

az group create -n rg-privatelink-prod -l westeurope
az network vnet create -g rg-privatelink-prod -n vnet-app-prod --address-prefix 10.20.0.0/16 --subnet-name snet-app --subnet-prefix 10.20.1.0/24
az network vnet subnet create -g rg-privatelink-prod --vnet-name vnet-app-prod -n snet-endpoints --address-prefixes 10.20.2.0/24 --disable-private-endpoint-network-policies true

1. Create the target service, for example a Storage account.

az storage account create -g rg-privatelink-prod -n stplprod001 -l westeurope --sku Standard_LRS --kind StorageV2 --public-network-access Disabled

1. Create the private DNS zone and link it to the VNet.

az network private-dns zone create -g rg-privatelink-prod -n privatelink.blob.core.windows.net
az network private-dns link vnet create -g rg-privatelink-prod -n link-app-prod -z privatelink.blob.core.windows.net -v /subscriptions/<subId>/resourceGroups/rg-privatelink-prod/providers/Microsoft.Network/virtualNetworks/vnet-app-prod -e false

1. Create the private endpoint for the blob subresource.

ST_ID=$(az storage account show -g rg-privatelink-prod -n stplprod001 --query id -o tsv)
az network private-endpoint create -g rg-privatelink-prod -n pe-stplprod001-blob --vnet-name vnet-app-prod --subnet snet-endpoints --private-connection-resource-id $ST_ID --group-id blob --connection-name peconn-stplprod001-blob

1. Create the DNS zone group.

az network private-endpoint dns-zone-group create -g rg-privatelink-prod --endpoint-name pe-stplprod001-blob -n default --private-dns-zone privatelink.blob.core.windows.net --zone-name privatelink.blob.core.windows.net

1. Validate name resolution and connectivity from a VM in snet-app.

nslookup stplprod001.blob.core.windows.net
curl -I https://stplprod001.blob.core.windows.net/

Code Examples

az network private-endpoint show -g rg-privatelink-prod -n pe-stplprod001-blob --query '{ip:networkInterfaces[0].id,provisioningState:provisioningState}'
az network private-dns record-set a list -g rg-privatelink-prod -z privatelink.blob.core.windows.net -o table

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  STORAGE_ACCOUNT_FQDN: "stplprod001.blob.core.windows.net"
  DNS_EXPECTED_ZONE: "privatelink.blob.core.windows.net"
  PRIVATE_ONLY_MODE: "true"

import socket
fqdn = "stplprod001.blob.core.windows.net"
ips = socket.gethostbyname_ex(fqdn)[2]
print({"fqdn": fqdn, "resolved_ips": ips, "private_match": any(ip.startswith("10.") for ip in ips)})

Security Hardening

• Disable public network access on supported services once private endpoints are validated.
• Use RBAC and least privilege for endpoint creation: Network Contributor is often too broad; prefer scoped custom roles.
• Restrict subnet use for private endpoints and separate them from application subnets for cleaner policy and routing control.
• Enforce private DNS governance to avoid split-brain resolution issues.
• Combine with NSGs, Azure Firewall, and Defender for Cloud for layered controls.
• Use service-side protections such as CMK encryption, soft delete, purge protection, and resource locks.
• Monitor with Azure Monitor and activity logs for Microsoft.Network/privateEndpoints and service firewall changes.

Comparison

Troubleshooting

Error 1: DNS resolves to public IP

Log sample:

$ nslookup stplprod001.blob.core.windows.net
Name: stplprod001.blob.core.windows.net
Address: 20.60.44.132

Fix: Verify the private DNS zone link to the VNet, confirm the zone group exists on the private endpoint, and ensure on-premises DNS forwarders send privatelink.blob.core.windows.net queries to Azure DNS resolvers.

Error 2: Endpoint approved but connection fails

Log sample:

curl: (7) Failed to connect to stplprod001.blob.core.windows.net port 443 after 3001 ms: No route to host

Fix: Check routing from source subnet to the endpoint subnet, confirm no UDR forces traffic to an appliance that drops RFC1918 east-west flows, and validate NSG rules allow outbound 443.

Error 3: Service rejects access after disabling public access

Log sample:

2025-04-12T09:14:33Z StorageErrorCode: AuthorizationFailure
Message: This request is not authorized to perform this operation.

Fix: Private Link provides network path, not data-plane authorization. Validate managed identity, SAS, or RBAC permissions on the target service.

Best Practices

Do

• Standardize a hub-and-spoke DNS design with centrally managed private DNS zones.
• Use one private endpoint per required subresource, for example separate endpoints for blob, file, and queue.
• Document service dependencies before disabling public access.
• Test from each consumer network, including on-premises and peered VNets.

Don't

• Do not assume Private Link replaces identity and authorization controls.
• Do not mix unmanaged custom DNS changes with automatic zone group registration without change control.
• Do not centralize all endpoints blindly; some latency-sensitive apps perform better with local spoke endpoints.
• Do not leave public endpoints enabled "just in case" for production data services.