AWS Transit Gateway: Hub-and-Spoke Network Connectivity for Multi-VPC Architectures

A growing AWS environment eventually hits a networking complexity wall. You have ten VPCs — production, staging, development, security, shared services, each business unit gets its own. Without Transit Gateway, connecting these requires VPC peering connections. Ten VPCs would need up to 45 individual peering connections in a full mesh. Each peering connection is non-transitive, meaning traffic cannot hop through intermediate VPCs. Managing routing tables for 45 connections across ten VPCs is an operational nightmare that scales badly.

AWS Transit Gateway solves this with a hub-and-spoke model. Every VPC connects to one regional hub. The hub routes traffic between attachments. Add a new VPC? Attach it to the Transit Gateway with one connection instead of nine. The routing update happens in one place.

What Transit Gateway Actually Is

Transit Gateway is a regional network transit hub managed by AWS. It is not a VPC itself — it is a routing appliance that sits between VPCs, VPN connections, and Direct Connect gateways. Every connected network attaches to the TGW as an “attachment,” and the TGW’s route tables determine how traffic flows between attachments.

The key components:

TGW itself: A regional resource. One TGW can serve all VPCs in a region.
Attachments: The connections to the TGW. Types include VPC attachments, VPN attachments, Direct Connect Gateway attachments, and peering attachments (connecting to another TGW in a different region).
Route tables: One or more route tables control how traffic between attachments is routed. Each attachment is associated with one route table and can propagate routes into one or more route tables.

VPC Peering (Old Approach) vs Transit Gateway
-----------------------------------------------
Full Mesh VPC Peering (5 VPCs):
  VPC-A <--> VPC-B
  VPC-A <--> VPC-C
  VPC-A <--> VPC-D
  VPC-A <--> VPC-E
  VPC-B <--> VPC-C
  VPC-B <--> VPC-D
  VPC-B <--> VPC-E
  VPC-C <--> VPC-D
  VPC-C <--> VPC-E
  VPC-D <--> VPC-E
  = 10 peering connections, non-transitive

Transit Gateway (Same 5 VPCs):
  VPC-A ---|
  VPC-B ---|
  VPC-C ---+---> [Transit Gateway] ---> routes traffic
  VPC-D ---|
  VPC-E ---|
  = 5 attachments, fully transitive, single route table

Route Tables and Traffic Segmentation

The default TGW configuration puts all attachments in a single route table, allowing full any-to-any communication. This is fine for small environments but creates security risks in larger ones — you likely do not want development VPCs to reach production databases.

TGW supports multiple route tables to segment traffic. A common pattern:

Production route table: Associates production VPCs and shared services. Development VPCs are not associated.
Development route table: Associates development and staging VPCs. Does not propagate routes into the production table.
Shared services route table: Associates shared services VPC only, but propagates routes into both production and development tables. This lets both environments reach shared services (DNS, monitoring, Active Directory) without being able to reach each other.

TGW Route Table Segmentation
-------------------------------
Production RT:
  Associated: Prod-VPC-A, Prod-VPC-B, Shared-Services-VPC
  Routes learned: 10.0.0.0/16 (Prod-A), 10.1.0.0/16 (Prod-B),
                  172.16.0.0/24 (Shared)

Dev RT:
  Associated: Dev-VPC, Staging-VPC, Shared-Services-VPC
  Routes learned: 10.100.0.0/16 (Dev), 10.101.0.0/16 (Staging),
                  172.16.0.0/24 (Shared)

Result:
  Prod VPCs can reach each other and Shared Services
  Dev VPCs can reach each other and Shared Services
  Prod VPCs CANNOT reach Dev VPCs (no cross-table route)

VPN and Direct Connect Attachments

Transit Gateway unifies hybrid connectivity. Instead of creating a separate VPN connection per VPC, a single VPN attachment to the TGW provides connectivity from the on-premises network to all VPCs attached to the TGW.

Site-to-Site VPN attachment: Create a VPN connection and associate it with the TGW rather than a VPC. Routes from the on-premises network propagate into TGW route tables and become reachable to all associated VPCs. This is cleaner than managing one VPN gateway per VPC.

Direct Connect Gateway attachment: A Direct Connect Gateway can connect to multiple TGWs across regions, enabling a single Direct Connect circuit to reach VPCs in multiple regions through TGW peering.

The bandwidth aggregate across VPN tunnels to a TGW can reach 50 Gbps (25 VPN connections × 2 Gbps per connection pair). For higher bandwidth, Direct Connect is the path.

Inter-Region Peering

TGW is a regional resource, but inter-region TGW peering connects TGWs in different regions over AWS’s private backbone. Traffic between regions goes over AWS infrastructure, not the public internet.

A company with VPCs in us-east-1 and eu-west-1 can:

Deploy a TGW in each region
Create a peering attachment between the two TGWs
Add static routes in each TGW’s route table pointing to the other region’s CIDR ranges via the peering attachment

The inter-region traffic is encrypted in transit by default. Latency depends on the physical distance between regions (typically 70–100ms between US East and Ireland). Bandwidth caps apply per peering attachment.

Multicast Support

Transit Gateway is the only AWS networking feature that supports multicast — the ability to send a single packet to multiple destinations simultaneously. This matters for a narrow set of use cases: video conferencing infrastructure, financial market data distribution, gaming, and industrial IoT sensor data.

TGW multicast works with IGMP (Internet Group Management Protocol) — standard multicast group management. Instances join multicast groups, and traffic sent to a multicast group address is delivered to all group members attached to the same TGW multicast domain. This feature is not available with VPC peering or other AWS networking constructs.

Real-World Architecture: Global Enterprise Network

A multinational with AWS workloads in us-east-1, eu-west-1, and ap-southeast-1:

4 VPCs per region (prod, staging, dev, shared-services)
On-premises data centres in New York and London
Security team requires prod and non-prod environments to be isolated

Architecture:

One TGW per region, two route tables per TGW (prod and non-prod)
VPN attachments to TGW in us-east-1 from New York DC, to eu-west-1 from London DC
Inter-region TGW peering: us-east-1 ↔ eu-west-1 ↔ ap-southeast-1
Direct Connect from New York to us-east-1 for production workloads requiring consistent bandwidth

Total connection management: 12 VPC attachments, 3 inter-region peering connections, 2 VPN attachments. Without TGW: 66+ individual peering connections across regions, non-transitive, unmanageable.

Transit Gateway is the correct architectural choice whenever an AWS environment exceeds approximately 5 VPCs, requires hybrid connectivity at scale, or needs to enforce network segmentation between environments.