Private Endpoint Best Practices¶

Private Endpoint guidance must cover the whole consumer path: endpoint approval, subnet placement, private DNS, public-access interaction, and service-specific subresource expectations.

Why This Matters¶

Private Endpoint incidents often look deceptive. The private endpoint resource shows Approved, yet workloads still fail because the wrong clients resolve the private name, the public endpoint is still being used, or the service-specific subresource was never added.

That means good practice is not just "deploy a private endpoint." It is to make split-horizon DNS, consumer-network validation, and service-specific caveats part of the design from the start.

mermaid flowchart TD Client[Client subnet] --> Resolver[DNS resolver path] Resolver --> PrivateZone[Private DNS zone] PrivateZone --> PrivateEndpoint[Private endpoint NIC] PrivateEndpoint --> Resource[Azure PaaS resource instance] Client --> PublicPath[Public endpoint path] PublicPath --> Decision[Allowed or intentionally blocked]

Recommended Practices¶

Treat private DNS as part of the deployment, not as follow-up work¶

• Create or reuse the correct private DNS zone and zone group in the same change window as the endpoint.
• Validate which VNets, on-premises resolvers, and build agents must consume the private answer.
• Keep a single owner for each private namespace so duplicate zones do not drift across subscriptions.

az network private-endpoint show \
    --resource-group $RG \
    --name $PRIVATE_ENDPOINT_NAME \
    --query "{customDnsConfigs:customDnsConfigs,networkInterfaces:networkInterfaces}"

az network private-endpoint dns-zone-group list \
    --resource-group $RG \
    --endpoint-name $PRIVATE_ENDPOINT_NAME

Design split-horizon behavior explicitly¶

• Decide which networks must resolve the public name and which must resolve the private address.
• Keep public access decisions aligned with client design; do not leave the public endpoint unintentionally reachable from unmanaged networks.
• Document whether fallback to the public path is allowed, blocked, or used only during migration.

Validate from every required consumer network¶

• Test from each VNet, on-premises segment, and automation environment that consumes the service.
• Do not accept portal success as proof of runtime success; runtime success comes from DNS plus packet path together.
• Keep one validation note per consumer group so outages can be scoped quickly later.

az network private-dns link vnet list \
    --resource-group $RG \
    --zone-name $PRIVATE_DNS_ZONE_NAME \
    --output table

az network watcher test-connectivity \
    --resource-group $RG \
    --source-resource $SOURCE_RESOURCE_ID \
    --dest-address $DESTINATION_FQDN \
    --dest-port 443

Capture service-specific caveats before rollout¶

• Storage, SQL, Key Vault, and other Private Link-enabled services use different private DNS zones and subresources; verify the right one for each connection.
• Separate endpoint lifecycle from application deployment lifecycle so endpoint approval and DNS stabilization do not surprise an application cutover.
• Reserve subnet capacity for additional endpoints instead of treating endpoint IP growth as an afterthought.

Keep deletion and rollback as first-class workflows¶

• Record how to remove stale private endpoints, zone links, and approvals cleanly.
• Make sure rollback notes say whether clients should return to the public endpoint or wait for private DNS repair.
• Review old endpoints regularly so consumers do not resolve to abandoned private IPs.

Common Mistakes / Anti-Patterns¶

• Creating the private endpoint first and leaving DNS to a later ticket.
• Assuming one consumer VNet proving success means all consumer networks are wired correctly.
• Leaving the public endpoint path undocumented during a private cutover.
• Reusing the wrong subresource or private DNS zone for the target service.
• Mixing private endpoint cleanup with unrelated application teardown so stale DNS and approvals remain.

Validation Checklist¶

• [ ] Private endpoint, zone group, and required private DNS links are deployed together.
• [ ] Public-path behavior is documented for every consumer group.
• [ ] Validation covers all required consumer networks, not just the endpoint subnet.
• [ ] Service-specific DNS zones and subresources are correct.
• [ ] Rollback notes explain how clients recover if private resolution fails.

See Also¶

• Dns Best Practices
• Subnet Design Best Practices
• Connect Private Endpoints
• DNS Resolution Failures

Sources¶

• What is a private endpoint?
• Azure Private Endpoint DNS configuration
• Use private endpoints for Azure Storage