← Back to Transit Gateway Topics

Core Components

The building blocks of Transit Gateway

So far, you've learned:

  • Transit Gateway is a network hub that connects VPCs and on-premises networks
  • It solves the VPC Peering scaling problem (1,225 connections → 50 attachments)
  • It enables transitive routing between connected networks

Now let's understand the pieces that make Transit Gateway work.

Think of Transit Gateway like LEGO blocks. You need to understand each piece before you can build something useful. Let's break down the 4 core components.

Component 1: The Transit Gateway Resource

Transit Gateway

The actual Transit Gateway resource itself - this is the hub that you create in your AWS region.

What it is: A highly available, scalable virtual router managed by AWS.

What it does: Routes traffic between attached networks when permitted by Transit Gateway route tables and VPC routing configuration.

Creating a Transit Gateway:

When you create a Transit Gateway in AWS, you configure a few basic settings:

Important: A default route table may be created at Transit Gateway creation, depending on your default association/propagation settings. If both "Default Route Table Association" and "Default Route Table Propagation" are disabled, no default route table is created.

Think of the Transit Gateway like a physical network switch in a data center.

You buy the switch (create the TGW), configure some basic settings (ASN, DNS), and then you start plugging cables into it (attachments). The switch routes traffic between all the connected devices.

Important: The Transit Gateway itself is regional. If you create a Transit Gateway in us-east-1, it only works in us-east-1. To connect multiple regions, you need one Transit Gateway per region and connect them with Inter-Region Peering.

Component 2: Attachments

Attachment

An attachment is a connection between your Transit Gateway and a network. It's how you "plug in" networks to the hub.

There are several types of attachments you can create:

VPC Attachment

Connects a VPC to the Transit Gateway. This is the most common type.

📖 Coming Up: We'll dive deep into VPC Attachments in Topic 2 - including subnet selection, availability zones, and ENI planning.

VPN Attachment

Connects your on-premises network via Site-to-Site VPN.

📖 Coming Up: We'll explore VPN Attachments in detail in Topic 3 - including BGP configuration, ECMP, and when to use VGW vs TGW VPN.

Direct Connect Gateway Attachment

A Transit Gateway attaches to a Direct Connect Gateway, which provides connectivity to on-premises networks via Direct Connect.

📖 Coming Up: Direct Connect integration is covered in Topic 4 - including Transit VIF setup and DX Gateway configuration.

Transit Gateway Peering Attachment

Connects two Transit Gateways together (in the same or different regions).

📖 Coming Up: Inter-Region Peering is explained in Topic 9 - including peering setup and multi-region design patterns.

Transit Gateway with Different Attachment Types
TGW VPC VPC Attachment On-Prem VPN Attachment Data Center (Direct Connect) Direct Connect Attachment TGW-EU Peering Attachment
  • → Each attachment connects ONE network to the Transit Gateway
  • → VPC attachments are the most common type
  • → You pay hourly per attachment ($0.05/hour)
  • → Maximum 5,000 attachments per Transit Gateway

Component 3: Route Tables

Transit Gateway Route Table

A route table contains rules that determine where network traffic is directed. It's like a GPS for your network packets.

Route tables are where the actual routing decisions happen. When a packet arrives at the Transit Gateway from one attachment, the Transit Gateway checks the route table to decide which attachment to send it to.

How Route Tables Work

Example Route Table:

Destination CIDR Attachment ID Meaning
10.1.0.0/16 tgw-attach-vpc-a Traffic for 10.1.x.x goes to VPC-A
10.2.0.0/16 tgw-attach-vpc-b Traffic for 10.2.x.x goes to VPC-B
192.168.0.0/16 tgw-attach-vpn Traffic for 192.168.x.x goes to On-Premises

When a packet arrives:

  1. Transit Gateway looks at the packet's destination IP address
  2. Checks the route table for a matching route
  3. Sends the packet out the corresponding attachment

Think of a route table like a directory at a mall.

When you want to find the Apple Store, you look at the directory. It says "Apple Store → 2nd Floor, West Wing." The directory (route table) tells you where to go based on what you're looking for (destination IP).

Default Route Table

When you create a Transit Gateway, AWS can automatically create a default route table. All new attachments are automatically associated with this table unless you specify otherwise.

This is convenient for simple setups where all networks can talk to all other networks.

Custom Route Tables

You can create multiple route tables for network segmentation. For example:

📖 Coming Up: We'll cover routing in depth in Topic 6: Route Tables & Routing - including associations, propagations, and static routes.

Multiple Route Tables = Network Segmentation

By using different route tables, you can control which networks can communicate. Route tables control reachability (network paths), not security enforcement.

Important: Actual security is enforced by Security Groups, NACLs, and firewall appliances. Route tables just determine if a path exists between networks.

Component 4: Associations & Propagations

This is the trickiest part of Transit Gateway, but once you understand it, everything clicks. Let's use a simple example.

Important to Know: Associations and Propagations are settings you configure when you create or manage attachments and route tables.

When you attach a VPC to Transit Gateway, AWS Console will ask you:

  • "Which route table should this attachment be associated with?"
  • "Which route tables should this attachment propagate to?"

These are checkboxes/dropdowns you select during setup - they're not automatic!

🏢 Simple Example

You have:

  • VPC-A (10.1.0.0/16)
  • VPC-B (10.2.0.0/16)
  • Transit Gateway with one route table

You want VPC-A and VPC-B to talk to each other.

Step 1: Association (Outbound Traffic)

Association = "Which route table do I use?"

When VPC-A sends traffic TO the Transit Gateway, which route table should TGW use to decide where to send it next?

What you do:

What this means:

Think of association like choosing which GPS app to use.

When you leave your house (VPC-A) and want directions, which GPS do you open? Google Maps, Waze, or Apple Maps?

Association says: "When I send traffic out, use THIS route table (GPS app) to find where to go."

Step 2: Propagation (Inbound Traffic)

Propagation = "Tell everyone how to reach me"

Automatically add a route to the route table so OTHER attachments know how to reach this VPC.

What you do:

What this does automatically:

What this means:

Think of propagation like adding your address to a directory.

When you move to a new apartment (VPC-A at 10.1.0.0/16), you add your address to the building directory. Now anyone who checks the directory can find you.

Propagation says: "Add my network address to the route table so others can reach me."

Propagation is Optional!

You can choose NOT to enable propagation and instead manually add routes to the Transit Gateway route table.

Why you might do this:

  • More control over exactly which routes exist
  • You want to use more specific routes (like 10.1.1.0/24 instead of 10.1.0.0/16)
  • Security or compliance requirements need manual approval of routes

Trade-off: Manual routes = more control but more work. Propagation = automatic but less control.

Putting It Together

Let's see what happens when VPC-A wants to send traffic to VPC-B (10.2.5.5):

  1. VPC-A sends packet to Transit Gateway (destination: 10.2.5.5)
  2. TGW checks association: "VPC-A is associated with Route Table 1"
  3. TGW looks up in Route Table 1: "10.2.0.0/16 → VPC-B attachment" (this route exists because VPC-B was propagated)
  4. TGW sends packet out VPC-B attachment
  5. Packet arrives at VPC-B!

The Simple Rule:

Associate an attachment = Outbound (which route table to use when SENDING)

Propagate an attachment = Inbound (add routes so others can RECEIVE)

For two-way communication, you need BOTH!

Association vs Propagation Summary

Association Propagation
"Which route table do I use when I send traffic?" "Add my routes to this table so others can find me"
Which route table TGW consults for traffic arriving from this attachment Which route tables contain routes pointing to this attachment
Each attachment associates with ONE route table Each attachment can propagate to MULTIPLE route tables
Manual: You choose which table Automatic: Routes are added for you
Example: "VPC-A uses Route Table 1" Example: "Add 10.1.0.0/16 → VPC-A to Route Table 1"

📖 Coming Up: We'll see real examples of associations and propagations in Topic 6: Route Tables & Routing with multiple route tables for network segmentation.

Putting It All Together

Let's see how all 4 components work together with a simple example:

Scenario: You have 2 VPCs and want them to communicate.

  1. Create Transit Gateway in us-east-1
  2. Create Attachments:
    • VPC-A attachment (10.1.0.0/16)
    • VPC-B attachment (10.2.0.0/16)
  3. Use Default Route Table (automatically created)
  4. Associate both attachments with the default route table
  5. Propagate both attachments to the default route table
    • This adds route: 10.1.0.0/16 → VPC-A attachment
    • This adds route: 10.2.0.0/16 → VPC-B attachment
  6. Update VPC route tables to send traffic to Transit Gateway

Result: VPC-A and VPC-B can now communicate through the Transit Gateway!

  • → Transit Gateway Resource = The hub itself
  • → Attachments = Connections to networks (VPC, VPN, DX)
  • → Route Tables = Rules for where traffic should go
  • → Association = Which route table TGW uses for traffic from this attachment
  • → Propagation = Automatically adds routes so others can reach this attachment
  • → All 4 components work together to enable routing

Quick Summary