☁️ Azure Network Cheatsheet

🌐 Virtual WAN Resource

The top-level container that holds all virtual hubs. One vWAN resource per organization is typical, with multiple hubs deployed across regions for global connectivity.

🏗️ Virtual Hub

A Microsoft-managed VNet in a region. Acts as the central routing engine. Contains gateways (S2S VPN, P2S, ExpressRoute) and connects VNets as spokes. Default throughput: 3 Gbps, scalable up to 50 Gbps.

🔗 Connections

VNets, VPN sites, ExpressRoute circuits, and P2S users connect to the hub via connections. VNet connections replace traditional peering — no manual peering needed.

🛣️ Hub Routing

Automated any-to-any transit between all connections (VNets, branches, users). Supports custom route tables for segmentation and isolation (e.g. isolating dev from prod).

🎯 What is Routing Intent?

A declarative way to tell the vWAN hub: "send all Internet traffic and/or all private traffic through my security solution". No manual route tables, no UDRs — the hub automatically programs the correct routes for all connections (VNets, branches, users).

📋 Two Routing Policies

Internet Traffic Policy — Hub advertises 0.0.0.0/0 to all connections. All internet-bound traffic flows through Azure Firewall / NVA / SaaS security in the hub before reaching the internet.

Private Traffic Policy — All east-west traffic (VNet-to-VNet, branch-to-VNet, inter-hub) flows through the security solution. Full inspection of private traffic across the entire topology.

✅ Why use it?

• Simple — No manual route tables or propagation config. Declare your intent, the hub handles the rest
• Effective — Guarantees all traffic is inspected. No risk of misconfigured routes creating bypass paths
• Extensible — Works with Azure Firewall, third-party NVAs, and SaaS security solutions. Add hubs or connections without reconfiguring routing
• Multi-hub — Policies apply per hub but work across inter-hub links for global security enforcement

🚫 Disable Gateway Route Propagation on Spokes

When a VPN/ExpressRoute gateway is in the Hub, it propagates BGP-learned on-premises routes to all peered VNets. If propagation is enabled on Spoke subnets, on-prem traffic bypasses the NVA because the BGP route is more specific than 0.0.0.0/0. Always set disable_bgp_route_propagation = true on Spoke route tables.

🔥 NVA must have IP Forwarding enabled

The NVA's NIC(s) must have IP forwarding enabled in Azure (NIC setting) and in the OS (kernel). Without this, Azure drops packets not destined for the NVA's own IP. For Azure Firewall, this is handled automatically.

🔗 Peering: "Use Remote Gateway" on Spokes

On the Spoke-to-Hub peering, enable use_remote_gateways = true. On the Hub-to-Spoke peering, enable allow_gateway_transit = true. This lets Spokes use the Hub's VPN/ExpressRoute gateway without deploying their own.

📋 Services that typically need this exception

• Application Gateway — needs direct internet for health probes (GatewayManager) and public listeners
• API Management — management plane requires internet access (port 3443)
• AKS (public) — kube API server and image pulls from public registries
• Azure Bastion — control plane needs internet for management
• Any service with public IP exposure — inbound internet traffic cannot pass through the NVA

🛣️ Why RFC1918 routes to NVA?

The 3 RFC1918 routes (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) cover all private address space — Azure VNets, on-premises networks, and other Spokes. This ensures that even without 0.0.0.0/0 pointing to the NVA, all east-west and hybrid traffic is still inspected. Only internet-bound traffic bypasses the NVA.

1️⃣ ExpressRoute Circuit

A logical connection between your on-premises network and Microsoft's edge, provisioned through a connectivity provider at a peering location. Defined by a bandwidth tier (50 Mbps to 100 Gbps with ExpressRoute Direct) and a SKU (Local, Standard, Premium).

Peering types:

• Private Peering — access to Azure VNets (IaaS/PaaS via private IPs)
• Microsoft Peering — access to Microsoft 365, Azure PaaS public endpoints

2️⃣ ExpressRoute Gateway

A virtual network gateway deployed in the GatewaySubnet of your Hub VNet. It terminates the ExpressRoute connection on the Azure side. Can coexist with a VPN Gateway in the same GatewaySubnet for redundancy.

Gateway SKU determines throughput, number of circuits, and VM connections (see table below).

3️⃣ Connection

The link between the Gateway and the Circuit. A single circuit can be connected to gateways in multiple VNets (up to the SKU limit). A single gateway can connect to multiple circuits. Each connection represents one logical link.

In Terraform: azurerm_express_route_circuit → azurerm_virtual_network_gateway_connection → azurerm_virtual_network_gateway

📐 Subnet-level association

NAT Gateway is assigned per subnet. All resources in that subnet use the NAT Gateway for outbound. It overrides LB outbound rules and default outbound access. However, instance-level public IPs take precedence over NAT Gateway — a VM with its own PIP will use that PIP for egress.

🔢 Up to 16 Public IPs

Attach up to 16 public IPs or a public IP prefix for a maximum of ~1 million concurrent SNAT ports. Azure distributes flows across all IPs automatically.

⚡ No SNAT exhaustion

Unlike LB outbound rules, NAT Gateway dynamically allocates SNAT ports on demand (up to 64k per IP). Eliminates the classic SNAT port exhaustion problem that plagues Load Balancer-based egress.

🔒 Outbound-only

NAT Gateway provides outbound and return traffic only. It does not allow unsolicited inbound connections. For inbound, use Load Balancer, Application Gateway, or instance-level PIPs.

🔗 Centralized Private DNS Zones

Create Private DNS Zones in the Hub/Connectivity subscription and link them to Spoke VNets. Never duplicate zones across subscriptions.

🔄 Conditional Forwarders

Use Azure Private DNS Resolver to resolve Azure names from on-premises, and on-premises names from Azure. No more custom DNS VMs needed.

🧩 DNS Private Resolver — Architecture

Deploy the Resolver in a dedicated Spoke VNet (or Shared Services Spoke). It requires two dedicated subnets: one for the inbound endpoint (on-prem → Azure resolution, min /28) and one for the outbound endpoint (Azure → on-prem forwarding, min /28). Link the Resolver's VNet to all Private DNS Zones so inbound queries can resolve Private Endpoint records.

📨 Resolver — Forwarding Rulesets

Create DNS forwarding rulesets on the outbound endpoint to forward specific domains (e.g. corp.local) to on-premises DNS servers. Rulesets can be linked to multiple VNets — no need to configure DNS settings per VNet. Point Spoke VNets' DNS settings to the Resolver inbound endpoint IP.

🏷️ Naming Convention

Private DNS Zones for Private Endpoints follow the format privatelink.{service}.{domain}. Don't change the names — Azure expects them exactly.

⚠️ Auto-registration

DNS auto-registration only works for VMs. A VNet can only have auto-registration enabled for one Private DNS Zone (but a zone supports up to 100 VNets with auto-registration). Use it in the Shared Services Spoke for shared VMs.

🌍 Split-Brain DNS

When you enable a Private Endpoint, public resolution still works for clients not connected to the VNet. The Private DNS Zone only overrides for clients within the linked VNet.

📊 Key Zones to Know

privatelink.blob.core.windows.net
privatelink.database.windows.net
privatelink.vaultcore.azure.net
privatelink.azurewebsites.net
privatelink.azurecr.io

📡 Centralize diagnostics

Enable Diagnostic Settings on all critical network resources (Firewall, VPN/ER gateways, Application Gateway, Front Door, Bastion, DDoS) and send logs/metrics to Log Analytics.

🔍 Keep flow visibility

Use Virtual Network Flow Logs for traffic visibility and investigation. Build workbooks for top talkers, denied flows, and unexpected east-west traffic paths.

🚨 Build an alert baseline

Create alerts for tunnel down events, gateway connection failures, firewall health degradation, App Gateway unhealthy backends, and DDoS mitigation activation.

🧪 Use Network Watcher tools

Standardize troubleshooting with Effective Routes, Next Hop, IP Flow Verify, Connection Troubleshoot, and Packet Capture before escalating incidents.

🛡️ Govern with Azure Policy

Use policy to enforce baseline controls (for example: approved regions/SKUs, mandatory diagnostic settings, restricted public exposure). Track compliance drift continuously.

📘 Operate with runbooks

Maintain runbooks for recurring scenarios: route leaks/asymmetry, DNS resolution failures, Private Endpoint outages, VPN/ER failover, and emergency egress controls.

🏗️ Hub-and-Spoke as Foundation

The Hub VNet should contain only networking infrastructure (Firewall, Gateway, Bastion). Shared services go in a dedicated Spoke. Consider one Spoke per service/usage to simplify filtering, NSG rules, and segmentation.

📐 Size Large from Day One

Use /21 for the Hub, /22 for Spokes. Subnets cannot be resized with resources deployed. Always plan 2x your initial need.

🚫 No CIDR Overlap

Plan your address space before creating the first VNet. Consider on-premises and other clouds. Overlapping CIDRs block peering and routing.

🔒 NSG on Every Subnet

Even with a firewall, apply NSGs to all subnets (except GatewaySubnet and FirewallSubnet). Defense in depth principle. Use Application Security Groups to simplify rules.

📡 Accelerated Networking

Enable Accelerated Networking on all VMs that support it. It's free and reduces latency by 50%+. Nearly all SKUs with ≥ 2 vCPUs support it.

🔄 NAT Gateway for Egress

Prefer NAT Gateway over individual public IPs for outbound traffic. Provides a stable outbound IP, more SNAT ports, and avoids Load Balancer SNAT port exhaustion.

📊 Enable Network Watcher

Enable Network Watcher in every used region. Configure VNet Flow Logs (successor to NSG Flow Logs) to a Storage Account + Log Analytics for auditing and troubleshooting.

🏷️ Naming Convention

Follow the CAF: vnet-{workload}-{region}-{env}, snet-{purpose}, nsg-{subnet}, rt-{subnet}. Consistent naming prevents production mistakes.

🔐 MTU & Fragmentation

Azure MTU is 1,500 bytes for inter-VNet/peering traffic. Don't rely on jumbo frames cross-VNet. Ensure firewalls don't block ICMP "Fragmentation Needed" messages.

🔁 Availability Zones for networking

Deploy zone-redundant resources wherever possible: VPN Gateway (AZ SKUs), Azure Firewall, Application Gateway, Load Balancer. Zone-redundant deployment survives a full AZ outage with no downtime.

🔍 Use Azure Firewall Manager

For multi-hub or multi-region deployments, centralize firewall policy management with Azure Firewall Manager. One policy, multiple firewalls. Works with both custom hubs and Virtual WAN secured hubs.

📋 Document your IP plan

Maintain a living IP address plan that covers all VNets, subnets, on-premises ranges, and reserved ranges. Review it before every new VNet or peering. Use a spreadsheet, IPAM tool, or Azure IPAM.