VPC Networking Transit Gateway Routing

Hub-and-Spoke Networking with AWS Transit Gateway

By Jake Collyer•Focus: AWS SAA-C03 Core Networking

While serverless architecture abstracts away the network, enterprise environments often consist of dozens or hundreds of custom Virtual Private Clouds (VPCs). Managing peer-to-peer connections between all of them creates an unmanageable administrative nightmare. This project demonstrates a centralized network hub.

The Architecture Flow

// Hub and Spoke Network Topology

[ VPC A: Logistics ]                         [ VPC B: Shared Services ]
           ↘                                       ↙
                    [ AWS Transit Gateway ]
           ↗                                       ↖
[ VPC C: Manufacturing ]                  [ Direct Connect (On-Prem) ]

1. The Transit Gateway Attachment

Instead of creating traditional VPC Peering connections (which are non-transitive and require a full mesh), I provisioned an AWS Transit Gateway. Each VPC is attached directly to the Transit Gateway, acting as spokes to the central hub.

2. Route Table Configuration

In each isolated VPC, I updated the main route table so that any traffic destined for a private internal IP address (e.g., `10.0.0.0/8`) is routed directly to the Transit Gateway Elastic Network Interface (ENI).

3. Centralized Security & Egress

The Transit Gateway routes all outbound internet traffic from the spoke VPCs through a single "Shared Services" VPC that contains a highly monitored NAT Gateway and AWS Network Firewall, centralizing security inspection and reducing the overhead of managing egress in every single environment.

The "Why":

A full-mesh VPC peering setup requires n(n-1)/2 connections. For 10 VPCs, that's 45 separate peering connections to manage. With a Transit Gateway, connecting 10 VPCs requires exactly 10 attachments. This architecture scales infinitely with minimal operational overhead.