2.2.2.1. TGW Attachments & Routing

Transit Gateway (TGW) attachments establish connections to various networks, while TGW routing directs traffic between them, defining the network's logical flow and enabling transitive communication.

Scenario: You have a central shared services VPC and multiple application VPCs connected to an AWS Transit Gateway (TGW). You need to ensure all application VPCs can reach the shared services VPC, but the application VPCs should not be able to communicate directly with each other.

Understanding how networks connect to a Transit Gateway (TGW) and how traffic is routed within it is crucial for building scalable and efficient hub-and-spoke architectures.

Key Concepts:

• TGW Attachments:
  • Purpose: Connections from your VPCs, VPNs, and Direct Connect Gateways to the Transit Gateway.
  • Types: VPC attachments, VPN attachments, Direct Connect Gateway attachments.
  • One-to-One: Each network attaches to the TGW via a single attachment.
• TGW Route Tables:
  • Purpose: Control how packets are routed from attachments connected to the Transit Gateway.
  • Default: Each TGW has a default route table. You can create custom TGW route tables for more complex routing policies.
  • Associations: An attachment is associated with a single TGW route table.
  • Propagations: Routes can be manually added or dynamically propagated from attached VPCs or VPNs to the TGW route table using BGP.
• TGW Route Domains: A common pattern where multiple attachments are associated with the same TGW route table, allowing them to share routing policies.
• Overlapping CIDRs: a TGW can hold attachments whose CIDRs overlap or match, but it cannot route between them: the destination is ambiguous, and it never re-addresses or load-balances across them. To connect such networks, route through a central NAT VPC where clients target a non-overlapping proxy address and the NAT appliance applies DNAT to the real destination and SNAT to the source.
• Traffic Flow: Ingress traffic to the TGW is associated with a TGW route table, which then directs traffic to the correct egress attachment.
• VPC route tables point at the TGW statically: each subnet route table needs routes (specific, summary, or 0.0.0.0/0) targeting the transit gateway. VPC route propagation works only from a virtual private gateway, so routes the TGW learns over BGP never appear in VPC route tables automatically.
• Centralized egress: spoke VPCs send 0.0.0.0/0 to the TGW, the TGW route table associated with the spokes sends 0.0.0.0/0 to the egress VPC attachment, and the egress VPC exits through its NAT gateway and internet gateway. Blackhole routes in a TGW route table drop traffic to a CIDR (e.g., keep the production table from reaching development CIDRs).
• Appliance mode: enable it on the attachment of a VPC that runs stateful appliances, so the TGW keeps both directions of a flow in the same Availability Zone (and appliance) and avoids asymmetric drops.
• Connect attachments (SD-WAN): GRE tunnels with BGP to third-party SD-WAN or router appliances, riding on an existing VPC or Direct Connect transport attachment — up to 5 Gbps per Connect peer and 4 peers (20 Gbps) per attachment, versus 1.25 Gbps per standard IPsec VPN tunnel.
• Peering attachments: connect transit gateways (typically in different Regions) over the AWS backbone; one side requests, the other accepts, and routes across the peering are static only (no propagation, no BGP).
• Cross-account attachments: share the TGW with other accounts or OUs through AWS RAM; the other account creates the VPC attachment, and the TGW owner accepts it unless auto accept shared attachments is on.
• Verifying: the Routes tab of a TGW route table lists the propagated and static routes it holds.

Practical Implementation: Configuring TGW Route Tables for Shared Services

# Assuming TGW_ID, SHARED_SERVICES_VPC_ATTACHMENT_ID, APP_VPC_ATTACHMENT_ID_1, APP_VPC_CIDR_1, SHARED_SERVICES_CIDR are defined

# 1. Create a TGW Route Table for Shared Services (where app VPCs will associate)
SHARED_RT_ID=$(aws ec2 create-transit-gateway-route-table \
  --transit-gateway-id $TGW_ID \
  --query TransitGatewayRouteTable.TransitGatewayRouteTableId --output text)
echo "Shared Services TGW Route Table ID: $SHARED_RT_ID"

# 2. Associate Application VPC attachments with the Shared Services TGW Route Table
aws ec2 associate-transit-gateway-route-table \
  --transit-gateway-route-table-id $SHARED_RT_ID \
  --transit-gateway-attachment-id $APP_VPC_ATTACHMENT_ID_1

# Repeat for all application VPC attachments

# 3. Propagate routes from the Shared Services VPC attachment to the Shared Services TGW Route Table
aws ec2 enable-transit-gateway-route-table-propagation \
  --transit-gateway-route-table-id $SHARED_RT_ID \
  --transit-gateway-attachment-id $SHARED_SERVICES_VPC_ATTACHMENT_ID

# 4. Create a TGW Route Table for the Shared Services VPC (where shared services VPC will associate)
# This TGW RT will only have routes to the app VPCs it needs to talk to.
SHARED_SERVICES_OUTBOUND_RT_ID=$(aws ec2 create-transit-gateway-route-table \
  --transit-gateway-id $TGW_ID \
  --query TransitGatewayRouteTable.TransitGatewayRouteTableId --output text)
echo "Shared Services Outbound TGW Route Table ID: $SHARED_SERVICES_OUTBOUND_RT_ID"

# 5. Associate the Shared Services VPC attachment with its outbound TGW Route Table
aws ec2 associate-transit-gateway-route-table \
  --transit-gateway-route-table-id $SHARED_SERVICES_OUTBOUND_RT_ID \
  --transit-gateway-attachment-id $SHARED_SERVICES_VPC_ATTACHMENT_ID

# 6. Add static routes from Shared Services TGW RT to each App VPC CIDR
aws ec2 create-transit-gateway-route \
  --transit-gateway-route-table-id $SHARED_SERVICES_OUTBOUND_RT_ID \
  --destination-cidr-block $APP_VPC_CIDR_1 \
  --transit-gateway-attachment-id $APP_VPC_ATTACHMENT_ID_1

# Repeat for all application VPC CIDRs

# 7. Ensure VPC route tables are updated to point to TGW
# For App VPCs: Add route for Shared Services CIDR to TGW attachment
# For Shared Services VPC: Add routes for App VPC CIDRs to TGW attachment

⚠️ Common Pitfall: Incorrectly associating attachments with TGW route tables or misconfiguring route propagations. This can lead to traffic black-holes or unintended communication paths.

Key Trade-Offs:

• Centralized Control vs. Granular Isolation: Using multiple TGW route tables provides granular control over traffic flow between attachments but adds complexity to the TGW configuration.

Reflection Question: How do TGW attachments establish connections and how does defining custom TGW route tables (with appropriate associations and propagations) fundamentally control routing and enable transitive communication between your networks while isolating application VPCs from each other?