Hub-and-Spoke Topology with Azure Firewall - Deployment Guide with Terraform

Enterprise organizations frequently employ hub-and-spoke network architectures. This design streamlines network administration, enables centralized traffic inspection, and establishes a single connectivity gateway to and from the internet. In Azure, Azure Firewall is frequently the go-to solution for implementing such a centralized security model.

In this post, I'll walk through a simplified hub-and-spoke configuration where Azure Firewall manages both north-south (internet-bound) and east-west (inter-spoke) traffic filtering.

 

What is Hub and Spoke Topology?

A hub-and-spoke topology consists of a central hub serving as the primary connection point, with all other networks (spokes) connecting to it. In Azure, the hub hosts shared services — firewalls, VPN gateways, monitoring tools — while spokes contain workloads dependent on the hub for connectivity and security.

Key advantages:

• Simplifies management across multiple networks
• Centralizes shared services deployment
• Reduces operational complexity as scale increases
• Improves security posture through unified policy enforcement
• Enhances scalability — adding spokes doesn't require reworking multiple peerings

 

Azure Firewall as a Central Security Solution

Azure Firewall is a managed, cloud-native network security service controlling and logging traffic across Azure environments. In hub-and-spoke topologies, it serves as the enforcement point for both inbound/outbound connections and lateral spoke-to-spoke traffic.

Benefits of central firewall placement:

• Centralized traffic inspection with consistent policy enforcement
• Automatic scalability and built-in high availability
• Single location for rule management instead of per-spoke deployments
• Advanced threat protection via Threat Intelligence filtering, FQDN filtering, and Application Rules

 

Architecture

Network Configuration:

• Hub VNet: 10.0.0.0/16 containing AzureFirewallSubnet with dedicated public IP
• Spoke 1: 192.168.0.0/16 with subnet 192.168.1.0/24
• Spoke 2: 172.16.0.0/16 with subnet 172.16.1.0/24

Key Components:

1. VNet Peerings: Hub connects to each spoke with forwarded traffic enabled
2. User-Defined Routes: Each spoke subnet routes 0.0.0.0/0 to firewall private IP (Virtual Appliance)
3. Exception Routes: SSH access from specific external IPs bypasses firewall
4. Firewall Rules: Permit ICMP/TCP (22/80/443) between spokes and to internet
5. Testing VMs: Ubuntu VMs in each spoke with public IPs for connectivity testing

Result: Direct spoke-to-internet and spoke-to-spoke communication is blocked; all traffic routes through the firewall for inspection and logging.

 

The Hidden Challenge: Azure Firewall SNAT Port Exhaustion

A critical limitation worth knowing about: an Azure Firewall instance with a single public IP provides 2,496 SNAT ports per backend virtual machine, totaling approximately 4,992 ports with the default dual instances.

Scaling solutions:

• Attach up to 250 public IPs (expensive; operationally complex for external whitelisting)
• Integrate NAT Gateway for 64,512 ports per IP supporting up to 16 IPs (1+ million pooled ports)

This is something that often catches people off guard in production, so plan for it early if you expect significant outbound connections.

 

Try It Yourself

The complete Terraform code deploys this entire hub-and-spoke architecture with Azure Firewall — VNets, peerings, UDRs, firewall rules, and test VMs. A single terraform apply gets you a working lab.

Check out the full code at gergovadasz.hu.

---

Originally published on gergovadasz.hu. I write hands-on cloud networking guides with production-ready Terraform code for AWS, Azure, and GCP. Subscribe for more.