As the number of VPC connections grows, a mesh of VPC peering connections becomes harder to manage. AWS Transit Gateway (TGW) provides a central hub for connecting VPCs and on-premises networks. Its route tables determine how traffic moves through that hub.
1. A quick review of VPC route tables
A VPC route table controls routing for its associated subnets. Routes match destination address ranges to targets such as the local VPC, an internet gateway, a NAT gateway, a peering connection, or a transit gateway.
Destination | Target
------------------|----------------
10.0.0.0/16 | local
0.0.0.0/0 | igw-123456
192.168.0.0/16 | pcx-abcdefThe identifiers above are illustrative placeholders. A subnet uses either an explicitly associated route table or the VPC’s main route table. Routes are not necessarily all manually maintained: supported gateway configurations can also propagate routes.
2. What a transit gateway route table does
VPCs and VPN connections connect to a transit gateway through attachments. The route table associated with an incoming attachment determines the next attachment to which TGW forwards matching traffic.
Destination | Attachment
------------------|------------------------
10.0.0.0/16 | VPC-A
192.168.0.0/16 | VPN-Attachment
172.16.0.0/12 | VPC-BThese are conceptual route examples, not a complete deployment configuration.
3. VPC and TGW route tables compared
| Aspect | VPC route table | TGW route table |
|---|---|---|
| Association | Subnet | Transit gateway attachment |
| Typical targets | Gateways, network interfaces, peering connections, TGW | Other attachments |
| Where it acts | Inside a VPC | Inside the transit gateway |
| Main purpose | Choose paths out of a subnet | Control traffic between attached networks |
| Operational model | Manage subnet routing in each VPC | Organize connectivity through a central hub |
4. Association, propagation, and security
A transit gateway can have multiple route tables. An attachment is associated with one route table at a time, while its routes can be propagated to multiple tables. Association and propagation therefore serve different purposes: the former selects the forwarding table for incoming traffic, while the latter makes destination routes available in selected tables.
- Add static routes where propagation does not provide the required path.
- Check the VPC subnet routes as well as the TGW routes. Configuring the hub alone does not complete the path.
- Verify the return path, not just the outbound route.
- Routing and permission to communicate are separate concerns. Security groups, network ACLs, and any firewalls still apply.
5. Example: three VPCs and a VPN
Suppose VPC-A and VPC-B should communicate, VPC-C is a backup network that should communicate with VPC-A but not VPC-B, and the VPN must reach all three VPCs.
This calls for separating forwarding policies by attachment role. VPC-C needs a restricted route table; the other incoming attachments also need tables whose routes reflect their allowed destinations. Propagate or add the VPN routes where needed, and provide matching return routes.
Clarification: merely placing VPC-C in a second table does not by itself enforce the entire connectivity matrix. If VPC-A and VPC-B share a table containing a route to VPC-C, both can use that route. Design each direction explicitly and add routing separation or security controls as required.
6. Practical takeaways
Group attachments by their connectivity requirements rather than assuming one shared table will fit every workload. Keeping these policies explicit also makes CloudFormation or Terraform configurations easier to review and maintain.
English translation with clarifications to the routing and isolation examples. The Korean original has not been changed. Reference: AWS transit gateway route tables.
Read the Korean original.