Hands-On with Azure Firewall: Hub-and-Spoke Architecture Deployment
Deploy Azure Firewall in a hub-and-spoke topology and force all VM traffic through it, then debug why network rules alone can't filter HTTPS and fix it with application rules.
IGBy infantus godfrey
Problem statement
Securing an Azure Virtual Network is often handled with Network Security Groups alone IP and port-level rules attached per NIC or subnet. That works for basic segmentation, but it breaks down once an organization needs centralized, Layer 7-aware control over what leaves its network: FQDN-based filtering, threat intelligence, TLS inspection, or a single place to see and manage outbound policy across many spokes.
NSGs are stateless and scoped per resource. They can't inspect HTTPS traffic by destination domain, can't apply threat intelligence, and don't give a security team one pane of glass across a hub-and-spoke estate.
The core question
How do you centralize outbound and inter-subnet traffic inspection for an Azure network with Layer 7 FQDN filtering, logging, and a single enforcement point without relying on per-resource NSG rules that don't scale and can't see application-layer traffic?
Why we need this realtime usecase
Azure Firewall vs. Network Security Groups
Aspect
Azure Firewall
Network Security Groups
OSI Layer
Layer 3–7 (stateful)
Layer 3–4 (stateless)
Scope
Protects entire subnets/networks
Protects individual NICs/subnets
State management
Maintains connection state
No state tracking
FQDN filtering
Full FQDN support with SNI
IP-based only
Threat intelligence
Built-in malware/botnet detection
None
Centralized management
Single pane via Firewall Manager
Individual rule management
Performance overhead
Single firewall instance for all traffic
Distributed, lower latency
Cost model
Pay for throughput
Pay per rule
Use case
Organization-wide security policy
Granular VM-level access control
Key rule: NSG rules are evaluated after Azure Firewall. If Azure Firewall allows traffic but the NSG blocks it, the traffic is blocked both layers must permit it for traffic to pass.
code
Internet → Azure Firewall → NSG → Virtual Machine
If traffic is blocked at any layer, it terminates there.
Architecture this use case builds
A separate VNet for the firewall (Hub)
A separate VNet for application resources (Spoke)
Azure Firewall, centralizing inspection between them
A virtual machine in the spoke, as the workload being protected
What this gains you
One enforcement point for outbound and inter-subnet traffic, instead of per-resource NSG rules
Layer 7 visibility: filtering by FQDN, not just IP and port
Built-in threat intelligence (and, on Premium, TLS inspection and IDPS)
A routing pattern hub-and-spoke with user-defined routes that scales to many spokes behind one firewall
Throughput up to 250 Mbps, unlimited concurrent connections, availability zones supported
L3–L7 stateful filtering, FQDN-based application rules, network rules with service tags, SNAT/DNAT, basic (alert-only) threat intelligence, full logging
Best for testing, development, and modest-traffic production workloads
Azure Firewall Standard - enterprise organizations, mission-critical workloads
Throughput up to 30 Gbps, 1 Gbps per flow, automatic autoscaling
Adds web categories, DNS proxy, active-blocking threat intelligence, 100+ service tags, FQDN tags, a policy analytics dashboard, multiple rule collection groups, outbound traffic control
Best for most enterprise deployments needing robust threat protection
Azure Firewall Premium - highly regulated industries, sensitive data
Throughput up to 100 Gbps, 10 Gbps per flow
Adds TLS/SSL inspection, IDPS, full-path URL filtering, enhanced web categories with SSL termination, east-west TLS inspection, advanced malware detection
Best for payment processors, healthcare, finance, and anyone handling regulated PII
Decision guide
Throughput under 250 Mbps → Basic
Throughput 250 Mbps–30 Gbps with standard threat protection needs → Standard
Throughput over 30 Gbps, or TLS/HTTPS payload inspection required → Premium
Use this approach when
You're moving from per-VM NSG rules to centralized, organization-wide traffic policy
You need to filter or block outbound HTTPS by destination domain (FQDN), not just IP and port
You're building or standardizing a hub-and-spoke network topology
You need a single place to view traffic logs and threat intelligence across your Azure estate
Compliance requires inspecting, not just routing, east-west or outbound traffic (Premium tier)
When this is not the right fit
A single VM or small flat network where NSGs already cover the access control you need Azure Firewall adds cost and complexity that a one-resource setup doesn't need
You need per-NIC or distributed, lowest-latency enforcement rather than a single centralized inspection point
You don't yet have (or plan to adopt) a hub-and-spoke topology the routing patterns in this lab assume one
Prerequisites for the lab
Accounts and access
An Azure subscription with rights to create VNets, subnets, route tables, a public IP, Azure Firewall (Standard SKU), and a virtual machine
Lab objective
Design and implement a production-style hub-and-spoke network topology using:
Azure Virtual Network
Azure Firewall (Standard SKU)
VNet peering
User-defined routes (UDR)
Traffic redirection through the firewall
This demonstrates controlled internet egress, centralized security inspection, and an enterprise routing pattern.