Azure Private Endpoints: Deployment Scenarios Explained

Azure PaaS services are accessible over the public internet by default. An Azure SQL database, a Storage account, a Service Bus namespace: all of them have public endpoints that any machine on the internet can attempt to reach. For most regulated workloads, that is not acceptable, and the network security groups and IP firewall rules that restrict access are a configuration layer rather than a architectural one, meaning they can be misconfigured.

Private Endpoints solve this differently. They give a PaaS service a private IP address inside your virtual network, pulling it off the public internet entirely. Traffic between your workload and the service never leaves the Microsoft backbone. There is no public endpoint to misconfigure, because the service is not public.

This is how you do it, across the four deployment patterns that cover most real environments.

How Private Endpoints work

A Private Endpoint is a network interface with a private IP address in a subnet of your VNet. It connects to a specific Azure service resource (a storage account, a SQL server, a Key Vault) via Azure Private Link. From that point, DNS resolves the service's fully qualified domain name to the private IP rather than the public one.

The DNS piece is what makes it work end to end. Azure's DNS service intercepts queries for the service's FQDN (for example, myaccount.blob.core.windows.net) and returns the private IP instead of the public one. This requires a Private DNS zone (for example, privatelink.blob.core.windows.net) linked to the VNet. Without the DNS linkage, clients resolve to the public IP and the Private Endpoint does nothing.

One detail that catches teams out: Azure Storage has separate private endpoints for each sub-service. Blob, Data Lake Storage, Files, Queues, Tables, and Static Websites each need their own Private Endpoint. If you create one for Blob but not for Data Lake Storage, operations that internally redirect to the DFS endpoint (including some ACL operations) will fail. Create both at the same time, even if you only think you need one.

Pattern 1: Single-region setup

The simplest case: one VNet, one region, one private DNS zone per service type, linked to the VNet.

This is the right starting point for organisations with a single region deployment and no on-premise connectivity requirement. DNS resolution works automatically for workloads within the VNet, setup is straightforward, and there are no cross-region data transfer costs.

The limitation is resilience. A regional outage affects everything. For workloads where the service-level requirement is higher than a single region provides, one of the following patterns is the right choice.

Pattern 2: Hub-and-spoke with shared DNS

For organisations running multiple VNets (typical as environments grow: separate VNets for dev, staging, production, or separate VNets per team), the hub-and-spoke pattern centralises Private Endpoints and DNS in a hub network.

The Private DNS zones live in the hub subscription. Each spoke VNet is linked to those zones. A spoke workload querying myaccount.blob.core.windows.net resolves via the hub's DNS zone to the private IP of the endpoint in the hub, without each spoke needing its own endpoint or DNS zone.

This simplifies management substantially: one set of endpoints to maintain, one set of DNS zones, and consistent access controls. It also reduces cost compared to creating duplicate endpoints in every spoke.

The architectural constraint to plan for: Azure limits a DNS zone group to five DNS zones, and you cannot assign multiple DNS zone groups to a single Private Endpoint. Map your service count to your zone limits early. If you are connecting more than five PaaS service types through the hub, you will need multiple endpoints or a different grouping strategy.

Traffic routing from spokes to hub endpoints goes through VNet peering. For workloads that also need traffic inspection (Azure Firewall logging and filtering all traffic to private endpoints), a dedicated VNet for Private Endpoints in the hub allows you to route spoke traffic through the firewall without hitting the 400-route-per-routing-table limit. If you put endpoints and workload VMs in the same VNet, each endpoint requires a /32 system route pointing to the firewall, which adds up quickly in large environments.

Pattern 3: Hybrid (on-premise to Azure)

On-premise workloads accessing Azure PaaS services through Private Endpoints require DNS forwarding. The challenge: the on-premise DNS server does not know about the Azure private DNS zone.

The solution is a DNS forwarder: a VM (or Azure Firewall) inside the VNet that is linked to the private DNS zone. On-premise DNS servers use conditional forwarding to send queries for the relevant domains (e.g., blob.core.windows.net) to the forwarder in Azure. The forwarder resolves to the private IP and returns the answer.

Configure conditional forwarding on the on-premise DNS server to point to the public DNS zone (e.g., blob.core.windows.net), not the privatelink zone. The privatelink zone handles the resolution on the Azure side; pointing the conditional forwarder directly at it causes resolution failures for clients outside the VNet.

Azure Private Resolver is the managed alternative to a DNS forwarder VM. It removes the operational overhead of managing a forwarder server and handles DNS queries through inbound and outbound endpoints at a fixed hourly cost per endpoint. For organisations with complex hybrid DNS requirements or wanting to avoid DNS VM management, Private Resolver is worth the additional cost.

Test on-premise DNS resolution thoroughly before cutover. Query the service FQDN from an on-premise machine using nslookup and confirm the response is the private IP, not the public endpoint. Do this from multiple network segments if your on-premise environment is complex.

Pattern 4: Multi-region for DR

Private Endpoints can be deployed in a different region from the target service. This enables multi-region DR architectures where a secondary region's workloads can reach the same Azure service via a regional private endpoint.

The DNS approach for multi-region: either a shared DNS zone (simpler, but updates propagate with a short lag during failover) or regional DNS zones (faster local failover, but more complex to maintain). The right choice depends on your RTO. If your recovery time objective is measured in minutes and DNS propagation lag matters, regional zones are worth the complexity.

Cross-region traffic via Private Endpoints carries inter-region data transfer charges. These are typically higher than intra-region charges. For DR scenarios where the secondary endpoint is rarely used, this is usually negligible. For active-active multi-region architectures where both endpoints carry regular traffic, model the transfer costs before committing to the design.

DNS configuration checklist

Regardless of pattern, these are the DNS decisions that need deliberate attention:

Centralise zones. Create private DNS zones in a hub subscription and link to all spokes rather than creating duplicate zones per spoke. Duplicate zones cause split-brain DNS.

Map every sub-resource for Storage. If you are creating Private Endpoints for Storage accounts, create for blob, dfs, file, queue, table, and web depending on which sub-services the workload uses. Missing one causes silent failures on operations that use the unendpointed sub-resource.

Handle App Service SCM endpoints. App Service Private Endpoints need a second DNS record for the Kudu/SCM endpoint used by deployment agents. If you are using Private DNS Zone groups, this record is created automatically. If not, add it manually.

Test from every network segment. DNS resolution works differently for VNet workloads, on-premise workloads, and workloads in peered VNets. Test each path explicitly.

Audit unused endpoints. Private Endpoints incur a monthly charge even when inactive. Review and remove endpoints attached to decommissioned resources as part of your regular cost hygiene.

Where Critical Cloud comes in

Deploying Private Endpoints correctly, across hub-and-spoke and hybrid environments, with DNS that resolves reliably from every network path, is the kind of foundational networking work that is easy to get wrong once and expensive to fix later. We design and operate Azure networking for regulated businesses where taking PaaS services off the public internet is not optional. As the world's first Powered by Datadog accredited partner, we monitor private endpoint connectivity and DNS resolution health as live signals, so a misconfiguration appears in our alerting before it surfaces as a production incident. See how Critical Support works.