Azure Hub and Spoke Architecture

Hub and Spoke

Hub and spoke is a networking model for efficiently managing common communication or security requirements. It also helps avoid Azure subscription limitations. Hub and spoke models help customers to isolate management components from production workloads It helps to bring all administrative services under one RG/Subscription for better management. Provides greater security and access controls. Using different subscriptions, helps customers isolate the cloud spending and helps to take measures to optimize the cost.

Why this approach

In traditional DC, it was always advised to separate the management network from the production network, this gives network segregation as well as less load on the production network. Any maintenance can be carried out without any hindrance to the production network. The same principles have been used on the Azure cloud.

• Efficient maintenance: Centralize services that can be shared by multiple workloads, like network virtual appliances (NVAs) and DNS servers. A single location for services will help IT to minimize redundant resources and management efforts.
• Overcoming subscription limits: Large cloud-based workloads might require using more resources than a single Azure subscription contains. Peering workload virtual networks from different subscriptions to a central hub can overcome these limits and IT can concentrate on creating a more secure environment for production Workloads.
• A separation of concerns: You can deploy individual workloads between central IT teams and workload teams
• Hub and spoke model: It helps customers to isolate management components from production workloads. It helps to bring all administrative services under one RG/Subscription for better management. Provides greater security and access controls
• Saving on costs: Using different subscriptions, helps customers isolate the cloud spending and helps to take measures to optimize the cost

Typical use cases

• Many customers have workloads that are deployed in different environments. These environments include development, QA, testing, and production. Many times, these workloads need to share services such as DNS, IDS, NTP, or AD DS (IT Services). These shared services can be placed in the hub vNet. That way, each environment is deployed to a spoke to maintain isolation.
• Workloads that don't require connectivity to each other, but require access to shared services.
• Enterprises that require central control over security aspects.
• Enterprises that require segregated management for the workloads in each spoke.
• An enterprise that requires segregated cost management.

Azure Hub and Spoke model - Architecture

The architecture consists of the following components.

• Subscriptions: Hub and spoke components will have different subscriptions.
• Resource Group: Hub and spoke components would be deployed in an individual resource group.
• Hub virtual network: It’s the central point of contact for both Azure and on-prem resources. It's a place to host all admin-related services that can be consumed by the different spoke virtual networks.
• Spoke virtual networks: Each spoke will host their own events, which will help us to isolate different workload environments (Dev, QA, Prod..etc). The virtual networks are managed separately from other spokes. Each workload might include multiple tiers, with multiple subnets connected through Azure load balancers.
• Virtual network peering: Spoke virtual networks would be connected to the hub using a peering connection. Peering connections are non-transitive, low-latency connections between virtual networks.
• Bastion Host: Azure Bastion allows us to connect to a virtual machine securing via using your browser and the Azure portal. An Azure Bastion host is deployed inside the hub virtual network and can access virtual machines in the VNet, or virtual machines in peered VNets.
• Azure Firewall: Azure Firewall is a managed firewall as a service. The Firewall instance is placed in its own subnet in the Hub.
• On-prem connectivity: Azure environment would be connected to on-prem via site-to-site VPN or Express route.
• Azure SQL VM: PAAS service from Azure, which enables you to use full versions of SQL Server in Azure without having to manage hardware. SQL Server virtual machines (VMs) also simplify licensing costs when you pay as you go.
• Azure Monitor: Monitoring service from Azure, which will help customers to actively or proactively remove any issues on Azure services.
• Azure Application Gateway: Designed specifically for web applications, it provides a web traffic load balancer that enables you to manage traffic to your web applications.

Reference Architecture

[Image reference taken from Microsoft Documentation]

Recommendations

• The hub and each spoke can be implemented in different resource groups and even different subscriptions
• When peering at different subscriptions, subscriptions can be associated with the same or different Azure Active Directory tenant. This flexibility allows for virtual networks from decentralized management of each workload while sharing services maintained in the hub
• Create a Gateway subnet with an address range of /27. This will provide us with 32 addresses to this subnet will help to prevent reaching gateway size limitations in the future
• If you need connectivity between the spoke, you can create another vNET peering between the spokes
• Another way of performing the connectivity is by deploying an Azure Firewall or other network virtual appliance. Then create routes to forward traffic from the spoke to the firewall or network virtual appliance, which can then route to the second spoke. In this scenario, you must configure the peering connections to allow forwarded traffic.
• Enable Azure log analytics to help us in troubleshooting.

Copyright Anupam Maiti. All rights reserved.