Lab: Building a Scalable Hub-and-Spoke Network with AWS Transit Gateway

This hands-on lab guides you through architecting a scalable network using AWS Transit Gateway (TGW). You will connect two separate VPCs (Spoke A and Spoke B) through a central hub to enable transitive routing, a core requirement for the AWS Certified Solutions Architect - Professional exam.

[!WARNING] Remember to run the teardown commands at the end of this lab to avoid ongoing charges for Transit Gateway attachments.

Prerequisites

An active AWS Account.
AWS CLI installed and configured with Administrator access.
Basic knowledge of VPC CIDR blocks and Route Tables.
Region: We will use us-east-1, but you can substitute with your preferred region.

Learning Objectives

Provision a hub-and-spoke network topology using AWS Transit Gateway.
Configure VPC route tables to enable communication across the Transit Gateway.
Verify transitive connectivity between isolated workloads.
Understand the performance benefits of Transit Gateway over complex VPC peering meshes.

Architecture Overview

We will build a hub-and-spoke model where the Transit Gateway acts as the central router connecting two isolated VPCs.

Loading Diagram...

Step-by-Step Instructions

Step 1: Create Spoke VPCs

First, we need two VPCs with non-overlapping IP ranges.

bash

# Create Spoke VPC A
aws ec2 create-vpc --cidr-block 10.1.0.0/16 --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=brainybee-spoke-a}]'

# Create Spoke VPC B
aws ec2 create-vpc --cidr-block 10.2.0.0/16 --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=brainybee-spoke-b}]'

▶Console alternative

Navigate to

VPC > Your VPCs > Create VPC

. Use Name:

brainybee-spoke-a

and CIDR:

10.1.0.0/16

. Repeat for Spoke B with

10.2.0.0/16

Step 2: Provision the Transit Gateway

The Transit Gateway will serve as our regional network hub.

bash

aws ec2 create-transit-gateway --description "Hub for Spoke A and B" --tag-specifications 'ResourceType=transit-gateway,Tags=[{Key=Name,Value=brainybee-tgw}]'

[!TIP] Note the TransitGatewayId from the output; you will need it for the next steps.

Step 3: Attach VPCs to the Transit Gateway

We must "plug" our VPCs into the hub using TGW Attachments.

bash

# Attach Spoke A
aws ec2 create-transit-gateway-vpc-attachment \
    --transit-gateway-id <TGW_ID> \
    --vpc-id <VPC_A_ID> \
    --subnet-ids <SUBNET_A_ID>

# Attach Spoke B
aws ec2 create-transit-gateway-vpc-attachment \
    --transit-gateway-id <TGW_ID> \
    --vpc-id <VPC_B_ID> \
    --subnet-ids <SUBNET_B_ID>

Step 4: Configure VPC Routing

Even with an attachment, instances don't know where to send traffic. We must update the VPC Route Tables to point the CIDR of the other VPC to the Transit Gateway.

bash

# In VPC A's Route Table: Route to VPC B goes to TGW
aws ec2 create-route --route-table-id <RT_A_ID> --destination-cidr-block 10.2.0.0/16 --gateway-id <TGW_ID>

# In VPC B's Route Table: Route to VPC A goes to TGW
aws ec2 create-route --route-table-id <RT_B_ID> --destination-cidr-block 10.1.0.0/16 --gateway-id <TGW_ID>

Checkpoints

Verify TGW State: Run aws ec2 describe-transit-gateways. The state should be available.
Verify Attachments: Run aws ec2 describe-transit-gateway-vpc-attachments. You should see two attachments in the available state.
Ping Test: If you launch EC2 instances in both VPCs (with appropriate Security Groups allowing ICMP), a ping from 10.1.x.x to 10.2.x.x should succeed.

Visualizing the Route Logic

Below is a TikZ diagram representing the packet flow decision for an instance in VPC A trying to reach VPC B.

\begin{tikzpicture}[node distance=2cm] \draw[thick] (0,0) rectangle (3,1.5) node[pos=.5] {Instance A}; \draw[->, thick] (3,0.75) -- (5,0.75) node[midway, above] {Dst: 10.2.0.5}; \draw[thick] (5,-0.5) rectangle (8,2) node[pos=.5, align=center] {VPC A Route Table\Local: 10.1/16\TGW: 10.2/16}; \draw[->, thick] (8,0.75) -- (10,0.75) node[midway, above] {To TGW}; \draw[fill=blue!10] (10,-1) rectangle (13,2.5) node[pos=.5, align=center] {Transit\Gateway}; \end{tikzpicture}

Troubleshooting

Problem	Potential Cause	Fix
Ping Timeout	Security Group / NACL	Ensure SG allows inbound ICMP from the other VPC's CIDR range.
Attachment "Pending"	AWS internal provisioning	Wait 2-3 minutes; TGW attachments take longer than VPC creation.
Route "Blackhole"	Deleted TGW	Ensure the TGW ID in the route table still exists and is attached.

Stretch Challenge

Scenario: You need to provide internet access to both spokes through a single centralized Inspection VPC.

Create a third VPC called Inspection-VPC with an Internet Gateway.
Modify Spoke route tables to point 0.0.0.0/0 to the TGW.
Configure TGW route table to route default traffic to the Inspection-VPC attachment.

Cost Estimate

Transit Gateway (us-east-1): $0.05 per hour.
TGW VPC Attachment: $0.05 per hour per attachment (Total $0.10/hr for this lab).
Data Processing: $0.02 per GB processed by the TGW.
Estimated Total for 1 Hour: ~$0.15 (Free-tier does not cover Transit Gateway).

Concept Review

Feature	VPC Peering	Transit Gateway
Topology	Point-to-Point (Mesh)	Hub-and-Spoke
Transitive Routing	No	Yes
Scalability	Complex at scale (N*(N-1)/2)	Highly Scalable (up to 5000 VPCs)
Complexity	High (many peerings)	Low (central management)

Clean-Up / Teardown

To avoid ongoing costs, delete resources in this specific order:

Delete EC2 Instances (if any were created for testing).
Delete VPC Attachments:
bash
aws ec2 delete-transit-gateway-vpc-attachment --transit-gateway-attachment-id <ATTACH_ID_A> aws ec2 delete-transit-gateway-vpc-attachment --transit-gateway-attachment-id <ATTACH_ID_B>
Delete Transit Gateway:
bash
aws ec2 delete-transit-gateway --transit-gateway-id <TGW_ID>
Delete VPCs:
bash
aws ec2 delete-vpc --vpc-id <VPC_A_ID> aws ec2 delete-vpc --vpc-id <VPC_B_ID>