Episode 3 — Connecting Virtual Networks: Peering

In Episode 2 we gave a subnet its way out to the internet with public IPs and NAT Gateway; now we connect virtual networks privately to each other, without ever touching the public internet.

Learning objectives

• Explain how virtual network peering connects VNets over the Microsoft backbone and why the traffic is private, low-latency, and needs no gateway or encryption.
• Distinguish regional (local) peering from global peering, and identify the constraints unique to global peering.
• Design a hub-and-spoke topology and reason about the non-transitive nature of peering.
• Configure the bidirectional peering links, plus gateway transit and use remote gateways so spokes share the hub's VPN/ExpressRoute gateway.
• Troubleshoot peering using connectivity state and effective routes.

Why it matters

A single virtual network (VNet) is scoped to one region and one subscription (Episode 1), yet real workloads span many VNets — different teams, different subscriptions, shared services in a central network. VNet peering is the primary way to stitch those VNets together into one private routing domain, keeping every packet on Microsoft's private backbone instead of the public internet. It is the foundation of the hub-and-spoke architecture that dominates enterprise Azure networking, so understanding what peering does — and, just as importantly, what it does not do (it is not transitive) — is central to the AZ-104 networking domain.

What peering actually is

Virtual network peering connects two or more VNets so that, for connectivity purposes, they behave as one network. Resources in either VNet can reach resources in the other directly, using private IP addresses, exactly as if they were in the same VNet.

The defining properties, all from the Microsoft source:

• Traffic between peered VNets is private — it stays on the Microsoft backbone network. No public internet, no gateways, and no encryption are required for VNets to talk to each other.
• The connection is low-latency, high-bandwidth. For VMs in peered VNets in the same region, latency is the same as within a single VNet. Throughput is bounded only by the VM size's own network bandwidth — peering adds no extra bandwidth restriction.
• Peering works across subscriptions, across Microsoft Entra tenants, across deployment models (Resource Manager to classic), and across regions.
• Creating or removing a peering causes no downtime to resources in either VNet.

By default a VNet can be peered with up to 500 other VNets. Using the connectivity configuration of Azure Virtual Network Manager, that limit can be raised to 1,000 — enough to build a hub with 1,000 spokes, or a full mesh of 1,000 interconnected VNets.

Memory hook — "PBLN": peering is Private, on the Backbone, Low-latency, and needs No gateway/encryption. If you remember only one thing about why to peer, remember PBLN.

Two flavours of peering

Azure supports exactly two types, and the only difference is whether the VNets sit in the same region:

The Basic load balancer limitation is the classic global-peering "gotcha": some services built on a Basic LB simply don't work over global peering, whereas the Standard LB works over both. Note also that you can't peer across different clouds — an Azure public-cloud VNet cannot peer with a VNet in the Azure operated by 21Vianet (China) or Government cloud.

Exercise 1 — choose the right peering type

Scenario: Your web tier runs in West Europe and must reach a Standard internal load balancer fronting a shared logging service in North Europe. A colleague warns that "peering won't reach a load balancer across regions." Is that true here, and what type of peering do you configure?

Solution. You configure global virtual network peering, because the two VNets are in different regions. The colleague's warning applies only to a Basic load balancer — resources in one VNet can't reach the front-end IP of a Basic LB in a globally peered VNet. Your logging service uses a Standard load balancer, which is supported for both regional and global peering. So the design works. (If the service had been on a Basic LB, you would have needed the LB in the same region as the callers, or a redesign to Standard.) Remember too that global peering can't cross clouds — but both VNets here are in Azure public cloud, so that constraint doesn't bite.

Peering is bidirectional — and non-transitive

Two facts govern almost every peering design.

A peering must be configured on each side. When you peer two Resource Manager VNets, you create two peering links — one from VNet-A to VNet-B, and one from VNet-B to VNet-A. The connection is not usable until both exist. The connectivity states tell you where you are:

• Initiated — you created the first peering link; only one side exists.
• Connected — you created the second link; both peerings now show Connected. The peering is not successfully established until both sides read Connected.

Deleting is symmetric too: when you delete a peering from one VNet, the peering on the remote VNet is also deleted automatically.

Peering is NOT transitive. This is the single most tested idea in the topic. If you peer:

• VNet-1 ↔ VNet-2, and
• VNet-2 ↔ VNet-3,

then VNet-1 and VNet-3 cannot communicate through VNet-2. There is no "pass-through." To make VNet-1 and VNet-3 talk, you must either create an explicit peering directly between them, or route their traffic through a network virtual appliance (NVA) or gateway in a hub VNet.

In the diagram every spoke peers with the Hub, so each spoke reaches the hub directly. But Spoke A cannot reach Spoke C just because both peer the hub — the dotted line is not automatic. To enable spoke-to-spoke traffic you either add a direct peering A↔C, or force spoke traffic through an NVA in the hub using user-defined routes (UDRs) — which is exactly what service chaining does (next section, and the routing details come in Episode 4).

Exercise 2 — why spoke A can't reach spoke C

Scenario: In the hub-and-spoke above, an admin peers Spoke A↔Hub and Spoke C↔Hub, both showing Connected. A VM in Spoke A pings a VM in Spoke C by private IP and gets no reply. The admin insists "everything is peered." Explain the failure and give two ways to fix it.

Solution. Everything is peered — but peering is non-transitive, so the A↔Hub and C↔Hub peerings do not chain into an A↔C path. Spoke A has a route to the hub's address space and to nothing beyond it; it has no route to Spoke C. Two fixes:

1. Direct peering: create an explicit bidirectional peering Spoke A ↔ Spoke C. Simple, but in a large mesh the number of peerings explodes (this is why the mesh limit — up to 1,000 — matters).
2. Route through the hub NVA: place an NVA in the hub, add UDRs in Spoke A and Spoke C that set the next hop to the NVA's IP in the peered hub VNet (service chaining), and enable IP forwarding on the NVA. This keeps the clean hub-and-spoke shape and lets the hub inspect/firewall the traffic — the standard enterprise pattern. (The peering itself carries the forwarded traffic; you may need Allow forwarded traffic on the relevant peerings.)

Service chaining and gateway transit

Service chaining

Service chaining directs traffic from one VNet to a virtual appliance or gateway in a peered VNet by using UDRs. You configure a UDR whose next hop is the private IP of a VM (the NVA) — or a virtual network gateway — sitting in the peered VNet. This is how a hub VNet hosting a firewall NVA or VPN gateway inspects and forwards traffic for all its spokes.

One important limit: a UDR used for service chaining can point its next hop at a VM in the peered VNet or at a VPN gateway, but you can't route between VNets with a UDR whose next-hop type is an ExpressRoute gateway.

Two peering switches control forwarded traffic, and their defaults matter:

• Allow the peered virtual network to access this VNet — the basic "let traffic flow between us" switch. Selected by default. This is what enables ordinary hub-spoke VM-to-VM communication, and it also makes the VirtualNetwork service tag include the peered VNet.
• Allow forwarded traffic — lets this VNet accept traffic that originated elsewhere and was forwarded by an NVA in the peer. Not selected by default. Enabling it permits the forwarded packets through the peering, but it does not create any UDRs or NVAs — you build those separately.

Gateway transit and remote gateways

Gateway transit is a peering property that lets one VNet use a VPN or ExpressRoute gateway that lives in the peered VNet. In hub-and-spoke this is the key to hybrid connectivity: put one gateway in the hub, and every spoke reaches on-premises through it — no per-spoke gateway needed.

The rules:

• A VNet can have only one gateway. So a spoke that uses a remote gateway in the hub cannot have its own gateway.
• On the hub side you enable "Allow gateway... to forward traffic to the peered VNet" (gateway transit). On the spoke side you enable "Use the remote gateway". The "use remote gateway" option can be enabled on only one of a VNet's peerings.
• Gateway transit is supported for both regional and global peering.
• When two VNets are connected by both a peering and a gateway, traffic flows through the peering configuration, not the gateway.

## Create the two peering links, allowing VNet access and forwarded traffic. ##
az network vnet peering create \
    --name vnet-1-to-vnet-2 \
    --vnet-name vnet-1 \
    --remote-vnet vnet-2 \
    --resource-group test-rg \
    --allow-vnet-access \
    --allow-forwarded-traffic

az network vnet peering create \
    --name vnet-2-to-vnet-1 \
    --vnet-name vnet-2 \
    --remote-vnet vnet-1 \
    --resource-group test-rg-2 \
    --allow-vnet-access \
    --allow-forwarded-traffic

Note that a peering can't be created as part of the PUT virtual network operation — it is always its own operation. To work with peerings your account needs the Network Contributor role (or a custom role granting the Microsoft.Network/virtualNetworks/virtualNetworkPeerings/* actions).

Exercise 3 — enable gateway transit for hybrid spokes

Scenario: The hub VNet has a VPN gateway to on-premises. Spoke A must reach the on-premises network through that gateway. Spoke A currently has no gateway of its own. Which two peering settings do you set, and on which side?

Solution. Use gateway transit:

1. On the hub → spoke peering, enable "Allow gateway (or route server) to forward traffic to the peered VNet". This lets the hub's VPN gateway serve the spoke.
2. On the spoke → hub peering, enable "Use the remote gateway". This tells Spoke A to send its on-premises-bound traffic to the hub's gateway.

Prerequisites and pitfalls: Spoke A must have no gateway of its own (a VNet can have only one gateway, local or remote). "Use remote gateway" can be set on only one of Spoke A's peerings. Gateway transit works for global peering too, so the hub and spoke need not be co-located. Finally, note the pricing nuance: traffic to/from the hub gateway incurs normal VNet peering charges on the spoke side. On-premises, ensure the VPN device's "interesting traffic" includes all relevant Azure CIDRs (hub, spokes, P2S pools) or the spokes won't be reachable.

Address spaces, DNS, and resizing

Because peered VNets merge into one routing domain, their IP address spaces must not overlap — this is a hard requirement, planned back in Episode 1. If ranges overlap, the peering can't route unambiguously.

Two more practical facts:

• Name resolution does not cross a peering by default. Azure's built-in DNS won't resolve names in a peered VNet. To resolve across VNets you must use Azure Private DNS or a custom DNS server (covered in Episode 7).
• You can resize the address space of peered VNets with no downtime — modify a prefix (e.g. 10.1.0.0/16 → 10.1.0.0/18), add ranges, or delete ranges. After resizing, the peers must sync (via portal or PowerShell) to pick up the change; run sync after every resize. This works for IPv4 and IPv6, and cross-tenant — but not when the peer is a classic VNet.

You can also apply network security groups (NSGs) on either side to block or narrow access between peered VNets; full connectivity is the default, and NSGs let you tighten it.

Peering vs VPN gateway vs ExpressRoute (brief)

Peering is not the only way to connect VNets, but it is usually the best for VNet-to-VNet inside Azure:

When both a peering and a gateway connect the same two VNets, traffic uses the peering. And a shared gateway/ExpressRoute circuit in a hub can be reached by spokes via gateway transit — combining peering (VNet-to-VNet) with the gateway (to on-premises).

Troubleshooting peering

Two quick, exam-relevant checks:

• Effective routes. If a peering exists, every subnet in the VNet shows routes with next-hop type Virtual network peering — one for each address space of each peered VNet. Missing that route on a NIC means the peering isn't effective.
• Connectivity state. Confirm both links read Connected (not stuck at Initiated — which means only one side was created).
• Network Watcher connectivity check shows how traffic is routed from a source NIC to a destination NIC in the peered VNet — the go-to tool when VMs can't reach each other (deep dive in Episode 9).

Also remember: if you want to pause connectivity without tearing peerings down, don't delete them — just deselect "Allow traffic to remote virtual network". Disabling/re-enabling access is easier than deleting and recreating.

Key takeaways

• VNet peering makes peered VNets act as one network; traffic stays private on the Microsoft backbone — no gateway, no encryption, no internet.
• Two types: regional (same region) and global (across regions). Global can't cross clouds and can't reach a Basic load balancer front-end in the peer; Standard LB works for both.
• Peering is bidirectional — create a link on each side; both must show Connected. Deleting one deletes the other.
• Peering is non-transitive: A↔Hub and C↔Hub do not give A↔C. Fix with a direct peering or an NVA/route in the hub (service chaining via UDRs).
• Gateway transit + use remote gateway let spokes share the hub's one gateway for on-premises access; a VNet has only one gateway, and "use remote gateway" on only one peering.
• Address spaces must not overlap; DNS doesn't cross peering by default (use Private DNS/custom DNS); you can resize peered address spaces with no downtime, then sync.
• Default is 500 peerings per VNet, up to 1,000 with Azure Virtual Network Manager. Managing peerings needs the Network Contributor role.

Quick recall

1. Q: Does peering traffic between two VNets traverse the public internet or require encryption? A: No. It stays on the Microsoft backbone, private, with no gateway, internet, or encryption required.

2. Q: You peer VNet-1↔VNet-2 and VNet-2↔VNet-3. Can VNet-1 reach VNet-3? A: No — peering is non-transitive. You need a direct VNet-1↔VNet-3 peering, or route through an NVA/gateway in a hub.

3. Q: What two connectivity states appear, and when is a peering truly usable? A: Initiated after the first link; Connected after the second. It's only established when both sides read Connected.

4. Q: For a spoke to use the hub's VPN gateway, which two settings and where? A: On the hub's peering, allow gateway to forward traffic; on the spoke's peering, use the remote gateway. The spoke must have no gateway of its own.

5. Q: What single-region resource can't be reached across a global peering? A: The front-end IP of a Basic load balancer. Use a Standard load balancer instead.

Coming up

Peering builds the roads between VNets — but which road a packet takes is decided by routing. In Episode 4 we dig into system routes, user-defined routes (UDRs), route selection priority, and forcing traffic through an NVA — the machinery that makes hub-and-spoke and service chaining actually work.