Free — no signup required

The Transit Gateway: Your Central Cloud Router

3 min read

The Hub-and-Spoke Model

Imagine a major airport. Instead of every city having a direct flight to every other city (which would require thousands of routes), most air travel flows through a small number of hub airports. You fly from your small city to a hub, then from the hub to your destination. The hub handles the routing.

A Transit Gateway (TGW) is exactly this hub for your cloud networks. It is a highly scalable, managed cloud router that sits at the center of your network topology.

You attach all your VPCs and on-premises connections to the Transit Gateway. When VPC A wants to send traffic to VPC B, the path is: VPC A → Transit Gateway → VPC B. Each VPC only needs to know one thing: "For any traffic that isn't local, send it to the Transit Gateway." The TGW's internal route table handles the rest.

How it works mechanically:

  1. You create a Transit Gateway in your cloud account.
  2. You create a TGW Attachment for each VPC — this is a logical connection that plugs the VPC into the TGW.
  3. The TGW maintains a Route Table that maps destination CIDR blocks (IP address ranges) to the correct attachment. For example: "Traffic for 10.2.0.0/16? Send it out the attachment for VPC-B."
  4. Each VPC's own route table gets a single entry: "For all non-local traffic (0.0.0.0/0 or specific ranges), next hop is the TGW."

Benefits:

  1. Simplicity: Each VPC only needs one attachment and one route entry pointing to the TGW for all external traffic.
  2. Scalability: Adding a new VPC means creating one new attachment and one new route entry in the TGW. You do not touch any of the other 50 VPCs.
  3. Centralized Control: You have one place to manage routing rules, traffic segmentation, and security policies for your entire network.
  4. Cross-Region and Cross-Account: TGWs support inter-region peering (connecting TGWs in different AWS regions) and can be shared across multiple AWS accounts using AWS Resource Access Manager (RAM).

Segmentation with multiple route tables: A single TGW can have multiple route tables. This lets you enforce isolation — for example, your Dev VPCs can reach each other and the internet, but cannot route to Production VPCs. You achieve this by associating different VPC attachments with different TGW route tables, each with different propagation rules. This is a powerful security pattern called network segmentation at the transit layer.

Interview Tip

Interviewers frequently ask: "How would you connect 100 VPCs without creating a management nightmare?" The answer is Transit Gateway with a hub-and-spoke model. Be ready to explain why it reduces complexity from O(N²) to O(N), and mention that TGW route tables can enforce segmentation between environments — for example, preventing Dev from routing to Prod even though both are attached to the same TGW.

Key Point: Transit Gateway reduces operational complexity from O(N²) peering connections to O(N) attachments. But the real architectural power is in its route tables — multiple route tables on a single TGW let you enforce strict network segmentation between environments without deploying separate infrastructure.

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free