VNet Peering and Connectivity

Your network won’t stay in a single VNet for long. Peering connects VNets so resources communicate as if they’re on the same network — with Microsoft backbone speed, no public internet involved.

🎬 Video coming soon

VNet Peering, Gateway Transit & AVNM

~13:00

Simple explanation

VNet peering is like building a private hallway between two floors of a building. Without peering, VNets are isolated. Peering creates a direct connection using Microsoft’s backbone — fast, private, never touches the internet. The catch: peering is not transitive. If A peers with B and B peers with C, A can’t reach C unless you set up explicit routing.

VNet Peering Basics

🏢 Ravi’s hub-and-spoke: Pinnacle Financial has a hub VNet (shared services, gateways, firewall) and two spoke VNets (Finance, HR). Peering connects each spoke to the hub.

Key peering rules:

Rule	Detail
Non-transitive	If VNet-A peers with VNet-B, and VNet-B peers with VNet-C, VNet-A cannot reach VNet-C through VNet-B — unless you configure routing through an NVA or gateway.
Cross-subscription	Peering works across subscriptions (both owners must create their side).
Cross-region (global peering)	Peering works across regions. Same-region peering has no bandwidth limits; global peering is metered.
Non-overlapping	Address spaces must not overlap.
Two-sided	Both VNets must create the peering link. Status shows “Initiated” until both sides connect.
Updates disconnect	Changing a VNet address space requires disconnecting peering first.

Peering settings (each side configured independently):

Setting	Purpose	Default
Allow forwarded traffic	Accept traffic that didn’t originate from the peered VNet (e.g., from an NVA)	Disabled
Allow gateway transit	Share this VNet’s gateway with the peered VNet	Disabled
Use remote gateways	Use the peered VNet’s gateway instead of deploying your own	Disabled
Allow virtual network access	Enable basic connectivity between the peered VNets	Enabled

Gateway Transit

Gateway transit is how spokes share the hub’s VPN or ExpressRoute gateway without deploying their own.

On-Premises ←── VPN/ER ──→ Hub VNet (Gateway)
                              ├── Peering ──→ Spoke 1 (Uses remote gateways)
                              └── Peering ──→ Spoke 2 (Uses remote gateways)

Configuration:

Hub side: Enable Allow gateway transit on the peering to each spoke
Spoke side: Enable Use remote gateways on the peering to the hub
Important: A VNet can only use remote gateways from one peered VNet
Important: You cannot use remote gateways with global peering if the gateway is a Basic SKU VPN Gateway (Standard or higher required)

🏢 Ravi’s setup: His hub VNet has an ExpressRoute Gateway. He enables “Allow gateway transit” on hub-to-spoke peerings. Each spoke enables “Use remote gateways.” Now Finance and HR VMs can reach on-premises through the hub’s gateway without needing their own.

Service Chaining

Service Chaining with UDRs

Peering is non-transitive by default, but you can create spoke-to-spoke connectivity by routing traffic through a hub NVA (like Azure Firewall):

Spoke 1 route table: 10.30.0.0/16 (Spoke 2) → Virtual appliance → 10.10.1.4 (Firewall)
Spoke 2 route table: 10.20.0.0/16 (Spoke 1) → Virtual appliance → 10.10.1.4 (Firewall)
Both spokes’ peering to hub: Enable “Allow forwarded traffic”
Firewall: Must have rules allowing spoke-to-spoke communication

This pattern is called service chaining — traffic chains through the hub’s firewall. It’s the standard enterprise pattern for spoke-to-spoke with inspection.

The alternative is to enable “Allow forwarded traffic” on spoke-to-spoke peering and use UDRs through the hub’s NVA. But direct spoke-to-spoke peering is usually avoided in enterprise architectures because it bypasses the firewall.

Azure Virtual Network Manager (AVNM)

Managing peering manually works for 5-10 VNets. At Elena’s scale (15 countries, dozens of VNets), it becomes a nightmare. AVNM centralises network management.

☁️ Elena’s scenario: Skyline Logistics has 30 VNets across 5 regions. Manually creating peering between each pair would require hundreds of connections. AVNM automates this.

AVNM features:

Feature	What It Does
Network groups	Group VNets by criteria (subscription, tag, region, manual selection)
Connectivity configurations	Define topology (hub-and-spoke or mesh) for a network group
Security admin rules	Enforce security rules that override NSGs (covered in Domain 5)
Deployments	Apply configurations to target regions — changes are staged, then deployed

AVNM Hub-and-Spoke vs Mesh Topology
Feature	Hub-and-Spoke	Mesh
Pattern	All spokes connect through a hub VNet	Every VNet connects to every other VNet
Spoke-to-spoke	Through hub (direct spoke connectivity option available)	Direct — all VNets can reach all others
Gateway transit	Spokes can use hub gateway	No central gateway — each VNet manages its own
Centralised security	Firewall in hub inspects traffic	No central inspection point by default
Best for	Enterprise with shared services, inspection	Flat networks where every VNet needs direct access
AVNM option	'Direct connectivity' checkbox enables spoke-to-spoke without UDRs	Automatically creates peering between all members

Exam Tip: AVNM’s hub-and-spoke topology has an option called “Direct connectivity” that creates peering between spokes (bypassing the hub for spoke-to-spoke). This is different from manual hub-and-spoke where spoke-to-spoke requires UDRs through the hub firewall. The exam may test whether you understand this distinction. For networks with under 10 VNets, manual peering is often sufficient. AVNM shines at scale.

AVNM deployment model:

Create an AVNM instance (scoped to management group or subscriptions)
Define network groups (static membership or dynamic with Azure Policy)
Create connectivity configuration (hub-and-spoke or mesh)
Deploy to target regions (configurations only take effect after deployment)

Key Takeaways

VNet peering is non-transitive — spoke-to-spoke requires UDRs through an NVA or AVNM direct connectivity
Gateway transit shares the hub’s VPN/ER gateway with spokes
Both sides must configure peering independently
AVNM automates topology management at scale with hub-and-spoke or mesh configurations
AVNM configurations must be explicitly deployed to take effect

Test Your Knowledge

Question

Is VNet peering transitive?

Click or press Enter to reveal answer

Answer

No. If A peers with B and B peers with C, A cannot reach C through B by default. You need UDRs through an NVA (service chaining), AVNM direct connectivity, or additional peering.

Click to flip back

Question

What two settings enable gateway transit in hub-and-spoke?

Click or press Enter to reveal answer

Answer

Hub side: 'Allow gateway transit' — shares its gateway. Spoke side: 'Use remote gateways' — uses the hub's gateway instead of deploying its own.

Click to flip back

Question

What is AVNM's 'direct connectivity' option in hub-and-spoke?

Click or press Enter to reveal answer

Answer

It creates peering directly between spoke VNets, enabling spoke-to-spoke communication without routing through the hub. This bypasses the hub firewall — use with caution in security-sensitive environments.

Click to flip back

Question

Can you peer VNets across different Azure subscriptions?

Click or press Enter to reveal answer

Answer

Yes. Cross-subscription and cross-tenant peering is supported. Both sides must independently create their peering link, and appropriate permissions (Network Contributor) are required on both subscriptions.

Click to flip back

Knowledge Check

Ravi's Finance spoke needs to reach his HR spoke. Both spoke VNets peer with the hub. What's the recommended enterprise approach?

Knowledge Check

What happens when only one side of a VNet peering is configured?

Knowledge Check

Elena has 30 VNets across 5 regions. What's the most efficient way to manage peering?

Next up: Network Monitoring and Diagnostics — Use Network Watcher, Traffic Analytics, and Azure Monitor to find and fix network issues.