Azure Private Link: Fix Setup & Config Errors Fast

This is the step where most Azure Private Link setups actually break. Even if the private endpoint is approved and the network interface has a private IP, if DNS doesn't route queries to that IP, your application will still try to connect over the public internet.

Azure Private Link works with specific Private DNS Zone names depending on the service. These are not arbitrary, they have to match exactly. Here are the most common ones:

Azure Blob Storage:   privatelink.blob.core.windows.net
Azure SQL Database:   privatelink.database.windows.net
Azure Cosmos DB:      privatelink.documents.azure.com
Azure Key Vault:      privatelink.vaultcore.azure.net
Azure Container Reg.: privatelink.azurecr.io

Go to Azure Portal → Private DNS Zones and confirm a zone with the correct name exists. Then click into it and do two things:

A) Check the A record: Under Record sets, look for an A record matching your resource name (e.g., myaccount for a storage account named myaccount). The IP value should match the private IP on your endpoint's NIC. If it's wrong or missing, click + Record set, set the name to just the resource short-name (not the FQDN), type A, TTL 10 seconds for testing, and enter the correct private IP from your endpoint's network interface.

B) Check the VNet link: Under Virtual network links, your VNet must be listed with registration status showing Completed. If it's not linked, click + Add, name the link, select your VNet, leave auto-registration off for private endpoint DNS zones, and save. Wait 60 seconds and test DNS again from a VM in that VNet.

One important nuance: if you have a hub-and-spoke topology, the DNS zone needs to be linked to the VNet where your DNS resolver sits, not necessarily every spoke. Verify your DNS forwarding rules if you use Azure Firewall DNS proxy or a custom DNS server.

Here's something that catches people off-guard: by default, Network Security Group (NSG) rules and User-Defined Routes (UDRs) do not apply to private endpoints inside a subnet. But if someone has explicitly enabled network policies on that subnet, those policies kick in, and if the NSG doesn't have the right allow rules, traffic gets dropped.

Check the current policy state with PowerShell:

$vnet = Get-AzVirtualNetwork -Name "your-vnet-name" -ResourceGroupName "your-rg"
$subnet = $vnet.Subnets | Where-Object { $_.Name -eq "your-subnet-name" }
$subnet.PrivateEndpointNetworkPolicies

If this returns Enabled, network policies are active on the subnet. This isn't necessarily wrong, you might want NSG control over private endpoint traffic, but you need to make sure the associated NSG actually allows your traffic.

To disable network policies and go back to the default (open) behavior, run:

$subnet.PrivateEndpointNetworkPolicies = "Disabled"
Set-AzVirtualNetwork -VirtualNetwork $vnet

Or via Azure CLI:

az network vnet subnet update \
  --name your-subnet-name \
  --resource-group your-rg \
  --vnet-name your-vnet-name \
  --disable-private-endpoint-network-policies true

If you want to keep policies enabled (which is valid and sometimes required by your security team), make sure your NSG has an inbound rule allowing traffic from the source subnet to the private endpoint's private IP on the correct port, for example, port 1433 for SQL, port 443 for Storage HTTPS, etc. Use the Azure Monitor Network Insights or NSG flow logs to confirm whether packets are hitting the NSG and what action is being taken before assuming this is or isn't the problem.

Once DNS and network policies look correct, use Azure Network Watcher's Connection troubleshoot tool to actually test the path from your VM to the private endpoint IP. This tool gives you a definitive pass/fail with hop-by-hop analysis, much better than guessing.

In the Azure Portal, search for Network Watcher. Under Network diagnostic tools, click Connection troubleshoot.

Fill in the fields:

• Source: Select your virtual machine (the one having connectivity issues)
• Destination type: Choose "Specify manually" and enter the private IP of your private endpoint (you can find this on the endpoint's Overview → Network interface)
• Protocol: TCP
• Destination port: The appropriate port for your service (443 for Storage, 1433 for SQL)

Click Check and wait 60–90 seconds for the result. If it shows Reachable with a low latency number, your network path is fine and the issue is likely in the application layer or DNS (go back to Step 2). If it shows Unreachable, the output will tell you at which hop the packet dies, whether it's an NSG, a UDR routing to the wrong next hop, or a gateway misconfiguration.

Pay attention to the hop count. A legitimate private endpoint path within the same region should have very few hops, usually 1–3. If you see traffic being routed out through an NVA or Azure Firewall that's blocking it, that's your culprit. Check the UDR table on the private endpoint's subnet and the source VM's subnet to make sure there's no route forcing traffic to a forced-tunnel or NVA unnecessarily.

Once Azure Private Link is working, you should verify it's actually being used, not just that connectivity tests pass. Azure Private Link has native integration with Azure Monitor, and you can pull data-processed metrics that confirm traffic is flowing through the private endpoint rather than the public endpoint.

Go to Azure Portal → Private endpoints → [your endpoint] → Metrics. Add a metric chart for Bytes In and Bytes Out. If traffic is flowing, you'll see non-zero values. If both stay at zero even when your application is running, that's a signal the application isn't actually routing through the private endpoint, often because its connection string still references the public FQDN and the client is resolving it to the public IP from outside the VNet.

To set up persistent monitoring, navigate to Diagnostic settings on the private endpoint and configure a destination, either a Log Analytics Workspace, a Storage Account for archival, or an Event Hub for streaming to a SIEM:

az monitor diagnostic-settings create \
  --name "pe-diagnostics" \
  --resource "/subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Network/privateEndpoints/{pe-name}" \
  --logs '[{"category": "AuditEvent","enabled": true}]' \
  --metrics '[{"category": "AllMetrics","enabled": true}]' \
  --workspace "/subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.OperationalInsights/workspaces/{workspace-name}"

For the Private Link service side (if you're operating a service behind a Standard Load Balancer), you can also track NAT port availability, a metric that becomes critical at scale. If NAT ports run out, new connections fail. Set an alert threshold at 75% NAT port utilization so you're never caught off guard. With monitoring in place, you have visibility into whether Azure Private Link is actually doing what you think it's doing.