VNet Peering & User-Defined Routes
VNets are isolated by design — so how do you connect them? VNet peering lets two VNets talk directly over Microsoft's backbone. User-defined routes give you fine-grained control over where traffic goes. Master both for the exam.
What is VNet Peering?
VNet peering is like building a private corridor between two separate office buildings so staff can walk directly between them.
By default, two VNets can’t talk to each other — they’re completely isolated. Peering creates a direct, high-speed connection between them using Microsoft’s backbone network. Traffic never touches the public internet. It’s fast, low-latency, and works across regions.
The catch: peering is NOT automatic. You must set it up on BOTH sides. And it’s not transitive — if Building A connects to Building B, and Building B connects to Building C, people in Building A can’t walk to Building C through B (unless you set that up too).
Types of peering
| Feature | Regional Peering | Global Peering |
|---|---|---|
| VNet location | Same Azure region | Different Azure regions |
| Latency | Same as within a VNet | Slightly higher (cross-region) |
| Bandwidth | No restrictions | No restrictions |
| Cost | Ingress and egress charges | Higher egress charges (cross-region) |
| Gateway transit | Supported | Supported |
| Use case | Multi-tier apps in same region | Disaster recovery, global apps |
Critical peering rules
- Peering must be created on BOTH VNets — create a peering link from VNet-A to VNet-B AND from VNet-B to VNet-A
- Address spaces cannot overlap — if both VNets use 10.0.0.0/16, peering will fail
- Peering is NOT transitive — if A peers with B and B peers with C, A cannot reach C through B
- You can’t peer a VNet with itself
- You can add peering to an existing VNet without downtime
Exam tip: Peering is NOT transitive
This is heavily tested. If VNet-A peers with VNet-B, and VNet-B peers with VNet-C, resources in VNet-A CANNOT communicate with VNet-C. You’d need to either create a direct peering between A and C, or use a hub-spoke topology with a network virtual appliance (NVA) or Azure Firewall in VNet-B to route traffic.
Think of it like phone calls — just because you have Alex’s number and Alex has Sam’s number doesn’t mean you can call Sam.
Gateway transit
Gateway transit allows a peered VNet to use the other VNet’s VPN or ExpressRoute gateway. This avoids deploying a gateway in every VNet.
How it works:
- The hub VNet has the VPN/ExpressRoute gateway and enables “Allow gateway transit”
- The spoke VNets enable “Use remote gateways” in their peering configuration
- Spoke VNets can then reach on-prem networks through the hub’s gateway
Real-world: TechCorp's hub-spoke design
TechCorp Solutions uses a hub-spoke topology:
- Hub VNet (10.0.0.0/16): Contains VPN gateway connecting to their on-prem datacentre, Azure Firewall, and shared services
- Spoke 1 (10.1.0.0/16): Production workloads, peered to hub with “Use remote gateways”
- Spoke 2 (10.2.0.0/16): Dev/test workloads, peered to hub with “Use remote gateways”
Both spoke VNets can reach on-prem through the hub’s VPN gateway — without needing their own gateways. Alex saved thousands in gateway costs.
User-Defined Routes (UDRs)
By default, Azure automatically routes traffic between subnets, to the internet, and to on-prem (via VPN). But sometimes you need to override this — that’s where UDRs come in.
How it works:
- Create a route table
- Add custom routes with a destination and next hop
- Associate the route table with one or more subnets
Next hop types
| Next Hop Type | What It Does |
|---|---|
| Virtual network | Routes within the VNet (default behaviour) |
| VNet gateway | Sends traffic to a VPN or ExpressRoute gateway |
| Internet | Routes traffic to the internet |
| Virtual appliance | Sends traffic to a specific IP (e.g., Azure Firewall, NVA) |
| None | Drops the traffic (black hole) |
The most common use case: forcing all internet-bound traffic through a firewall by creating a UDR with destination 0.0.0.0/0 and next hop as the firewall’s IP address.
Exam tip: UDRs override system routes
Azure has built-in system routes that handle default traffic flow. When you create a UDR, it takes precedence over the matching system route. The most specific route wins — a /24 route beats a /16 route for the same destination.
If traffic suddenly stops working after adding a route table, check whether a UDR is redirecting traffic to the wrong next hop or dropping it entirely (next hop type “None”).
Troubleshooting network connectivity
Azure provides tools in Network Watcher to diagnose routing and connectivity issues:
| Tool | What It Does |
|---|---|
| IP flow verify | Checks if traffic is allowed or denied by NSG rules |
| Next hop | Shows which route table entry a packet will use |
| Connection troubleshoot | Tests end-to-end connectivity between resources |
| Effective routes | Shows all routes (system + UDR) applied to a NIC |
| VPN troubleshoot | Diagnoses VPN gateway issues |
Real-world: Alex debugs a routing issue
After setting up a new UDR to route traffic through Azure Firewall, Alex notices the app tier VMs can no longer reach the database tier. He uses Network Watcher’s “Effective routes” tool on the app tier NIC and discovers the UDR is sending ALL traffic to the firewall — including intra-VNet traffic.
The fix: add a more specific route for the database subnet (10.0.3.0/24) with next hop “Virtual network” to keep intra-VNet traffic direct, while the broader 0.0.0.0/0 route still sends internet traffic through the firewall.
Knowledge check
Meridian Financial has three VNets: VNet-A peers with VNet-B, and VNet-B peers with VNet-C. A VM in VNet-A tries to reach a VM in VNet-C but fails. What should Alex do?
CloudFirst Labs wants all internet-bound traffic from their application subnet to pass through Azure Firewall (10.0.4.4). How should they configure this?
After adding a new route table to a subnet, Alex notices VMs in that subnet can no longer reach other VMs in the same VNet. Which Network Watcher tool should he use first?