Azure Hub and Spoke VNets - Private Endpoints and Private DNS Zones

Azure makes it simple to access Azure Cloud Services from your processes in Azure over the public network.  Things become a little more complicated when you implement the best practice of restricting access to your Azure Services to only your Azure networks (VNets).  This simple action drags in Private Link Endpoints and Private DNS Zones

Enterprises typically then layer on multiple Virtual Networks (VNets) for management and control purposes. This VNET Hub and Spoke architecture is pretty common though Microsoft has recently been advising customers to implement HUB and Spoke more through subnets than VNets. This reduces VNet sprawl and the amount of peering and other network magic required  

See YouTube video links below

Private Endpoints / Private DNS Zones 

Azure Standard Sevices can be restricted from the Public Internet to your private Virtual Network (VNet) through the use of Private Link Endpoints (PLE). The PLEs essentially create private connections from a Network Interface Card (NIC) in your VNet to the Azure Service.  
  • Each service asset has its own Private Link Endpoint and corresponding NIC.
  • A DNS entry is created for that NIC using an Azure standard domain name.  
  • The DNS entry is managed through a Private DNS Zone.  
  • The Private DNS Zone is joined to your VNet through a Virtual Network Link. A Private DNS Zone's Virtual Network Links can be managed in the Azure Portal.
  • Processes in that VNET can access the resource PLE via DNS name using the standard Azure VNet DNS service available on the well-known address in each VNET.
Each Azure service type has its own domain naming standard and corresponding Private DNS Zone.

This VNet also includes a Point to Site (P2S) VPN on the VNet Gateway. Remote processes communicate with Azure resources over the VPN tunnel.  A DNS forwarder is provisioned in the VNET and attached to the VPN Gateway.  The downloaded VPN configuration files include references to the DNS Forwarder.  External processes then use that DNS Forwarder as their DNS server when looking up Azure names. 

Private Link Endpoint / DNS / Hub and Spoke VNets

This same behavior can be extended across peered VNets. It is pretty standard in the networking world to organize networks around a hub and spoke topology.  There is typically a hub VNet that contains management resources and gateways or peerings off to any resources outside this grouping.  Worker or Spoke VNets connect to the hub.  Resources in the spoke VNets talk to resources in other VNets by transiting through the hub. The current Landing Zone pattern is an extension of this.   
  • Peering relationships are set up between the Hub Vnet and each connected Spoke.
  • Private DNS Zone resources are declared in a centralized resource group rather than in one of the Resource Groups dedicated to Spoke assets.
  • Azure services are exposed in a given Spoke using the same pattern used for a single VNet with Private Endpoints and Private DNS Zones that are connected to the Spoke VNet DNS via Virtual Network Links.
  • Private Link NIC DNS entries from all the Spokes are stored in the same share Private DNS Zones.
  • The Private DNS Zones are linked to all the VNets.  Really to all the VNets where that asset may be accessed from.

The DNS Forwarder presented to VPN Clients is linked to the standard VNet Azure DNS Server.  That server knows about the Private DNS Zone severs.  This means the programs on the VPN have access to the DNS entries for all of the Private Endpoints or other resources in all the Spoke VNets.


Example Project on GitHub

This picture comes from the README of It shows multiple Private DNS Zones, one for each type of Azure Service resource that exists in this project.  Each Zone is exposed to the Spoke VNet over a Virtual Network Link, as described in the Azure Portal. 

The Spoke VNet contains multiple subnets.  Some of those subnets have Private Link Endpoints terminating in them.  Those PLEs DNS entries are registered with the corresponding Private DNS Zones.  This means compute and other resources in that VNET can find the resource by name.  

The same DNS is linked to the Hub VNet.  This means processes on the hub VNet can also see the PLE DNS names. 

The screenshots in the rest of this blog are from Infrastructure configured via this GitHub Project

Hub and Spoke VNets

Our sample network has two VNets.  One Hub and one Spoke.

Subnets on the two VNets

Each VNet has its own subnet.  Our Hub VNet has 3 network management and governance subnets. 

The Spoke Vnet has compute, data, and secrets subnets.  The data and CredentialsSecrets subnets will contain Private Link Endpoints for our data and Key Vault Azure services

DNS Forwarders

The Hub VNet contains a VPN gateway.  This means it needs a DNS Forwarder to provide internal Azure DNS IP address resolution for processes across the VNet.

Spoke VNets use standard Azure DNS services.

Private Endpoints

We don't have any Private Endpoints in the Hub VNet.  A real network would have Key Vault, Storage or other services used for management and governance.

The Spoke VNet contains Private Endpoints for Storage Accounts and Key Vaults.

Private DNS Zones

Private DNS Zones are created for each of the Azure Service types, and associated DNS Zone, we expect to provision access via Private Endpoints.  All of the Private DNS Zones are put in the same Resource Group to ensure that we don't end up with disjoint Private DNS Zones for the same domain.

The project has a core Resource Group that contains our VNET, DNS Forwarder VPN Gatway and all the Private DNS Zones.

Private DNS Zone Links to VNETs

Private DNS Zones are exposed into VNets via Virtual Network Links.  A link is created from the DNS Zone to each VNet where the resource may need to be accessed via DNS name.  In this example, we create a link to every VNet, hub, and spoke.

Private DNS Zone DNS Private Link Entries

A DNS entry is created for every Private Endpoint.  Microsoft has standardized the domain name for Private Links by Azure resource types.  All of the Azure Storage blob resources end up in the domain.  The sample has a single blob resource so there is only one DNS entry in the Private DNS Zone DNS server for that domain.

We've exposed both blob and file for this Storage Account. This means we created Private Endpoints for both file and blob.  There will be two DNS entries each in its associated zone.


This was a short description of how VNets, peering, Private Endpoints, and multi-VNet DNS work.  Leave feedback if you think one of these sections could use more explanation.

Created 2022 04


Popular posts from this blog

Understanding your WSL2 RAM and swap - Changing the default 50%-25%

Installing the RNDIS driver on Windows 11 to use USB Raspberry Pi as network attached

DNS for Azure Point to Site (P2S) VPN - getting the internal IPs