Azure Architecture Best Practices

Azure hub and spoke architecture is considered a best practice for several reasons:

The Azure hub and spoke architecture is a proven network topology for enterprise-scale cloud environments. Below are actionable best practices, real-life examples, and code snippets for DevOps Engineers and Cloud Architects.

1. Better Security

• Centralized Security Controls: Use the hub for shared services (firewall, VPN, Azure Bastion, etc.) and enforce NSGs and Azure Firewall policies centrally.

• Example:

resource firewall 'Microsoft.Network/azureFirewalls@2022-05-01' = {
  name: 'hub-fw'
  location: resourceGroup().location
  properties: {
    sku: { name: 'AZFW_VNet', tier: 'Standard' }
  }
}

• Best Practice: Route all spoke traffic through the hub for inspection and logging.

2. Improved Network Performance

• Optimized Routing: Use User Defined Routes (UDRs) to control traffic flow between spokes via the hub.

• Example:

resource "azurerm_route_table" "spoke" {
  name                = "spoke-rt"
  resource_group_name = azurerm_resource_group.spoke.name
  location            = azurerm_resource_group.spoke.location
}

resource "azurerm_route" "to-hub" {
  name                   = "to-hub"
  resource_group_name    = azurerm_resource_group.spoke.name
  route_table_name       = azurerm_route_table.spoke.name
  address_prefix         = "0.0.0.0/0"
  next_hop_type          = "VirtualAppliance"
  next_hop_in_ip_address = azurerm_firewall.hub.ip_configuration[0].private_ip_address
}

3. Simplified Management

• Centralized Logging and Monitoring: Deploy Log Analytics and Azure Monitor in the hub for all spokes.

• Example:

az monitor log-analytics workspace create --resource-group rg-hub --workspace-name law-hub
az monitor diagnostic-settings create --resource-id <spoke-vnet-id> --workspace law-hub --logs '[{"category": "AllLogs", "enabled": true}]'

• Best Practice: Use Azure Policy to enforce tagging, security, and compliance across all spokes.

4. Scalability

• Easily Add Spokes: Onboard new business units or environments by deploying new spokes without impacting the hub or other spokes.

• Example:

module spokeVnet 'spoke-vnet.bicep' = {
  name: 'spokeVnet1'
  params: {
    vnetName: 'spoke-vnet-1'
    addressPrefix: '10.1.0.0/16'
  }
}

• Best Practice: Use Infrastructure as Code (Bicep, Terraform) and CI/CD for repeatable spoke deployments.

5. Cost-Effective

• Shared Services: Centralize expensive resources (firewall, VPN, monitoring) in the hub to reduce duplication.

• Example:

# Deploy Azure Firewall once in the hub, share across all spokes
az network firewall create --name hub-fw --resource-group rg-hub --location westeurope

• Best Practice: Tag resources for cost allocation and use Azure Cost Management for chargeback.

Real-Life Scenario

A global retailer uses hub and spoke to:

• Centralize security (Azure Firewall, Bastion, VPN Gateway) in the hub

• Isolate dev, test, and prod workloads in separate spokes

• Route all internet and inter-spoke traffic through the hub for inspection

• Use IaC (Bicep/Terraform) and Azure DevOps for automated spoke onboarding

Common Pitfalls

• Not routing all traffic through the hub (missed inspection/logging)

• Manual spoke deployments (inconsistent configuration)

• Over-permissioned peering (avoid using 'Allow Gateway Transit' unless needed)

References

• Microsoft Azure Hub-Spoke Reference Architecture

• Azure Landing Zones

Joke: Why did the spoke get jealous of the hub? Because the hub was always at the center of attention!