Designing a Secure
Hub-and-Spoke Network.

In the early days of cloud adoption, many organizations started with "Flat Networks"—deploying resources into a single Virtual Network (VNet). While simple, this approach quickly collapses at scale. You end up with fragmented security checks, redundant VPN gateways for every new project, and no easy way to inspect traffic between workloads.

Enter the Hub-and-Spoke topology: the gold standard for enterprise network architecture in Azure. It decouples "shared services" (identity, connectivity, security) from "workloads" (apps, databases), allowing your network to scale securely.

In this guide, I break down the architecture I implemented in the Secure Hub-and-Spoke Network project.

1. The Architecture

The concept is analogous to an international airport. The "Hub" is the main terminal where all security checks (Passport Control/TSA) happen. The "Spokes" are the gates where the planes (workloads) actually sit. You can't fly from one gate to another without going through the terminal.

The Hub: Central Command

The Hub VNet acts as the central point of connectivity. It hosts:

• Azure Firewall: The central policy engine inspecting all traffic.
• VPN Gateway: Provides Site-to-Site (S2S) connectivity to on-prem and Point-to-Site (P2S) for remote users.
• Azure Bastion: Secure RDP/SSH access to VMs without exposing public IPs.
• Private DNS Zones: Centralized name resolution for internal resources.

The Spokes: Workload Isolation

Spoke VNets connect to the Hub using VNet Peering. Crucially, spokes do not peer with each other. This ensures that if a workload in Spoke A is compromised, the attacker cannot laterally move to Spoke B without passing through the Firewall in the Hub.

2. The "Default Routing" Problem

To enforce Zero Trust, we must ensure that ALL traffic—whether it's leaving the VNet to go the internet, or going to another VNet—passes through the Azure Firewall.

We achieve this by creating a Route Table and associating it with every subnet in the Spoke VNets. We define a route for `0.0.0.0/0` (all traffic) and set the Next Hop to the Firewall's internal IP.

// Bicep: Enforcing Traffic Inspection via UDR
resource routeTable 'Microsoft.Network/routeTables@2021-02-01' = {
  name: 'rt-spoke-to-hub'
  location: location
  properties: {
    disableBgpRoutePropagation: false
    routes: [
      {
        name: 'ToFirewall'
        properties: {
          addressPrefix: '0.0.0.0/0' // Capture ALL traffic
          nextHopType: 'VirtualAppliance' // Send to NVA (Firewall)
          nextHopIpAddress: firewallPrivateIp
        }
      }
    ]
  }
}

3. Layer 4 vs. Layer 7 Security

A common question is: "Why do I need Azure Firewall if I have Network Security Groups (NSGs)?"

NSGs (Layer 4)

NSGs are your basic "Port and Protocol" guards. They sit at the subnet or NIC level.
Example: "Allow traffic on TCP Port 443 from IP 10.0.0.5."
They are fast and cheap, but they are dumb. They don't know what is inside the packet.

Azure Firewall (Layer 7)

Azure Firewall is intelligent. It understands the application layer.
Example: "Allow traffic to 'github.com' but block 'gaming.com', even if both use Port 443."
It also performs TLS Inspection, stripping away encryption to check for malware inside HTTPS streams.

The Strategy: Use NSGs for coarse-grained filtering (e.g., blocking widely known bad ports) within the spoke, and use Azure Firewall for fine-grained, identity-aware inspection at the perimeter.

4. Hybrid Connectivity (Gateway Transit)

One of the biggest cost-saving features of this topology is Gateway Transit.

Instead of deploying a VPN Gateway in every single Spoke VNet (which costs ~$140/month each), we deploy one Gateway in the Hub. By enabling the `useRemoteGateways` flag in the VNet Peering configuration, all Spokes can piggyback on the Hub's gateway to talk to on-premises networks.

// Bicep: Spoke Peering with Gateway Transit
resource peeringHub 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2021-02-01' = {
  name: 'spoke-to-hub'
  parent: spokeVNet
  properties: {
    remoteVirtualNetwork: {
      id: hubVNet.id
    }
    allowForwardedTraffic: true
    useRemoteGateways: true // Critical: Use the Hub's VPN Gateway
  }
}

Conclusion

The Secure Hub-and-Spoke topology is heavily relied upon in regulated industries because it provides a single pane of glass for network security. By centralizing your egress and ingress points, you drastically reduce your attack surface and simplify the complexity of audit logs.

<< Return to Project Overview