Most Common Issues with Azure Private Endpoints, Private Link Service & Private DNS Zones

Introduction

Azure Cloud Engineers often encounter unexpected issues with individual Azure services or their connectivity. In this post, I've compiled error causes related to Private Endpoints, the Private Link Service, and Private DNS Zones that are not always easily identifiable.

Private DNS Records

In a VNet, various resources like virtual machines, Container Apps, or services integrated via Private Endpoints (e.g., Azure App Services, Storage Accounts, Key Vaults) can be operated. For name resolution within the VNet, Azure Private DNS Zones are used to map FQDNs to their respective private IP addresses.

Especially with Terraform deployments, it can happen that private IP addresses of services change, but the corresponding DNS records are not updated automatically. This leads to connectivity issues that are often hard to detect. Although DNS record updates are typically integrated into Terraform scripts, this issue can still occur in edge cases.

Example Scenario:

• You notice that a service within the VNet is no longer reachable.
• From another resource in the same VNet (e.g. a Container App), you run ping https://app-name.cas-env-suffix.region.azurecontainerapps.io.
• The command returns the currently resolved private IP address.
• Solution: Compare this private IP address with the recordset entry in the corresponding private DNS zone of the target service.

If the private IPs do not match, the recordset in the DNS zone is likely outdated and needs to be updated.

Non-Functional Private Endpoints

Private Endpoints are an elegant way to securely and privately expose Azure services through a direct connection to your VNet. But when the connection suddenly stops working, the troubleshooting often leads to dead ends.

Typical Causes:

• Missing or incorrect DNS resolution: As mentioned in the previous chapter, the Azure Private DNS Zone plays a central role. If the associated DNS entry does not correctly point to the private IP of the endpoint and its NIC (e.g., after a re-deployment), the service becomes unreachable.
• Missing network routes or NSG rules: The Private Endpoint may be created, but if Network Security Groups (NSGs) or User Defined Routes (UDRs) block traffic to the Private Endpoint subnet, you’ll encounter timeouts or rejected connections.
• Unapproved Private Endpoint connections: In many cases, a Private Endpoint connection must first be approved in the Azure Portal before it works. Without approval, the endpoint remains in "Pending" state and the connection fails.
• Subnet issues or IP conflicts: Private Endpoints are deployed into a specifically delegated subnet. If the subnet is too small and all IPs are already assigned, the assignment may fail silently.

My Recommendation:

• Set up a scheduled job to automate the approval process, so you don’t have to log in to the Azure Portal for each Private Endpoint approval.
• At the initial VNet deployment, ensure your Private Endpoint subnet is relatively large, as the number of endpoints can grow significantly. A good example are Azure Storage Accounts, which may create a separate Private Endpoint for each storage type (Blob, File, Queue, Table).
• Choose Private Endpoints when compliance policies require them. If cost is a concern and your cloud security requirements allow it, consider switching to Service Endpoints instead.

Unreachable Endpoints in FrontDoor

Azure Front Door is ideal for delivering global web apps with high availability and low latency. Still, problems may occur when accessing specific FrontDoor routes.

False Negatives with Health Probes

A common problem is failing health probes, even though the endpoint is reachable. This is a known issue caused by origin groups that contain only one origin. In such cases, Azure recommends designing the health probe accordingly, or you may face sporadic false negatives.

Origin Unreachable Despite Correct Configuration

While an Application Gateway is deployed within a specific VNet, FrontDoor is a global service. Therefore, you cannot use a service’s private IP address in your VNet directly as the host for an origin. Instead, you must route traffic from FrontDoor to public endpoints of your Storage Account, App Service, or Application Gateway, or use the Private Link Service.

If you want to use Private Link Service to access your VNet resources via the Azure backbone, you need to upgrade your FrontDoor instance to the Premium SKU. This allows you to use the Private Link Service, which, unlike Private Endpoints, does not deploy a virtual NIC with a static internal IP in your VNet. Instead, the services are linked directly over the Azure backbone.

Example Scenario:

• You have correctly configured an origin group in FrontDoor, but you cannot access your service via the configured domain, sub-path, etc.

You can do this as follows:

• Select your FrontDoor instance.
• In the side bar, select Origin Groups.
• Choose the faulty origin group.
• Click on Origin Host Name.
• Disable Enable Private Link Service.
• Click Apply to save changes.
• Repeat the steps and re-enable Enable Private Link Service.
• After successful creation, go to the Private Link Center using Azure search.
• In the side bar, select Pending Connections.
• Approve the Private Link connection for your FrontDoor origin.

This approach should resolve issues with App Services, Key Vaults, and Storage Accounts quickly.

My Container App Is Not Reachable

When configuring private DNS zones for Azure Container Apps, there are some differences compared to other services like Storage Accounts and App Services. For a Storage Account integrated via a Private Endpoint, you'd add a record in the private DNS zone privatelink.blob.storage.azure.net for each Storage Account with the IP of its NIC. The same applies to App Services with the zone privatelink.azurewebsites.net.

While Storage Accounts and App Services have individual internal IPs, the private DNS zone for Container Apps is region-name.azurecontainerapps.io. Here’s the catch: you don’t create a recordset for each individual Container App, but rather per Container App Environment. The recordset uses the internal IP of the internal load balancer of that environment.

As the name of the recordset, you must create a wildcard entry that reflects the Container App Environment suffix. For app-name.suffix.region-name.azurecontainerapps.io, the recordset name would be *.suffix. These values are just placeholders for explanation purposes. You’ll find the correct internal IP in the overview of the respective Container App Environment.

Conclusion

Using Private Endpoints, Private Link Services, and Private DNS Zones brings many benefits in terms of security and compliance, but it also requires a solid understanding of the underlying infrastructure.

Common issues like outdated DNS records, missing approvals, or misconfigured network routes can seriously impact connectivity and are often hard to diagnose.

Especially with automated deployments using Terraform, it's worth regularly checking DNS zones and IP assignments. Tools like the Private Link Center and setting up auto-approval processes can significantly reduce operational effort.

If you’re aware of these pitfalls and take a systematic approach, you can fully leverage the advantages of private connections in Azure—without falling into the usual traps.