Network Topology & Outbound
Hub-spoke · Virtual WAN · Peering · NAT Gateway
Practice questions for this topic →
Decision table
| Need | Choose |
|---|---|
| Many regions and dozens of branch offices, Microsoft-managed transit | Virtual WAN |
| Two regions, third-party firewall NVA, lowest cost | Customer-managed hub-spoke |
| Connect and secure hundreds of VNets from one place | Azure Virtual Network Manager |
| Fixed or scalable outbound internet access for a private subnet | NAT Gateway |
| Zone-redundant outbound NAT | NAT Gateway StandardV2 |
| Force internet-bound traffic through a firewall in a Virtual WAN hub | Routing intent (internet traffic policy) |
| Spokes use the hub's VPN or ExpressRoute gateway | Gateway transit (allow on the hub, use remote gateways on the spoke) |
| Spoke A must reach spoke B through the hub | UDRs through the hub firewall or NVA (or Virtual Network Manager connectivity) |
| Two VNets with overlapping address spaces must peer | Not possible: re-address first |
Pick the topology from how many regions and branches you have, then pick the outbound method from the VNet's API version (see the new-VNet rule below).
Hub-spoke and peering
- Hub: a regional resource. Use one hub per region, holding the gateway and egress control.
- Peering is not transitive. Spoke A can't reach spoke B just because both peer with the hub. Route the traffic through the hub firewall or NVA with user-defined routes (UDRs).
- Gateway transit lets spokes use the hub's VPN or ExpressRoute gateway: allow it on the hub, use remote gateways on the spoke.
- Peering types: VNet peering in the same region; global peering across regions. Both run on the private Microsoft backbone, with no downtime, and work across subscriptions and tenants.
- Overlapping address spaces: peering needs non-overlapping ranges. Re-address first.
- Azure Virtual Network Manager: hub-and-spoke up to 1,000 spokes; mesh group up to 3,000 VNets. Network groups are populated manually or by Azure Policy.
- Default system routes: 0.0.0.0/0 goes to the internet unless you override it. Traffic to Azure services stays on the backbone.
Virtual WAN
- Transitive connectivity is managed by Microsoft: hubs are full-mesh in a Standard Virtual WAN.
- Routing intent sends internet and private traffic to the next hop declaratively, without hand-built UDRs. Each hub can have at most one internet routing policy and one private routing policy, each with a single next-hop resource.
- Valid next hops: Azure Firewall, a next-generation firewall or NVA, or a security SaaS solution deployed in the virtual hub.
- Internet Traffic routing policy: Virtual WAN advertises a default route (0.0.0.0/0) to all spokes, gateways and NVAs. The next-hop security solution inspects the traffic and then sends it to the internet.
Outbound access and NAT Gateway
- New virtual networks (API versions released after March 31, 2026) default to private subnets: VMs have no default internet access. Give them an explicit outbound method: a NAT gateway on the subnet, Standard Load Balancer outbound rules, or a public IP on the VM.
- Existing virtual networks aren't modified by this default change. A VNet created in 2024 keeps default outbound access.
- NAT Gateway: SNAT port exhaustion and a fixed outbound IP are its usual trigger. Standard throughput is up to 50 Gbps; StandardV2 up to 100 Gbps.
- StandardV2: zone-redundant, needs StandardV2 public IPs, and doesn't support BYOIP, Basic load balancers or Basic public IPs. Not available in Canada East, India South Central, Sweden South or West India.
- No in-place migration from Standard to StandardV2. The outbound IPs change, so plan the cutover.
- Reusing a load balancer's frontend IP: the Standard NAT gateway can take over the load balancer's frontend IP; StandardV2 can replace outbound rules but can't use that frontend IP.
Exam Tips
Tick each tip once you can answer it without looking.
“New VNet with no internet access, needs a fixed outbound IP” → NAT Gateway. Trap: Existing VNets aren't modified by the default change.
“Spoke to spoke through the hub, with inspection” → UDRs through the hub firewall. Trap: Peering isn't transitive.
“Many regions, dozens of branches, SD-WAN, Microsoft-managed transit” → Virtual WAN.
“Two regions, third-party NVA, lowest cost” → Customer-managed hub-spoke.
“Inspect all internet and private traffic in a Virtual WAN hub” → Routing intent.
“Spokes use the hub's VPN or ExpressRoute gateway” → Gateway transit.
“Peer VNets with overlapping address spaces” → Not possible: re-address first.
“SNAT port exhaustion or a fixed outbound IP” → NAT Gateway.
“Outbound NAT must survive a zone failure” → NAT Gateway StandardV2.
“Replace a Standard NAT gateway with StandardV2 for zone redundancy” → No in-place migration; outbound IPs change.
“Manage connectivity and security rules across hundreds of VNets” → Azure Virtual Network Manager.
“Route an internet-bound default route in Virtual WAN” → Internet Traffic routing policy advertises 0.0.0.0/0.
“Default outbound access on an existing 2024 VNet” → Still works; the change applies only to new VNets created with the newer API versions.
“Global peering across regions” → Private backbone, no downtime, across subscriptions and tenants.