Azure Network Topology Patterns

Azure network topology defines how virtual networks (VNets) are arranged and interconnected to support workloads, security, and connectivity requirements. The AZ-305 exam tests your ability to choose the right pattern based on business needs, cost, and operational complexity. The three primary patterns are hub-and-spoke, mesh (full or partial), and hybrid (connecting on-premises).

Hub-and-spoke is the most common pattern for enterprise workloads. The hub is a central VNet that hosts shared services such as Azure Firewall, VPN/ExpressRoute gateways, domain controllers, or jump boxes. Spoke VNets connect to the hub via VNet peering, and traffic flows through the hub for inspection or routing.

Mechanism: VNet peering establishes a low-latency, high-bandwidth connection between two VNets using the Microsoft backbone. Peering is non-transitive by default: if Spoke A is peered to Hub, and Spoke B is peered to Hub, Spoke A and B cannot communicate directly unless you explicitly enable gateway transit or add additional peerings. In hub-and-spoke, you enable 'Use remote gateways' on spoke peerings to allow spokes to use the hub's VPN/ExpressRoute gateway for hybrid connectivity. The hub typically uses a network virtual appliance (NVA) or Azure Firewall to inspect traffic between spokes.

Configuration:

Key Values:

In a full mesh, every VNet is directly peered to every other VNet. This pattern is suitable for scenarios requiring low latency between all pairs, but it does not scale due to peering limits and management overhead.

Mechanism: Each VNet must have a peering to every other VNet. Traffic flows directly without a central inspection point. To enforce security, you must apply NSGs or NVAs at each VNet boundary, which increases complexity.

Limitations:

Hybrid topology extends Azure VNets to on-premises datacenters via VPN (site-to-site) or ExpressRoute. This is often combined with hub-and-spoke: the hub hosts the gateway, and spokes use gateway transit.

VPN Gateway:

ExpressRoute:

Coexistence: VPN and ExpressRoute can coexist on the same gateway (using route-based VPN). Azure prefers ExpressRoute over VPN for the same routes. If both paths are available, traffic uses ExpressRoute.

Azure Virtual WAN (vWAN) is a managed service that simplifies large-scale hub-and-spoke and hybrid topologies. It provides a central hub that automatically connects spokes, branch offices (via VPN/SD-WAN), and ExpressRoute circuits.

Components:

Benefits:

Limitations:

Exam scenarios typically present requirements like: - "Multiple workloads need to share a common firewall and VPN gateway" -> Hub-and-spoke. - "Low latency between all VNets with fewer than 10 VNets" -> Full mesh (but hub-and-spoke often still preferred for manageability). - "Global presence with many branch offices" -> Virtual WAN. - "Isolated workloads that must not communicate" -> Separate VNets with no peering (or use NSGs).

Decision Factors:

Network Security Groups (NSGs): Applied at subnet or NIC level. In hub-and-spoke, apply NSGs on spoke subnets to filter traffic from hub and other spokes.

Azure Firewall: Stateful, managed firewall in hub. Supports FQDN filtering, threat intelligence, SNAT/DNAT. Deployed in a dedicated subnet (AzureFirewallSubnet).

User-Defined Routes (UDRs): Forced tunneling: route all internet-bound traffic through firewall or on-premises. In hub-and-spoke, create a route table in spoke subnets with 0.0.0.0/0 next hop to firewall IP.

BGP: Used with VPN and ExpressRoute gateways to propagate on-premises routes. In Virtual WAN, BGP is automatic between hub and spokes/branches.

Although Azure is GUI-based, you can use Azure CLI or PowerShell for verification:

# List VNet peerings
az network vnet peering list --resource-group MyRG --vnet-name HubVNet --output table

# Check effective routes on a NIC
az network nic show-effective-route-table --resource-group MyRG --name MyVMNic

# Verify VPN connection status
az network vpn-connection show --resource-group MyRG --name MyVPNConn --query 'connectionStatus'

# List ExpressRoute circuit status
az network express-route list --resource-group MyRG --query '[].{Name:name, Status:serviceProviderProvisioningState}'

Scenario 1: Multi-tier Application with Centralized Security

A financial services company runs a three-tier application (web, app, database) in separate spoke VNets. The hub contains Azure Firewall for inspection and a VPN gateway for branch office connectivity. The company requires that all internet-bound traffic goes through the firewall for logging. They also need to isolate the database tier from direct access from other spokes.

Configuration: Each spoke has UDRs pointing 0.0.0.0/0 to the firewall. NSGs on the database subnet only allow traffic from the app subnet (via private IPs). The hub firewall has rules to allow HTTP/HTTPS from internet to web tier, and SQL traffic from app to database. VPN gateway uses BGP to advertise on-premises routes.

Scale: 10 spokes, each with multiple subnets. The hub firewall handles ~5 Gbps throughput. Issues arise when developers add new spokes without updating UDRs, causing traffic to bypass the firewall. The solution is to use Azure Policy to enforce route table association.

Scenario 2: Global Enterprise with Virtual WAN

A multinational corporation with offices in 20 countries uses Azure Virtual WAN to connect all branches. Each region has a virtual hub with ExpressRoute circuits from local providers. Spoke VNets for regional workloads connect to the nearest hub. Hubs are interconnected via Microsoft backbone (hub-to-hub peering).

Benefits: Simplified management – no need to configure individual VPN tunnels for each branch. Centralized routing policies. The company uses Azure Firewall Manager to enforce security policies globally.

Problems: Cost – each hub incurs gateway costs. Latency for inter-region traffic is slightly higher than ExpressRoute Global Reach, but acceptable. Misconfiguration of custom route tables can cause blackholing; they rely on default routing.

Scenario 3: Hybrid Migration with Hub-and-Spoke

A healthcare provider migrates on-premises workloads to Azure. They set up a hub with ExpressRoute (1 Gbps) and a VPN gateway as backup. Spokes host different departments (HR, Finance, Clinical). Each spoke has its own private DNS zones. The hub hosts a jump box and management tools.

Challenge: Coexistence of VPN and ExpressRoute – BGP routes from both paths must be managed to prefer ExpressRoute. They use route-based VPN and set local preference BGP attribute on ExpressRoute connections. The migration takes 6 months, during which they maintain overlapping IPs by using site-to-site VPN with network address translation (NAT) on premises.

Failure case: During a test, a misconfigured UDR in a spoke sent traffic to a non-existent firewall IP, causing an outage. Recovery required deleting the route and re-associating the correct route table. They learned to use Azure Monitor alerts for route table changes.