In Microsoft Azure, networking strategy revolves around how you connect virtual networks (VNets) and how data actually travels between them. Understanding this is key to building a scalable, secure environment.
1. VNet Peering: The Fundamentals
VNet Peering connects two Azure Virtual Networks over the Microsoft backbone network. Once peered, the two networks behave as one for connectivity purposes.
- Regional Peering: Connects VNets within the same Azure region.
- Global Peering: Connects VNets across different Azure regions.
Key Characteristics:
- Low Latency: Traffic stays on the private Microsoft fiber; it never touches the public internet.
- Performance: Offers the same high-bandwidth connection as if the resources were in the same network.
- No Gateway Required: Unlike VPNs, peering doesn’t require a virtual network gateway unless you are “chaining” transit traffic.
2. Common Peering Strategies
Hub-and-Spoke Topology
This is the “gold standard” for enterprise architecture.
- The Hub: A central VNet that hosts shared services (Firewalls, ExpressRoute gateways, DNS).
- The Spokes: Individual VNets (e.g., for different departments or apps) that peer with the Hub.
- The Benefit: It centralizes security and reduces costs by sharing expensive resources like an Azure Firewall.
Mesh Topology
Every VNet is peered directly to every other VNet.
- Use Case: Small environments with very few VNets (3 or less).
- The Downside: It becomes a management nightmare as you scale, because peering is not transitive. If VNet A is peered with B, and B is peered with C, A and C cannot talk to each other unless you peer them directly or use a “Transit” setup.
3. Understanding Traffic Flow
How data moves depends heavily on your User Defined Routes (UDRs) and Gateway Transit settings.
Default Flow (Direct)
In a simple peering, traffic flows directly from VM-A to VM-B. Azure handles the routing automatically via “System Routes.”
Hub-and-Spoke with Transit
If you want Spokes to communicate with each other or the internet through the Hub, you must configure:
- Allow Gateway Transit: Set on the Hub peering.
- Use Remote Gateways: Set on the Spoke peering.
- Network Virtual Appliance (NVA): Usually a Firewall in the Hub. You must create a UDR on the Spoke subnets to “force” traffic to the Firewall’s IP address instead of letting it go direct.
Traffic Flow Table
| Scenario | Path | Logic |
| VNet A to Peered VNet B | Direct | System Route (Peering) |
| Spoke A to Spoke B | Spoke A → Hub (Firewall) → Spoke B | User Defined Route (UDR) |
| On-Prem to Spoke | On-Prem → Hub Gateway → Spoke | Gateway Transit enabled |
4. Crucial Constraints
- Overlapping Address Space: You cannot peer two VNets if their IP address ranges overlap.
- Transitivity: Peering is strictly 1:1. To move traffic “through” a VNet to another destination, you must use a Network Virtual Appliance (like Azure Firewall) or Azure Route Server.
In a multi-region Azure architecture, the strategy shifts from connecting individual workloads to connecting entire regional ecosystems. As of 2026, the industry standard has moved toward high-automation models to manage the complexity of cross-region routing.
There are two primary ways to architect this: Global Hub-and-Spoke and Azure Virtual WAN.
1. Global Hub-and-Spoke (Self-Managed)
In this model, you replicate the Hub-and-Spoke design in every region where you have a footprint and then link the hubs together.
The Strategy
- Regional Hubs: Each region (e.g., East US, West Europe) has its own Hub VNet containing a local Azure Firewall and Gateway.
- Hub Peering: You connect the Hubs using Global VNet Peering.
- Full Mesh vs. Chain: Ideally, all Hubs are peered to each other (Full Mesh of Hubs) to ensure the lowest latency and avoid “bottlenecking” through a third region.
Traffic Flow
- Inter-Region Spoke-to-Spoke: To go from Spoke A (Region 1) to Spoke B (Region 2), the traffic flow is:
Spoke A→Hub 1 (Firewall)→Global Peering→Hub 2 (Firewall)→Spoke B. - Routing Logic: This requires meticulous User-Defined Routes (UDRs) on every spoke subnet to ensure traffic knows the “Next Hop” is the local Hub Firewall for remote region ranges.
2. Azure Virtual WAN (Microsoft-Managed)
Virtual WAN (vWAN) is a managed networking service that replaces the manual Hub-and-Spoke with a “plug-and-play” global transit architecture.
The Strategy
- The Virtual Hub: Microsoft manages the Hub VNet for you. You don’t manage the underlying VMs or scaling; you just toggle features (VPN, ExpressRoute, Firewall).
- Automated Peering: When you connect a Spoke VNet to a Virtual Hub, the routing is automatically propagated.
- Any-to-Any Connectivity: By default, all spokes connected to any hub in the vWAN can talk to each other globally via the Microsoft backbone.
Traffic Flow
- Simplified Path: Traffic moves from a Spoke to its local Virtual Hub, which then uses the Global Mesh (automatically maintained by Azure) to reach a Spoke in another region.
- Managed Routing: You don’t need to write dozens of UDRs. The vWAN “Hub Router” handles BGP propagation across regions automatically.
Key Differences for 2026
| Feature | Global Hub-and-Spoke | Azure Virtual WAN |
| Effort | Manual (UDRs, Peering, NVA configs) | Managed (Point-and-click/Policy) |
| Transitivity | Not native (must use Firewall/NVA) | Native (Any-to-Any transit) |
| Scale | Limits at ~500 peerings per Hub | Scales to thousands of VNets |
| Cost | Cheaper for small, simple setups | Better ROI for large, complex global builds |
| Routing | Static (UDR-based) | Dynamic (BGP-based) |
Important Change: Default Outbound Access (March 2026)
As of March 31, 2026, Azure has retired “default outbound access” for new VNets. In a multi-region setup, you can no longer rely on VMs simply “finding” the internet.
The Strategy Update: You must now explicitly define an egress path. In a multi-region architecture, this is typically done by routing all regional internet traffic through the local Hub’s Azure Firewall or by attaching an Azure NAT Gateway to each spoke subnet for high-performance, non-inspected traffic.
Would you like to see a sample User-Defined Route (UDR) configuration for a cross-region Hub-and-Spoke setup, or are you leaning more toward the managed Virtual WAN approach?
Since you’re interested in the “how-to,” let’s look at the User-Defined Route (UDR) configuration for a cross-region Hub-and-Spoke setup. This is the manual way to “force” traffic through your security stack.
Scenario
- Region 1 (East US): Hub VNet (10.1.0.0/16) with a Firewall at 10.1.0.4.
- Region 2 (West US): Hub VNet (10.2.0.0/16) with a Firewall at 10.2.0.4.
- Spoke A (in East US): Subnet range 10.1.10.0/24.
1. The Route Table Logic
To get Spoke A (East US) to talk to a Spoke in West US, the packet needs instructions. Without a UDR, the packet will try to go directly via Global Peering, but if you have a Firewall, it will be blocked or dropped because there is no return path.
Example UDR for Spoke A (East US)
You would create a Route Table and associate it with the subnets in Spoke A:
| Route Name | Address Prefix | Next Hop Type | Next Hop Address | Purpose |
| To-West-US | 10.2.0.0/16 | Virtual Appliance | 10.1.0.4 | Sends West US traffic to the Local Hub Firewall first. |
| To-Internet | 0.0.0.0/0 | Virtual Appliance | 10.1.0.4 | Forces all web traffic through the Firewall (Egress). |
| Local-Spoke-Traffic | 10.1.10.0/24 | VNet Local | None | Keeps traffic within the same subnet local. |
2. The Traffic Flow (Step-by-Step)
When a VM in Spoke A (East US) sends a packet to Spoke B (West US):
- Source Check: The VM looks at its Route Table. It sees the
10.2.0.0/16prefix points to 10.1.0.4 (Local Hub Firewall). - First Hop: Packet travels to the East US Firewall. The Firewall inspects it against your Network Rules.
- Global Transit: The Firewall sees the destination is in West US. It sends the packet across the Global VNet Peering to the West US Hub.
- Second Hop: The West US Firewall receives the packet, inspects it again (if desired), and forwards it to the destination VM in the West US Spoke.
- Return Path: Symmetric routing is critical. The West US Spoke must have a mirrored UDR pointing East US traffic (
10.1.0.0/16) to the West US Hub Firewall (10.2.0.4).
3. Comparison: Manual UDR vs. Virtual WAN (vWAN)
If writing these tables for 50 spokes sounds like a headache, that’s exactly why Azure Virtual WAN exists.
| Feature | Manual Hub-and-Spoke (UDR) | Azure Virtual WAN |
| Routing Table | You manually create/update every UDR. | Automated. Routes are propagated via BGP. |
| Transit | You must configure NVAs/Firewalls to route. | Native. The Virtual Hub is a transit router. |
| Complexity | High (risk of “Route Leaks” or loops). | Low (Microsoft manages the routing mesh). |
| Scaling | Hard to manage beyond 10-15 VNets. | Designed for 100s of VNets globally. |
Pro-Tip: The “Gateway Subnet” Exception
Never associate a UDR with the GatewaySubnet in your Hub unless you are very experienced with BGP. Doing so can “break” the connection between your On-Premises VPN and your Azure VNets by creating circular routing loops.
Given the complexity of managing cross-region UDRs, are you currently leaning toward building this manually for more granular control, or does the automation of Virtual WAN sound like a better fit for your scale?
Infra Cloud Solutions 