At a time when cloud adoption is widespread, especially in large enterprises, it is essential to design a secure and maintainable network architecture.
This not only helps protect against external threats, but also avoids common issues for developers:
- inconsistently defined network access that can slow down development
- difficult evolutions and maintenance
- low resilience to network failures
- etc.
A quick overview of other architectures used in Azure
The Hub & Spoke architecture is far from being the only one in use. Here is a brief overview of the main architectures commonly used, along with their advantages and disadvantages.
The “simple” network
This architecture does not have a specific name as it is the simplest to implement on Azure.
The main building block used is Azure Virtual Network, which allows you to create a private virtual network interconnecting Azure resources, making them accessible only through authorized connections.
It is possible to create multiple private virtual networks to improve organization and achieve more granular access control.
The main advantage of this architecture is its ease of implementation, but it comes with several drawbacks, including:
- Each private virtual network must be configured individually, which often leads to duplicated configurations and naturally results in numerous errors, as well as poor maintainability.
- The need to configure everything can result in unwanted public access to these private networks.
- It is also difficult to control outbound traffic (private network → external).
The “full mesh” network
A core principle of this architecture is to create connection bridges between all existing subnets, much like a spider web.
The main advantage of this approach is its very high resilience: if one node fails, it does not disrupt communication between the remaining nodes.
One major limitation is that this architecture is difficult to maintain over time, especially for large networks: the number of connections required when adding new resources grows exponentially, following the formula n(n - 1)/2 where n represents the number of resources.
The Hub & Spoke architecture
General principle
The core idea behind this architecture is simple: it establishes a transit network that enables a unified network policy across the entire system, avoiding redundancy and allowing different policies depending on the application environment.
It is generally divided into two parts:
- A hub is the central private virtual network in this architecture, as it orchestrates and centralizes connections between spokes. It also serves to monitor and provide specific access.
- Spokes are private virtual networks interconnected through the hub: they do not communicate with each other without going through it. Their role is purely application-focused, hosting the actual resources (databases, application logic, API servers, queues, function apps, etc.).
To optimize latency between spokes caused by this mandatory routing through the hub, a VNet peering mechanism is often used. It consists of establishing private direct connections between two VNets, as if they belonged to the same network. In this case, to avoid direct connections between spokes, each peering links a spoke to the hub. User Defined Routes (UDRs) are then configured so that outbound traffic from spokes must pass through the hub—and especially its firewall—before reaching its destination.
The reason latency is improved is that traffic remains within the Azure network, without detouring through the internet or a VPN, enabling optimal routing between spokes and the hub.
Hub operation
To orchestrate and secure all connections, the hub must include several key components:
- Azure VPN Gateway: a VPN gateway service that ensures encrypted network traffic, particularly for client-to-Azure connections or on-premises to Azure connectivity, and vice versa. (see documentation)
- Azure ExpressRoute: an optional component that provides private connectivity between an on-premises network and Azure. In a Hub & Spoke architecture, it can replace Azure VPN Gateway and be shared at the hub level when hybrid connectivity is required.
- Azure Firewall: as the name suggests, it is a firewall used to define allowed and denied inbound and outbound connections. Spoke routing tables are configured so that their default route (0.0.0.0/0) passes through this central firewall, ensuring control over outbound traffic. It also supports a “next hop” mechanism toward an on-premises firewall, forcing outbound traffic to pass through it before reaching the internet. (see documentation)
- Azure Bastion: this service allows RDP or SSH connections to virtual machines in the spokes. It is typically deployed in the hub, as it receives HTTPS connections and then establishes RDP/SSH sessions toward target VMs. (see documentation)
- Shared services: it is common to host shared services in the hub, such as DNS, NTP, or Active Directory Domain Services (AD DS), to avoid duplication across spokes. (see documentation)
Spoke operation
Spokes also require several components to function within a Hub & Spoke architecture:
- Application resources: these are the main building blocks that support business needs—databases, queues, processing servers, virtual machines, etc. Communication between these components is both secure and simplified since they belong to the same spoke and therefore the same private virtual network.
- Azure Private Endpoint: this service creates a private network interface (with a private IP), removing public exposure and significantly reducing the risk of unauthorized external access, particularly from the internet. (see documentation)
- Network Security Groups (NSG): NSGs filter inbound and outbound traffic at the subnet or network interface level. In a Hub & Spoke architecture, they are typically used within spokes to reinforce workload isolation and allow only strictly necessary traffic between subnets, application components, and potentially the hub. They complement centralized filtering mechanisms like Azure Firewall by providing fine-grained control closer to the hosted resources.
Additional resources
In addition to core networking components, a Hub & Spoke architecture can integrate load balancing or publishing services such as Azure Application Gateway, Azure Load Balancer, Azure Front Door, or Azure Traffic Manager.
These components serve different purposes depending on whether the need is local, regional, or global load balancing, or application exposure to the internet. They are therefore not always positioned in the same place within the architecture. Some are located in spokes close to workloads, while others operate at a global front layer.
The following diagram shows a use case with Azure Application Gateway :
Advantages and disadvantages of the Hub & Spoke architecture
Advantages
- Security is centralized: everything is configured through the hub without duplication, addressing one of the main weaknesses of other architectures, namely redundant configurations.
- Similarly, ExpressRoute and VPN gateways are shared through the hub, eliminating the need to create one per virtual network.
- The separation into multiple spokes improves workload organization.
- It is very easy to create new spokes, as configurations are shared through the hub and Azure Virtual Network Manager.
- Resilience is strong, as a failing spoke impacts only its own workload, without affecting others.
Disadvantages
- Centralization around the hub makes it a critical component: if the hub fails, all spokes lose external connectivity.
- Manual routing configuration requires careful attention, as misconfiguration can allow unwanted traffic.
- Routing through the hub increases latency and requires a robust firewall, which adds cost and complexity.
- A single hub is less suitable for multi-region architectures, where latency and central dependency become problematic. A common approach is to deploy one hub per region or use Azure Virtual WAN for global connectivity. (see documentation)
