Hub-and-spoke network architecture

The hub and spoke model refers to a distribution method in which a centralized “hub” exists. It is a network design where we have a central device (the hub) that is connected to multiple other devices (the spokes). This is a cost-effective solution except the hub is a single point of failure.

Let’s deep dive into the aspects of the Hub and Spoke model.

Mục Lục

What is the Hub-Spoke Model?

The hub-spoke model, sometimes called the “shared services” model, relies on sharing connections between the hub component and each spoke component. Each spoke usually contains different SDLC tiers (Dev, Test, Stage, Prod). Although some companies have more complex models where different applications or clients live in separate accounts structure.

I have worked with this model mostly into cloud world with AWS and MicroSoft Azure which from implementation perspective is bit different and for sure more reliable solution in today’s world from network isolation and security perspective.

Let’s Look at Azure implementation

Microsoft Azure

If we look at above architecture it consists of the following aspects:

Hub virtual network: The hub virtual network is the central point of connectivity to your on-premises network. It’s a place to host services that can be consumed by the different workloads hosted in the spoke virtual networks

Spoke virtual networks: Spoke virtual networks are used to isolate workloads in their own virtual networks, managed separately from other spokes. Each workload might include multiple tiers, with multiple subnets connected through Azure load balancers.

Virtual network peering: Two virtual networks can be connected using a peering connection. Peering connections are non-transitive, low latency connections between virtual networks. Once peered, the virtual networks exchange traffic by using the Azure backbone without the need for a router.

Bastion Host: Azure Bastion lets you securely connect to a virtual machine using your browser and the Azure portal. An Azure Bastion host is deployed inside an Azure Virtual Network and can access virtual machines in the virtual network (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.

VPN virtual network gateway or ExpressRoute gateway. The virtual network gateway enables the virtual network to connect to the VPN device, or ExpressRoute circuit, used for connectivity with your on-premises network. For more information, see Connect an on-premises network to a Microsoft Azure virtual network.

VPN device. A device or service that provides external connectivity to the on-premises network. The VPN device may be a hardware device or a software solution such as the Routing and Remote Access Service (RRAS) in Windows Server 2012. For more information, see About VPN devices for Site-to-Site VPN Gateway connections.

Let’s Look at AWS implementation

My experience with AWS in designing the Hub-Spoke Network model is with 2 ways :-

With Multiple AWS Account

No alt text provided for this image

If we look at above architecture it consists of the following aspects:

Hub AWS Account: The hub aws account is the central point of connectivity to your prod and pre-prod aws accounts. It’s a place to host services that can be consumed by the different workloads hosted in the spoke virtual networks

Spoke AWS Account: Spoke virtual networks are used to isolate workloads in their own virtual networks, managed separately from other spokes. Each workload might include multiple tiers, with multiple subnets connected through Azure load balancers hosted within Hub AWS.

Transit Gateway:A transit gateway is a network transit hub that you can use to interconnect your virtual private clouds (VPCs) and on-premises networks. We have kept transit gateway within Hub AWS account and getting shared with Spoke account.

AWS Resource Access Manager: AWS RAM is helping us in sharing the transit gateway with Spoke accounts.

AWS LB:- These are ALBs which is getting shared from Hub to Spoke for load balancing the traffic coming from internet into Hub-Spoke.

VPN/Direct Connect Device: A device or service that provides external connectivity to the on-premises network. It can be AWS Direct Connect or any VPN [Cisco/PaloAlto or any..]

With Shared VPCs Account

No alt text provided for this image

If we look at above architecture it consists of the following aspects:

The hub-spoke model, sometimes called the “shared services” model, relies on VPC Peering connections between the hub VPC and each spoke VPC. Each spoke VPC usually contains different SDLC tiers (Dev, Test, Stage, Prod). Although some companies have more complex models where different applications or clients live in separate VPCs.

Design alternatives

Inter-spoke connectivity using a gateway in the hub VPC network
VPC Network Peering or Transit Gateway without a hub

If you don’t need centralized control over on-premises connectivity or sharing services across VPC networks, then a hub VPC network isn’t necessary

Multiple Shared VPC networks

Typical uses for the hub and spoke architecture

Many customers have workloads that are deployed in different environments. These environments include development, testing, and production. Many times, these workloads need to share services such as DNS, IDS, NTP, or AD DS. These shared services can be placed in the hub VNet/VPC. 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.

Benefits of Hub-Spoke Model

Isolate workloads while sharing common services. These services include identity and security.
Cost savings by centralizing services in a single location that can be shared by multiple workloads. These workloads include network virtual appliances and DNS servers.
Separation of concerns & modularity.
Scalability. Need to spin up or down a lower-level tier, or add an additional VPC? You can do so knowing that the additional VPC is connected to the Hub and central security requirements.
Compliance. It is often a compliance requirement to separate development and production environments (ex. SOC1 + 2). The hub-spoke model allows you to do this without duplicating security controls for each VPC.

Disadvantages of Hub and Spoke Model

There’s the issue of hub congestion, which can create bottlenecks.
Focusing too much on the central hub can cause you to unintentionally ignore other resources available.

Possible Solutions to Overcome Disadvantages

Planning and strategy can smooth out these issues in most cases.
I haven’t tried this solution , may be making Hub as HA can help us to solve the issue. HA can be within same account/vnet or multiple account.

Conclusion

Hub-Spoke is a good solution obtained within reasonable amount of time providing us flexibility to isolate network related issues as well as separation of responsibility between different teams.