Hub and Spoke Network Model

Introduction

A hub and spoke network architecture, also known as shared-services model is a system where traffic moves between central hub and peripheral spokes. This model is efficient for managing traffic flows.

Imagine a bicycle tyre, the main area of tyre represents the central hub that provides structural support and contains critical components. It is the most load bearing and provides structural integrity to the entire system. The spokes extend outwards from hub and represent the various elements required to contribute to the overall functionality.

How it works:

It is a centralized network management system. We place all new shared network resources at the central location, and all peripheral locations and networks communicate with this central architecture to access different services/resources while operating independently in their own network premises.

In a multi-account scenario, the spokes are connected to several distinct hubs separated by functionality domain. These hubs are then linked to the on-premises server.

If there are more than 2 VPCs (Virtual Private Cloud), using normal methods for connections can get complicated. In such cases, it is recommended to utilize the hub and spoke network architecture. This is made easier with transit gateways.

By connecting each VPC/VPN to the transit gateway, traffic can be routed continuously to and from them.

Another common practice is VPC peering connections. However, as the network becomes more interconnected, the risk of exposure increases.

For example, in an organization with 10,000 VPCs, maintaining numerous peering connections can be cumbersome and pose risks to the network. Therefore, connecting through a transit gateway is a more optimal solution.

Advantages of Hub and Spoke Network Model:

• Isolation: It helps us set up separate development and production environments.

• Flexibility: If there is a need to change something in the architecture, since it is distinctly separated, we can modify only what is necessary without impacting the rest. Spokes can easily connect and disconnect from the central hub as required. This offers flexibility for dynamic workloads.

• Scalability: This model helps organizations to scale services and resources more efficiently.

• Compliance: Helps attain PCIDSS and HIPAA compliance requirements.

• Security and Monitoring: The centralized architecture helps in easy enforcement of security policies, and we can attain monitoring across the entire network.

• Performance Optimization: Organizations can optimize network performance and reduce latency.

• Cost efficiency: Centralizing helps reduce redundant resources at spoke locations. If a resource is not needed for a specific period, we can easily modify that resource at the spoke without changing the entire network flow.

Basic Implementation requirements in AWS :

• Hub: One master account VPC that will act as our central hub.

• Spokes: Multiple child account VPCs that will act as spokes. These can represent different environments, resources, functionality, etc.

• Network elements:

  We will need network elements such as VPCs, VPN, route tables, transit gateway, security groups, and network ACLs.

• AWS CloudFormation Stack Sets:

  The entire architecture can be easily deployed using CloudFormation stack sets.

  It executes a template/script according to our architecture from one account into multiple accounts and regions, making the deployment centralized and convenient.

• AWS S3 bucket:

  The CloudFormation Script can be stored in an S3 bucket, and we can upload directly from there.

• IAM:

  Provide administrator rights.

  Create separate roles and policies depending on the requirement to control access.

• CloudWatch Metrics and Logs:

  To continuously monitor the logs and raise alerts in case of unwanted scenarios.

  Track performance utilization across VPCs.

• Config and CloudTrail:

  Track changes in network configurations. Help maintain security and compliance via config rules.