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!
The Webservers testing shots
Top comments (5)
Well explained
💡
Exquisite❤️
Well detailed, Steve🔥
well detailed 👌