Your new workload team files their first support ticket three weeks after go-live. A developer can’t reach the database. You pull the logs. The VM is making an outbound call to a public IP on port 1433—in plain text, no firewall inspection, straight out to the internet. You ask who approved that route. Nobody did. It just worked, because every VNet in the environment was managing its own egress.
That’s what flat networking at enterprise scale looks like from the inside: every team doing the reasonable thing locally, nobody seeing the full picture, and the blast radius of any mistake being the entire cloud environment.
The Hub-and-Spoke topology solves this by centralizing shared services—Azure Firewall, VPN/ExpressRoute Gateways, and DNS Resolvers—into a single “Hub” VNet. Application workloads live in “Spoke” VNets that peer back to the hub, sharing its connectivity while staying isolated from each other. This article walks through building the networking core of your landing zone using Azure Verified Modules (AVM).
1. The Hub Networking Stack
The hub VNet is the high-security gateway for your entire Azure region. In 2026, the retirement of “Default Outbound Internet Access” means a hub with a centralized firewall is no longer just a best practice—it is a requirement for resource connectivity.
The Hub Networking Stack
1.1: Mandatory Reserved Subnets
Azure enforces strict naming and sizing rules for hub services. Size all of these at /26 or larger to avoid downtime when services need to scale:
- AzureFirewallSubnet: The data plane for the firewall.
- AzureFirewallManagementSubnet: Required only if you enable “Forced Tunneling” to route management traffic separately.
- GatewaySubnet: For VPN or ExpressRoute gateways.
- AzureBastionSubnet: For the Bastion managed service.
Getting this wrong—say, a /27 for AzureFirewallSubnet—means an outage the day you try to scale the firewall. Size for growth now.
2. Deploying the Hub with Terraform AVM
Using AVM modules reduces the 500 lines of standard VNet/Firewall code into a few atomic blocks.
module "hub_vnet" {
source = "Azure/avm-res-network-virtualnetwork/azurerm"
version = "~> 0.7"
name = "vnet-prod-hub-001"
resource_group_name = "rg-prod-conn-001"
location = "eastus"
address_space = ["10.0.0.0/16"]
subnets = {
AzureFirewallSubnet = { address_prefixes = ["10.0.0.0/26"] }
GatewaySubnet = { address_prefixes = ["10.0.0.64/27"] }
AzureBastionSubnet = { address_prefixes = ["10.0.0.96/26"] }
}
}
module "firewall" {
source = "Azure/avm-res-network-azurefirewall/azurerm"
version = "~> 0.5"
name = "fw-prod-hub-001"
resource_group_name = "rg-prod-conn-001"
location = "eastus"
sku_tier = "Premium" # Required for IDPS and TLS inspection
# Link to the hub subnet
virtual_network_resource_id = module.hub_vnet.resource_id
}
3. Private DNS Resolution Flow
DNS is the most frequent source of post-deployment support tickets. In a hub-and-spoke model, centralize Private DNS Zones in the hub and use the Azure DNS Private Resolver to handle queries from both cloud and on-premises clients.
Private DNS Resolution Flow (Resolver Pattern)
Link your hub VNet to the Private DNS Zones, and configure your spokes to use the Hub’s Firewall or Resolver as their DNS server. That’s what makes resource.privatelink.blob.core.windows.net resolve to a private IP across your entire organization—not just in the subscription where the Private Endpoint lives.
4. VNet Peering and Gateway Transit
To connect a spoke to the hub, create a two-way peering. In an enterprise landing zone, enable Gateway Transit. This lets spoke VNets use the VPN or ExpressRoute gateway in the hub, so you don’t pay for an expensive gateway in every application subscription.
resource "azurerm_virtual_network_peering" "hub_to_spoke" {
name = "peer-hub-to-app01"
resource_group_name = module.hub_vnet.resource_group_name
virtual_network_name = module.hub_vnet.name
remote_virtual_network_id = var.spoke_vnet_id
allow_gateway_transit = true
}
5. Controlling Egress with User Defined Routes (UDR)
Peering a VNet to the hub does not automatically force traffic through the firewall. You must apply a Route Table to your spoke subnets with a default route (0.0.0.0/0) pointing to the Azure Firewall’s private IP. Without this, traffic bypasses your central security policy—quietly, with no error, and no log entry in the firewall.
Add the UDR in your Subscription Vending process. If a new spoke arrives without it, traffic will flow uninspected until someone notices.
Key Takeaways
- Centralize Egress: Use Azure Firewall Premium in the hub to inspect all outbound traffic and enforce FQDN filtering.
- Size for Growth: Use
/26for mandatory hub subnets to avoid future downtime during service scaling. - DNS is Global: Use the DNS Private Resolver to provide a unified namespace for cloud and on-premises developers.
- Automate Peerings: Include peering and UDR configuration in your Subscription Vending process to ensure new spokes are “Secure by Default.”
Next Steps:
- Read Identity and Access Architecture for Azure Landing Zones: Entra ID, RBAC, and PIM to design the Identity and RBAC model that will manage these network resources.
- Read Centralized Monitoring: Log Analytics, Diagnostic Settings, and Azure Monitor Workbooks to configure the centralized logging that will capture your Azure Firewall and DNS traffic.