Building AWS Network Architecture: A Guide to VPCs, Subnets, Route Tables, and Transit Gateways

Steve Ayeni — Sun, 13 Jul 2025 23:27:05 +0000

TRANSIT GATEWAY

What is transit gateway? AWS Transit Gateway is like a virtual traffic controller for cloud networks. Imagine you have multiple offices (VPCs), remote workers (on-prem systems), and cloud services all needing to talk to each other — instead of setting up separate phone lines between every pair, you use a central hub where everyone connects. That’s what Transit Gateway does: it brings all your networks together in one place, making it easier to manage traffic, scale your setup, and keep everything running smoothly — without the headache of tangled connections.

When managing complex cloud environments, simplifying network connectivity is a top priority. That’s where AWS Transit Gateway comes in—a fully managed, highly scalable service that acts as a central hub for connecting Amazon VPCs, on-premises data centers, and other AWS services. Instead of dealing with intricate VPC peering setups, Transit Gateway streamlines connectivity, making it easier to manage distributed and multi-region architectures while improving security and operational efficiency.

While AWS Transit Gateway has many powerful features, here are the ones that stands out:

A. Simplified Network Architecture: No more managing complex connections; Transit Gateway consolidates connectivity into a single hub.

B. Cross-Region & Hybrid Support: Seamlessly connect VPCs across different AWS regions and on-premises networks.

C. Centralized Security & Control: Apply consistent routing policies, access controls, and monitoring from a single point.

Steps taken to Connect 3 VPCs with Public Subnets, IGWs, Route Tables & Transit Gateway

1. Create 3 VPCs

VPC 1

VPC 2

VPC 3

2. Create 3 Public Subnets (one in each VPC)

Subnet 1 in VPC 1

Subnet 2 in VPC 2

Subnet 3 in VPC 3

3. Create 3 Internet Gateways (one per VPC)

IGW 1 attached to VPC 1

IGW 2 attached to VPC 2

IGW 3 attached to VPC 3

4. Create 3 Route Tables (one per VPC)

Route Table 1 for VPC 1

Route Table 2 for VPC 2

Route Table 3 for VPC 3

5. Associate Each Public Subnet with Its Route Table

Associate Subnet 1 with Route Table 1

Associate Subnet 2 with Route Table 2

Associate Subnet 3 with Route Table 3

6. Add Default Routes to Internet Gateways in Each Route Table

Route Table 1: 0.0.0.0/0 → IGW 1

Route Table 2: 0.0.0.0/0 → IGW 2

Route Table 3: 0.0.0.0/0 → IGW 3

7. Create a Transit Gateway (TGW)

Deploy Transit Gateway

8. Attach Each VPC to the Transit Gateway

TGW Attachment for VPC 1

TGW Attachment for VPC 2

TGW Attachment for VPC 3

9. Update Route Tables in Each VPC for TGW Routing

Route Table 1: Add routes for VPC 2 & VPC 3 CIDRs → TGW

Route Table 2: Add routes for VPC 1 & VPC 3 CIDRs → TGW

Route Table 3: Add routes for VPC 1 & VPC 2 CIDRs → TGW

10. (Optional) Enable DNS Resolution in TGW

11. Verify Connectivity

Test inter-VPC traffic via TGW

Test internet access via IGWs

What is a VPC (Virtual Private Cloud)?

A Virtual Private Cloud (VPC) is a private, isolated section of the AWS Cloud where you can launch resources (like EC2 instances, databases, and load balancers) in a logically defined virtual network. Think of it as your personal "cloud data center" with complete control over:

A. Network configuration (IP addressing, subnets, routing).
B. Security (firewall rules via security groups and network ACLs).
C. Connectivity (to the internet, other VPCs, or on-premises networks via VPN or Direct Connect).

Key components of a VPC:

A. Subnets – Segments of your VPC’s IP range (public/private).
B. Route Tables – Define traffic rules between subnets and external networks.
C. internet Gateway (IGW) – Allows public subnet resources to access the internet.
D. NAT Gateway – Enables private subnets to access the internet securely.
Security Groups & NACLs – Act as firewalls for instance-level and subnet-level traffic.
E. VPC Peering & Transit Gateway – Connects VPCs to each other or to on-premises networks

The VPC shots

Inside My VPCs: There are three public Subnets Waiting for Transit Gateway’s Magic

Subnets act like secure rooms in the VPC house - keeping different workloads separated yet connected in controlled ways. Public subnets face the internet.

Public-Subnet shots

Deploying Internet Gateways for All three public Subnets"

An Internet Gateway (IGW) lets the subnets communicate to the internet. Transit Gateway connects VPCs, but IGW handles outside access

Set Up for three Internet Gateways (One for Each Subnet)
Since each subnet needs internet access, I created three Internet Gateways (IGW)—one for each of my three subnets. Here’s how it works:

Created 3 Subnets

Subnet 1 (Public)

Subnet 2 (Public)

Subnet 3 (Public)

Attached an Internet Gateway to Each

IGW-1 → Subnet 1

IGW-2 → Subnet 2

IGW-3 → Subnet 3

Why Separate IGWs?

Ensures independent internet access for each subnet.

Avoids bottlenecks (though AWS IGWs scale, this design keeps traffic isolated).

The Internet gateway shots

Subnet Association

Subnet association links a subnet to a route table, defining how traffic enters/exits that subnet. Key Functions of Subnet Association are
Traffic Routing, it determines if the subnet is public (routes to an Internet Gateway) or private (routes to a NAT Gateway/TGW).

The Subnet-associations shots

Deploying route-table for the Vpcs and the subnets

A route table is a set of rules (routes) that determines how network traffic is directed within VPC and subnets. Think of it as a "traffic signboard" for your cloud network—it tells data packets where to go.

To enable internet access and Transit Gateway connectivity for of my three VPCs (10.2.0.0/16, 192.168.37.0/24, 172.25.6.0/24), your route tables should include:

Internet Access:

Route: 0.0.0.0/0 → Internet Gateway (IGW)
(Allows public subnets to reach the internet)

Transit Gateway (TGW) for Cross-VPC Traffic:

Route: 10.2.0.0/16 → TGW (VPC1 to others)

Route: 192.168.37.0/24 → TGW (VPC2 to others)

Route: 172.25.6.0/24 → TGW (VPC3 to others)

Local VPC Traffic:

Route: [VPC_CIDR] → local

The route-table shots

Transit-Gateway

To simplify and streamline connectivity between the three VPCs (10.2.0.0/16, 192.168.37.0/24, and 172.25.6.0/24), Implementation of AWS Transit Gateway (TGW) is required. Here’s why:

A. Seamless Communication Without Complexity: No more messy peering, instead of managing multiple VPC peering connections (which become complex as more VPCs are added), Transit Gateway acts as a central hub that all VPCs connect to.
., One Connection Point: Each VPC attaches once to the TGW—no need for separate links between every pair.

B. Simplified Routing
Single Route Table Control: Traffic between VPCs flows through the Transit Gateway, eliminating the need to update route tables in every VPC manually.

Easy Scaling: Adding future VPCs? Just attach them to the TGW—no reconfiguring existing connections.

C. Secure & Efficient
Centralized Security Policies: Apply consistent routing and security rules across all connected VPCs.

Reduced Overhead: No more managing individual peering requests or route updates.

The transit gateway/transit gateway attachment shots

Testing Connectivity: Using an EC2 Instance to Verify Communication among Servers

To confirm that my three VPCs (10.2.0.0/16, 192.168.37.0/24, and 172.25.6.0/24) are properly connected via Transit Gateway, create an EC2 instance in each of the VPC and cross ping among servers to verify connectivity.

Step 1: Launch an EC2 Instance (Ping Tester)
VPC: 10.2.0.0/16 (Main VPC)

Subnet: Public (to allow SSH access)

Security Group:

Allow SSH (Port 22) from my IP.

Allow ICMP (Ping) from the other VPCs’ private IP ranges.

Step 2: Prepare the Target Servers
Ensure the servers in the other VPCs (192.168.37.0/24 and 172.25.6.0/24) have ICMP (Ping) enabled in their security groups.

The below screenshots demonstrate the above illustrations

The eC2-Instance shots

Testing Private Server Connectivity via cross Ping!

DEV Community: Steve Ayeni