Private Link for Azure Storage: when to isolate and how to avoid DNS failures

Security audit flags storage access from your app VNet as traversing the public internet. The useful takeaway is that Azure Private Link can keep that traffic on Microsoft’s backbone, but the feature only works when private DNS resolves the storage FQDN to the private IP. Get DNS and subnet right first, then remove public access.

The problem that pushes teams to Private Link

An App Service or VM in a VNet needs blob and file access for an app. By default the storage account name resolves to a public IP. Service Endpoints can restrict network rules to the VNet, but the connection still uses the public service endpoint and requires the storage account to be publicly reachable.

Private Link changes the model. A Private Endpoint creates a network interface in your subnet with a private IP that represents the storage account inside your VNet. Traffic stays on the Azure backbone. The service name must resolve to that private IP via a private DNS zone.

Private Link vs Service Endpoints for storage data plane

Service Endpoints are simpler and have no per-endpoint charge. They are useful for low-risk scenarios and when you need quick VNet filtering.

Private Link provides stronger isolation. It removes the storage account from the public internet entirely when you disable public network access, and it works for hybrid connectivity through on-premises DNS forwarding. The cost is per Private Endpoint and per GB processed, plus operational overhead for DNS.

Worked example: lock down a storage account with a Private Endpoint

The pattern below secures blob and file access for a single storage account from one VNet. Replace placeholders with your names.

Prerequisites

• Contributor on the resource group containing the VNet and storage account.
• Network Contributor on the VNet for subnet changes.
• A subnet with enough free addresses. The Private Endpoint NIC consumes one IP.
• The storage account exists and is not yet locked down.

Create private endpoint and DNS link

Run Azure CLI from a machine with az logged in and access to the subscription.

az network private-endpoint create \
  --name pe-storage-prod \
  --resource-group rg-app-network \
  --vnet-name vnet-app \
  --subnet snet-private-endpoints \
  --private-connection-resource-id /subscriptions/<sub-id>/resourceGroups/rg-storage/providers/Microsoft.Storage/storageAccounts/stprodacct \
  --group-id blob \
  --connection-name pe-storage-blob

Repeat for file if needed with --group-id file. The command creates a NIC in the chosen subnet. Expected check: the private endpoint shows ProvisioningState Succeeded in the portal and the NIC has a private IP in the subnet range.

Link the storage private DNS zone to the VNet so resolution returns the private IP.

az network private-dns zone create \
  --resource-group rg-app-network \
  --name privatelink.blob.core.windows.net

az network private-dns link vnet create \
  --resource-group rg-app-network \
  --zone-name privatelink.blob.core.windows.net \
  --name link-vnet-app \
  --virtual-network vnet-app \
  --registration-enabled false

Risk: creating the DNS link after the endpoint exists can cause a temporary resolution gap.

Verify name resolution and block public access

From a VM in the VNet, test resolution.

nslookup stprodacct.blob.core.windows.net

You should see the private IP from the subnet, not a public address. If you see a public IP, DNS is not resolving to the private zone.

Once resolution is correct, disable public network access on the storage account. This is a state-changing operation.

az storage account update \
  --name stprodacct \
  --resource-group rg-storage \
  --public-network-access Disabled

Rollback if needed: set --public-network-access Enabled and remove the private endpoint.

Trade-offs and limits to plan for

Private Link costs per endpoint and data processed. For many low-risk services Service Endpoints remain cheaper.

DNS misconfiguration is the most common failure mode. The endpoint can be healthy while clients still resolve to the public IP.

Not all sub-resources are supported for every service. Verify the support matrix for the specific Azure service and sub-resource before design.

Shared subnets with Azure Firewall or custom UDRs add routing complexity. Test traffic paths in a non-production VNet first.

Actionable checklist before you cut over

• Confirm the service supports Private Link for the required sub-resource.
• Reserve subnet capacity and avoid overlapping address spaces.
• Create the Private Endpoint, then link the private DNS zone to the VNet.
• Validate resolution from a VM in the VNet resolves to the private IP.
• Attempt a read/write to the storage account from the VNet and confirm connectivity.
• Disable public network access only after verification succeeds.