Hub-Spoke Network Architecture in Azure

The hub-spoke topology is a network design pattern that uses a central hub virtual network (VNet) to manage connectivity and security for multiple spoke VNets. This architecture provides a scalable and manageable way to connect workloads across Azure and to on-premises environments.

Key Components

• Hub VNet: This central VNet acts as a central point for connectivity. It typically houses shared services like firewalls, network virtual appliances (NVAs), VPN gateways, and ExpressRoute circuits.
• Spoke VNets: These VNets are connected to the hub VNet. They host individual workloads, such as applications, databases, or development/testing environments.
• VNet Peering: Spoke VNets are connected to the hub VNet using VNet peering. This allows traffic to flow between them without needing to traverse the internet.
• Gateway Transit: To allow spokes to communicate with on-premises networks or other spokes via the hub's gateway, gateway transit must be enabled on the VNet peering connection from the spoke to the hub.
• Forwarded Traffic: The hub VNet is responsible for routing traffic between spokes and between spokes and on-premises networks. This is typically achieved using Azure Firewall or NVAs within the hub.

Benefits of Hub-Spoke

• Centralized Security: Security policies and appliances (like firewalls) are deployed and managed in the hub, providing a single point of inspection and control for all traffic.
• Simplified Management: Network management is consolidated, reducing complexity and operational overhead.
• Scalability: New spokes can be added easily without impacting existing network configurations.
• Cost-Effectiveness: Shared services in the hub are used by multiple spokes, potentially reducing redundant infrastructure.
• Workload Isolation: Each spoke VNet can be isolated, providing granular control over access and communication.

Implementing Hub-Spoke

1. Design the Hub VNet

Plan the address space for your hub VNet, ensuring it doesn't overlap with any connected spoke or on-premises networks. Deploy shared services like Azure Firewall or NVAs.

2. Create Spoke VNets

For each spoke VNet, define its address space and deploy the workloads. Ensure no IP address conflicts.

3. Establish VNet Peering

Create peering connections from each spoke VNet to the hub VNet. Crucially, enable Gateway Transit on the spoke-to-hub peering and Allow Gateway Transit on the hub-to-spoke peering.

4. Configure Routing

Use User Defined Routes (UDRs) on spoke subnets to force traffic through the hub's firewall or NVAs for inspection and routing. The hub's routing will then direct traffic to its destination.

# Example of creating a UDR to route traffic to a firewall in the hub
az network route-table create --resource-group MyResourceGroup --name SpokeRouteTable

az network route-table route create --resource-table-name SpokeRouteTable \
    --resource-group MyResourceGroup --name ToHubFirewall \
    --address-prefix 0.0.0.0/0 \
    --next-hop-type VirtualAppliance \
    --next-hop-ip-address <HUB_FIREWALL_PRIVATE_IP>

az network subnet update --resource-group MyResourceGroup --vnet-name MySpokeVNet \
    --name MySpokeSubnet --route-table MyResourceGroup/SpokeRouteTable
            

5. Deploy Shared Services

Deploy services like Azure Firewall, Azure Load Balancer, or NVAs in the hub to manage traffic flow, security, and other shared network functions.

Considerations

• Address Space Planning: Careful planning of IP address spaces is critical to avoid overlaps and ensure seamless connectivity.
• Security: Implement robust security rules on firewalls and Network Security Groups (NSGs) to control traffic flow.
• Performance: Consider the impact of traffic inspection and routing on latency. For performance-sensitive workloads, optimize routing and consider dedicated network appliances.
• High Availability: Design for high availability by deploying redundant instances of shared services in the hub.