Lesson 16 — VNet Peering, Service Endpoints & Private Endpoints

Domain 4 — Networking AZ-104: 15–20% ~35 min Prereq: Lessons 14–15

Why You Need to Understand This

No workload lives in complete isolation. Applications need to communicate across VNets. Databases and storage accounts need to be reachable from VMs without exposing them to the internet. These connectivity patterns — peering, service endpoints, and private endpoints — are among the most commonly tested AZ-104 topics, and they are also the most common sources of real-world misconfiguration in production Azure environments.

The concepts in this lesson are deceptively simple to state but require careful reasoning to apply correctly. VNet peering's non-transitivity trips up experienced engineers. Private endpoint DNS is a surprisingly deep topic. Pay close attention to the details — they are what distinguish a correct exam answer from a plausible-sounding wrong one.

VNet Peering

VNet Peering connects two VNets so their resources can communicate using private IP addresses over the Azure backbone network — never over the public internet. Traffic between peered VNets stays within Microsoft's network, providing low latency and high bandwidth.

Regional vs Global peering

TypeScopeLatencyCost
Regional peeringBoth VNets in the same Azure regionSub-millisecond (same DC fabric)Per-GB data transfer (low)
Global peeringVNets in different Azure regionsHigher (cross-region backbone)Per-GB data transfer (higher than regional)
Regional peering ingress is not free A common misconception: VNet peering data transfer is not free. Both regional and global peering incur per-GB charges on both sides (ingress and egress). Regional peering rates are lower than global peering. This is different from intra-VNet communication (within the same VNet), which is free.

Critical peering properties

  • Peering is bidirectional but must be configured in both directions: when you create a peering from VNet A to VNet B, you must also create a peering from VNet B to VNet A. Creating only one direction means VNet A can reach VNet B, but VNet B cannot reach VNet A. The portal can create both sides simultaneously as a convenience.
  • Address spaces cannot overlap: peered VNets must have non-overlapping CIDR ranges. Azure refuses to create the peering if they overlap.
  • Peering is not inheritable: resources in peered VNets can only access each other's immediate peers. A VNet cannot access resources through a peer's other peers.

Non-Transitive Peering — The Most Important Peering Fact

VNet peering is non-transitive. This is the most tested and most misunderstood property of peering.

VNet A ←──── peering ────→ VNet B ←──── peering ────→ VNet C VNet A ✗ CANNOT directly communicate with ✗ VNet C (even though both are peered to VNet B)

To allow A↔C communication, you have two options:

  1. Create a direct A↔C peering — simple but does not scale; in a large spoke topology you'd need O(n²) peerings.
  2. Route A→C traffic through an NVA (Azure Firewall) in VNet B — using UDRs in VNet A and VNet C that point to the Firewall in VNet B. This is the hub-spoke pattern and scales to any number of spokes.
Exam trap — transitive routing A common exam scenario: "VNet A is peered to VNet B. VNet B is peered to VNet C. A VM in VNet A cannot reach a VM in VNet C. Why?" The answer is always non-transitivity. The fix is either a direct A↔C peering or routing through an NVA. Do not confuse this with gateway transit (which is about on-premises connectivity via VPN/ExpressRoute, not spoke-to-spoke traffic).

Peering Configuration Properties

Each peering link has settings that control how traffic behaves. These are configured independently on each side of the peering.

SettingWhere configuredEffect
Allow Virtual Network Access Both sides Enables IP communication between resources in the peered VNets. Default: on. Turning this off makes the peering configuration exist but no traffic flows.
Allow Forwarded Traffic Both sides Allows traffic that was forwarded through this VNet (i.e. originated elsewhere) to pass. Required in NVA/hub scenarios where the hub's Firewall forwards spoke-to-spoke traffic.
Allow Gateway Transit Hub side (the VNet that has the gateway) Permits the peered VNet to use this VNet's VPN Gateway or ExpressRoute Gateway for on-premises connectivity. Must be enabled on the hub for spoke gateway transit to work.
Use Remote Gateways Spoke side (the VNet that will use the gateway) Tells the spoke to use the gateway in the peered (hub) VNet. Requires Allow Gateway Transit to be enabled on the hub side. Cannot be enabled if the spoke already has its own gateway.
Gateway transit — both sides must be configured For a spoke VNet to use the hub's VPN Gateway: enable Allow Gateway Transit on the hub's peering settings AND enable Use Remote Gateways on the spoke's peering settings. Both must be set. If either is missing, the spoke uses its own default route for internet/on-premises traffic and does not traverse the hub gateway.

Hub-Spoke Topology

The hub-spoke topology is the dominant enterprise network architecture in Azure. It uses peering to create a centrally-managed connectivity hub that shared services (firewall, VPN, DNS) live in, while application workloads live in isolated spoke VNets.

Hub VNet (10.10.0.0/16) — East US ├─ AzureFirewallSubnet (10.10.0.0/26) — Azure Firewall ├─ GatewaySubnet (10.10.1.0/27) — VPN Gateway / ExpressRoute └─ ManagementSubnet (10.10.2.0/24) — Bastion, DNS, monitoring VMs │ ┌─────┼──────────────────────────────────────┐ │ │ │ Spoke A Spoke B Spoke C (Prod) (Dev) (Shared Services)

Key design rules for hub-spoke

  • Spoke VNets peer to the hub — they do not peer with each other directly.
  • Spoke-to-spoke traffic is routed through the Azure Firewall in the hub, providing centralised inspection and logging.
  • UDRs in each spoke point 0.0.0.0/0 (and spoke CIDR ranges) to the Azure Firewall's private IP in the hub.
  • Hub has Allow Gateway Transit enabled; spokes have Use Remote Gateways enabled to share the hub's VPN/ExpressRoute gateway.
  • DNS: either an Azure DNS Private Resolver in the hub or DNS forwarder VMs — spoke VMs use this for hybrid DNS.
Transitive routing through the Firewall Spoke A VMs send traffic destined for Spoke B. Their UDR routes this to the Azure Firewall in the hub. The Firewall evaluates network/application rules and, if permitted, routes the traffic to Spoke B. This is how non-transitive peering is overcome without direct spoke-to-spoke peerings — traffic traverses the hub's Firewall, gaining inspection and audit logging for all east-west traffic.

Service Endpoints

Service endpoints extend your VNet's identity to an Azure PaaS service. When enabled on a subnet for a specific service (e.g. Microsoft.Storage), traffic from that subnet to the service is routed through the Azure backbone instead of the internet — and the service sees the traffic's source as your VNet private IP range rather than a public IP.

How service endpoints work

  1. Enable the service endpoint on the subnet (e.g. Microsoft.Storage on the AppTier subnet).
  2. On the PaaS service (e.g. Storage Account), configure the firewall to allow traffic from that specific subnet/VNet.
  3. Azure adds a more-specific route to the subnet's routing table directing traffic for the service's IP ranges through the Azure backbone instead of the default internet gateway.
  4. The PaaS service uses the source VNet identity for access control — the storage account can allow only the specified VNet subnet and block everything else (including other Azure services and the internet).
Service endpoints do NOT create private IPs The PaaS service still has a public IP address. Traffic from your subnet routes to that public IP via the Azure backbone (not the internet) — but the service is still publicly addressed. If you also want to block all internet access to the service, you must explicitly disable public network access on the service. Without that, the service is still reachable from the internet; your subnet just gets preferential backbone routing.

Private Endpoints

A Private Endpoint creates a network interface with a private IP address from your VNet's address space that maps to a specific PaaS service instance. Traffic to that PaaS service goes entirely over the private network — it never touches the public internet or the service's public IP.

How private endpoints work

  1. Create a private endpoint resource, specifying the target PaaS resource (e.g. a specific Storage Account) and the sub-resource type (e.g. blob).
  2. Azure provisions a NIC in your chosen subnet with a private IP from that subnet's address space (e.g. 10.20.3.5).
  3. All traffic from your VNet to that Storage Account is routed to 10.20.3.5 — it stays entirely within the private network.
  4. Optionally disable public access on the Storage Account — now even internet callers cannot reach it.
DNS is the most critical private endpoint requirement Your application calls mystorageaccount.blob.core.windows.net. Without DNS configuration, this name resolves to the Storage Account's public IP (e.g. 52.x.x.x) — traffic bypasses the private endpoint and goes to the internet. With correct DNS configuration, the same name resolves to your private endpoint IP (e.g. 10.20.3.5) — traffic stays private. The private endpoint exists but does nothing useful until DNS is correctly configured. This is the single most commonly missed step in private endpoint deployments.

Private DNS Zone configuration

The recommended approach for private endpoint DNS is to use Azure Private DNS Zones:

  1. Create a Private DNS Zone named privatelink.blob.core.windows.net (the zone name depends on the service — each has a specific privatelink subdomain).
  2. Link the Private DNS Zone to every VNet that needs to resolve the private endpoint.
  3. When you create the private endpoint, enable "Integrate with private DNS zone" — Azure automatically creates an A record in the zone mapping the storage account's FQDN to the private IP.
  4. Clients in linked VNets now resolve mystorageaccount.blob.core.windows.net → mystorageaccount.privatelink.blob.core.windows.net → 10.20.3.5 (private IP).

Private DNS Zone names by service

ServiceSub-resourcePrivate DNS Zone name
Azure Blob Storageblobprivatelink.blob.core.windows.net
Azure File Storagefileprivatelink.file.core.windows.net
Azure SQL DatabasesqlServerprivatelink.database.windows.net
Azure Key Vaultvaultprivatelink.vaultcore.azure.net
Azure Container Registryregistryprivatelink.azurecr.io
Azure Cosmos DB (SQL)Sqlprivatelink.documents.azure.com
Hub-spoke DNS for private endpoints In a hub-spoke model, private DNS zones should be linked to the Hub VNet. Spoke VMs use the hub's DNS resolver (Azure DNS Private Resolver or a DNS forwarder VM) to resolve private endpoint names. Do not link the same zone to every spoke VNet manually — use the hub as the central DNS resolution point, which gives you a single place to manage zone links as your spoke count grows.

Service Endpoints vs Private Endpoints — Side by Side

Understanding the differences between these two connectivity options is critical for both the exam and real-world architecture decisions. They solve similar problems but with different mechanisms and different trade-offs.

FeatureService EndpointsPrivate Endpoints
Private IP in VNet No — service retains public IP Yes — NIC with private IP in your subnet
Traffic path Azure backbone to service's public endpoint Fully private; never touches service public IP
Public access disabled No (service still accessible from internet unless separately restricted) Yes — public access can be fully disabled
DNS changes required No — FQDN still resolves to public IP Yes — FQDN must resolve to private IP
Cross-subscription Service endpoint policies only within subscription Yes — private endpoint can target resources in other subscriptions
Cross-region No — service endpoint is region-specific Yes — private endpoint in one region can connect to a resource in another
On-premises access Not directly accessible from on-premises Yes — on-premises traffic via VPN/ExpressRoute can reach the private IP
Setup complexity Low — enable on subnet, configure service firewall Medium — create endpoint, configure DNS zone, link to VNets
Cost Free (part of VNet) Per-hour cost + per-GB data processing fee
When to use Dev/test, simple scenarios, cost-sensitive environments Production, compliance-driven, any scenario requiring full private access
The rule of thumb Use Private Endpoints for production workloads. The DNS requirement is the main operational hurdle, but once your Private DNS Zone automation is in place (e.g. via Azure Policy auto-registration), it is seamless. Service Endpoints are a good fit for dev/test environments where the DNS overhead is not justified, or for simple storage firewalling where you trust your VNet boundary.

Azure Private Link

Azure Private Link is the underlying platform service that powers Private Endpoints. When you create a Private Endpoint for a PaaS resource (Storage, SQL, Key Vault, etc.), you are consuming that service through Private Link.

Private Link also enables a second scenario: Private Link Service, which lets you expose your own multi-tenant service (e.g. your application running behind a Standard Internal Load Balancer) to other VNets or customers' VNets via private endpoints — without VNet peering. This is used for ISV scenarios and service provider architectures.

For AZ-104, the important distinction is: Private Endpoint is the consumer side (in your VNet), Private Link Service is the provider side (exposing your service). The exam focuses on the Private Endpoint consumer experience.

Check Your Understanding

Click any option to see immediate feedback. Answers reflect real Azure behaviour.

1. VNet A is peered to VNet B. VNet B is peered to VNet C. A VM in VNet A cannot communicate with a VM in VNet C. What is the correct explanation?

VNet peering is non-transitive by design. Peering A↔B and B↔C does not create a path for A↔C. To enable A↔C communication, either create a direct A↔C peering, or configure UDRs in A and C that route cross-spoke traffic through an NVA (Azure Firewall) in VNet B. "Allow Forwarded Traffic" (option D) only affects traffic that has been forwarded by an NVA — it does not make peering transitive. That setting would be part of the NVA solution, not the cause of the problem.

2. You want a spoke VNet to use the hub VNet's VPN Gateway to connect to on-premises. What must be configured?

Both settings are required: Allow Gateway Transit must be enabled on the hub side of the peering (this allows the hub's gateway to be used by peers), and Use Remote Gateways must be enabled on the spoke side of the peering (this tells the spoke to use the hub's gateway). If either setting is missing, the spoke will attempt to use its own default routing and will not route on-premises traffic through the hub gateway. The spoke must not have its own gateway for Use Remote Gateways to be enabled.

3. You created a Private Endpoint for a Storage Account in your VNet. VMs in the VNet still connect to the Storage Account's public IP instead of the private endpoint. What is the most likely cause?

The most common private endpoint failure mode is missing DNS configuration. Even though the private endpoint NIC exists with a private IP, the application calls the FQDN (e.g. myaccount.blob.core.windows.net). Without a Private DNS Zone linked to the VNet and an A record mapping the FQDN to the private IP, DNS resolution returns the public IP. The application connects to the public IP — bypassing the private endpoint entirely. Creating the private endpoint does NOT automatically configure DNS unless you select "Integrate with private DNS zone" during creation. Option D is a common misconception — public access being enabled means external callers can still reach the service, but does not affect whether internal callers route to the public or private IP. That is purely a DNS resolution issue.

4. How do Service Endpoints and Private Endpoints differ in terms of the service's public endpoint accessibility?

Service Endpoints route traffic from your subnet through the Azure backbone to the service's existing public endpoint — the service's public IP remains active and reachable from the internet unless you separately configure the service firewall to block all public access. Private Endpoints create a private NIC in your VNet and allow you to set "Public network access: Disabled" on the service — at that point, the service's public IP stops accepting connections entirely, and only traffic through the private endpoint can reach the service. This is the key security advantage of Private Endpoints over Service Endpoints.

5. In a hub-spoke topology, Spoke-A VMs need to reach Spoke-B VMs. How is this enabled without creating a direct Spoke-A to Spoke-B peering?

Allow Forwarded Traffic (option A) is a necessary prerequisite but not sufficient on its own — it allows forwarded packets to enter/exit a VNet through a peering, but it doesn't create routes. The actual routing is controlled by UDRs. In Spoke-A, you add a UDR: destination = Spoke-B's CIDR, next hop = VirtualAppliance pointing to the Azure Firewall's private IP in the hub. The Firewall receives the traffic, evaluates its network/application rules, and routes it to Spoke-B. Allow Forwarded Traffic must be enabled on the hub-to-spoke peerings for the Firewall's forwarded packets to exit to the spokes — so both are needed, but the UDR is the routing mechanism.

6. You create a Private Endpoint for a Storage Account in your East US VNet. Resources in three other spoke VNets also need to resolve the storage account to the private IP. What is the correct DNS configuration?

The correct approach is one privatelink.blob.core.windows.net Private DNS Zone, linked to every VNet (or to the hub VNet with spoke DNS traffic forwarded to the hub). When you create the private endpoint and select "Integrate with private DNS zone", Azure automatically creates an A record in that zone mapping the storage account name to the private IP. Spokes linked to this zone (directly or via the hub DNS resolver) will correctly resolve the FQDN to the private IP. Creating separate zones per VNet (option A) creates an unmaintainable operational burden. Adding records to the public DNS zone (option B) would expose the private IP publicly and break public callers. DNS resolution through peering links is not automatic (option D) — explicit zone links are required.
Primary source for this lesson Azure Private Endpoint — Overview (Microsoft Learn)

Also read the VNet peering overview and the DNS for private endpoints article — the DNS configuration guide is especially important for production deployments and exam scenarios involving private endpoint troubleshooting.

Questions for your teacher (the AI agent)
This lesson covered peering, hub-spoke, service endpoints, and private endpoints. Go deeper on:
  • Walk me through configuring private endpoint DNS in a hub-spoke topology using Azure DNS Private Resolver — how does the conditional forwarding work from spoke VMs to the hub resolver?
  • Explain the specific scenarios where Service Endpoints are still preferred over Private Endpoints in 2025 — are there any legitimate production use cases left?
  • How do I automate Private DNS Zone registration for new private endpoints using Azure Policy, so that every new endpoint is automatically registered without manual intervention?
  • What happens to private endpoint connectivity when the target PaaS resource is moved to a different subscription or region?
Coming up: Lesson 17 — Azure DNS You now understand Private DNS Zones from the perspective of private endpoints. The next lesson covers Azure DNS comprehensively — public zones, private zones, DNS Private Resolver, split-horizon DNS, and how to design a complete DNS architecture for a hybrid enterprise environment with both Azure and on-premises workloads.