Skip to content

Example transit gateway routing tables

A worked example for a multi-account transit gateway with three VPCs. It shows the transit gateway’s own route table, the VPC route tables that feed it, and the decisions behind them.

The design allows every VPC to reach every other VPC through the transit gateway, keeps inter-VPC traffic off the public internet, and leaves room to add VPCs and Regions later.

The distinction that trips people up: a VPC subnet route table targets the transit gateway (tgw-…); the transit gateway’s own route tables target attachments (tgw-attach-…). Putting an attachment ID in a VPC route table produces an invalid gateway ID error.

VPCAccountCIDR
VPC 1Account 110.1.0.0/16
VPC 2Account 110.2.0.0/16
VPC 3Account 210.3.0.0/16

Route table tgw-rtb-main carries a route for every VPC CIDR block, each pointing at that VPC’s attachment.

Destination CIDRTarget typeTarget IDNotes
10.1.0.0/16Attachmenttgw-attach-vpc1Route to VPC 1
10.2.0.0/16Attachmenttgw-attach-vpc2Route to VPC 2
10.3.0.0/16Attachmenttgw-attach-vpc3Route to VPC 3
Destination CIDRTargetNotes
10.1.0.0/16localLocal VPC traffic
10.2.0.0/16tgw-xxxxxxxxTo VPC 2 via the transit gateway
10.3.0.0/16tgw-xxxxxxxxTo VPC 3 via the transit gateway
0.0.0.0/0igw-xxxxxxxxInternet traffic, if the subnet is public
Destination CIDRTargetNotes
10.2.0.0/16localLocal VPC traffic
10.1.0.0/16tgw-xxxxxxxxTo VPC 1 via the transit gateway
10.3.0.0/16tgw-xxxxxxxxTo VPC 3 via the transit gateway
0.0.0.0/0igw-xxxxxxxxInternet traffic, if the subnet is public
Destination CIDRTargetNotes
10.3.0.0/16localLocal VPC traffic
10.1.0.0/16tgw-xxxxxxxxTo VPC 1 via the transit gateway
10.2.0.0/16tgw-xxxxxxxxTo VPC 2 via the transit gateway
0.0.0.0/0igw-xxxxxxxxInternet traffic, if the subnet is public

Each of the three tables names the same transit gateway. A summary route such as 10.0.0.0/8 would work in place of the two specific entries, at the cost of losing the ability to leave one VPC out.

SettingValueWhy
Auto-accept shared attachmentsEnabledMember accounts can attach without an approval step
Default route table associationDisabledAttachments are associated explicitly, so isolation is deliberate
Default route table propagationDisabledRoutes are added explicitly rather than appearing on their own
DNS supportEnabledCross-VPC resolution of private hosted zones
VPN ECMP supportEnabledAggregate bandwidth across multiple VPN tunnels
Default route tabletgw-rtb-main

Disabling default association and propagation is what makes segmentation possible later: with them on, every attachment can reach every other attachment by default.

  • Each VPC has one transit gateway attachment.
  • An attachment needs a subnet in each Availability Zone where traffic should enter or leave the transit gateway; other subnets in the same zone route through it.
  • Attachments are associated with tgw-rtb-main.

Another VPC in the same Region

  1. Create the attachment.
  2. Add a route for the new CIDR block to the transit gateway route table and to the existing VPC route tables.
  3. Associate the attachment with the transit gateway route table.

Another Region

  1. Create a transit gateway in the target Region.
  2. Create a transit gateway peering attachment between the two.
  3. Add routes for the remote CIDR blocks in both Regions’ transit gateway route tables and in the VPC route tables.

Keep one non-overlapping block per Region so that a summary route per Region stays possible.

  • Routes make traffic possible; security groups and network ACLs decide whether it is allowed. Add both.
  • Enable VPC flow logs on the attachment subnets — inter-VPC traffic is otherwise invisible.
  • Give each account only the IAM and RAM permissions it needs to attach, not to alter the transit gateway route tables.
  • Consider separate transit gateway route tables per environment rather than one shared table, so that a mistake in a development account cannot open a path to production.