0Pricing
Cloud & IT Cert Prep · Lesson

Hub-and-Spoke Network Topology

Design a hub-and-spoke VNet topology with a shared hub for firewall, DNS, and VPN, and spoke VNets for individual workloads connected via VNet peering.

Hub-and-Spoke Network Topology is a free Cloud & IT Cert Prep lesson on CoddyKit — lesson 3 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Cloud & IT Cert Prep learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Introduction to Hub-and-Spoke

The hub-and-spoke network topology is the recommended Azure network architecture for enterprise environments. It consists of a central hub VNet that hosts shared networking services and multiple spoke VNets that host individual workloads. Spokes connect to the hub via VNet peering. This topology centralises security controls, reduces network complexity, and scales efficiently as new workloads are added.

The Hub VNet

The hub VNet is the central network that all spoke VNets connect to. It typically contains:

  • Azure Firewall — centralised outbound and east-west traffic inspection
  • VPN Gateway or ExpressRoute Gateway — on-premises connectivity
  • Azure Bastion — secure RDP/SSH access to VMs without public IPs
  • Azure DNS private zones — centralised private DNS resolution
  • Network monitoring resources — connection monitors and flow logs
# Create the hub VNet:
az network vnet create \
  --resource-group hubRG \
  --name hubVNet \
  --address-prefix 10.0.0.0/16 \
  --subnet-name AzureFirewallSubnet \
  --subnet-prefix 10.0.1.0/26

Spoke VNets and Their Workloads

Each spoke VNet hosts a single workload or a closely related set of workloads. For example: Spoke 1 — production web application; Spoke 2 — data analytics platform; Spoke 3 — dev/test environment. Isolating workloads in separate spokes provides a network boundary between them. If one workload is compromised, the attacker cannot directly pivot to another workload's VNet without going through the hub firewall.

# Create a spoke VNet:
az network vnet create \
  --resource-group spoke1RG \
  --name spoke1VNet \
  --address-prefix 10.1.0.0/24 \
  --subnet-name webSubnet \
  --subnet-prefix 10.1.0.0/25

VNet Peering Between Hub and Spokes

Hub and spoke VNets are connected via VNet peering, which provides private, low-latency connectivity without routing traffic through the public internet. You must create peerings in both directions: hub-to-spoke and spoke-to-hub. Spoke-to-spoke traffic is not routed directly — it travels through the hub, allowing the hub firewall to inspect and control inter-spoke communication.

# Create hub-to-spoke peering:
az network vnet peering create \
  --resource-group hubRG \
  --name hub-to-spoke1 \
  --vnet-name hubVNet \
  --remote-vnet spoke1VNet \
  --allow-gateway-transit true

# Create spoke-to-hub peering:
az network vnet peering create \
  --resource-group spoke1RG \
  --name spoke1-to-hub \
  --vnet-name spoke1VNet \
  --remote-vnet hubVNet \
  --use-remote-gateways true

Routing Through the Hub Firewall

By default, VNet peering does not force traffic through the Azure Firewall — it routes directly between VNets. To inspect spoke-to-spoke and spoke-to-internet traffic through the hub firewall, you must configure User Defined Routes (UDRs) in each spoke subnet that point the default gateway (0.0.0.0/0) to the firewall's private IP address. This ensures all outbound traffic from spokes is filtered by the centralised firewall.

# Create a route table that forces traffic through the hub firewall:
az network route-table create \
  --resource-group spoke1RG \
  --name spoke1RouteTable

# Add a default route pointing to the Azure Firewall private IP:
az network route-table route create \
  --resource-group spoke1RG \
  --route-table-name spoke1RouteTable \
  --name defaultRoute \
  --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address 10.0.1.4  # Azure Firewall private IP

Azure Firewall in the Hub

Azure Firewall in the hub VNet provides centralised network security for all spokes. It supports:

  • Network rules — allow or deny by IP, port, and protocol
  • Application rules — allow or deny by FQDN and HTTP category
  • DNAT rules — translate inbound public IPs to private backend IPs
  • Threat intelligence — block traffic to/from known malicious IPs and domains

A single Azure Firewall can serve all spoke VNets, reducing the cost and management overhead of deploying individual firewalls per spoke.

DNS in a Hub-and-Spoke Topology

Centralised DNS is critical in a hub-and-spoke architecture. Deploy Azure DNS private zones linked to the hub VNet, and configure spoke VNets to use the hub's DNS servers (or Azure-provided DNS with auto-registration). This ensures that VMs in all spokes can resolve each other's names and the names of Azure PaaS services via private endpoints using consistent DNS configuration.

# Create a private DNS zone and link to hub VNet:
az network private-dns zone create \
  --resource-group hubRG \
  --name privatelink.blob.core.windows.net

az network private-dns link vnet create \
  --resource-group hubRG \
  --zone-name privatelink.blob.core.windows.net \
  --name hub-dns-link \
  --virtual-network hubVNet \
  --registration-enabled false

On-Premises Connectivity via the Hub

A major advantage of hub-and-spoke is that on-premises connectivity is centralised in the hub. A single VPN Gateway or ExpressRoute Gateway in the hub VNet provides connectivity for all spoke workloads to reach on-premises systems. Spoke workloads do not need their own gateways — they access on-premises resources through the hub gateway via peering, significantly reducing cost and complexity.

Scaling the Topology

Hub-and-spoke scales naturally: adding a new workload means creating a new spoke VNet, peering it to the hub, and applying the UDR to route through the hub firewall. The hub services (firewall, gateway, DNS, Bastion) are shared across all spokes. Azure Virtual WAN is Microsoft's managed hub-and-spoke service that automates the peering, routing, and gateway management for very large deployments with many spoke VNets.

Hub-and-Spoke vs. Flat Network

A flat network (single large VNet with everything in subnets) is simpler to start but becomes difficult to manage and secure at scale. In a flat network, all workloads share the same address space with only NSGs separating them. Hub-and-spoke provides stronger isolation (VNet boundaries are harder to cross than NSG rules), centralised security controls, and clearer governance as each spoke can be managed independently.

Costs of Hub-and-Spoke

The main costs of hub-and-spoke beyond the workload resources are:

  • Azure Firewall — charged per deployment hour plus data processing fee
  • VPN/ExpressRoute Gateway — charged per gateway hour plus bandwidth
  • VNet peering — charged per GB of data transferred across peering links

Despite these costs, centralising services in the hub is usually cheaper than deploying separate firewalls, gateways, and DNS servers in each spoke individually.

Quick Check

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

Lesson Recap

In this lesson you learned: hub-and-spoke topology centralises shared networking services (firewall, gateway, DNS) in a hub VNet with workloads in separate spoke VNets; VNet peering connects spokes to the hub with UDRs routing traffic through the hub firewall; and it scales efficiently by sharing platform services across all spokes. Next up we explore enterprise identity and access design with RBAC and Privileged Identity Management.

Frequently asked questions

Is the “Hub-and-Spoke Network Topology” lesson free?

Yes — the full text of “Hub-and-Spoke Network Topology” is free to read here on the web, and the Cloud & IT Cert Prep course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Cloud & IT Cert Prep course, upgrade to CoddyKit PRO.

What will I learn in “Hub-and-Spoke Network Topology”?

Design a hub-and-spoke VNet topology with a shared hub for firewall, DNS, and VPN, and spoke VNets for individual workloads connected via VNet peering. You practise Cloud & IT Cert Prep with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Cloud & IT Cert Prep?

No prior experience is required. Cloud & IT Cert Prep on CoddyKit is structured for beginners through advanced learners; this is — lesson 3 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Hub-and-Spoke Network Topology” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Cloud & IT Cert Prep lesson?

Yes. Every Cloud & IT Cert Prep lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. Cloud Adoption Framework Overview
  2. Azure Landing Zones
  3. Hub-and-Spoke Network Topology
  4. Enterprise Identity and Access Design
← Back to Cloud & IT Cert Prep