Transit Gateway TGW-1 (with VPC A attached) is peered with Transit Gateway TGW-2 (with VPC B attached) via a transit gateway peering attachment, which has been accepted. A week later, instances in VPC A still cannot reach instances in VPC B. What is the most likely cause, given how transit gateway peering attachments handle routing?
- Transit gateway peering attachments support automatic route propagation just like VPC attachments, so the routes should already exist — the peering attachment itself must be misconfigured
- Transit gateway peering attachments do not support route propagation; a static route pointing to the peering attachment must be manually added to (and associated with) the transit gateway route tables on both TGW-1 and TGW-2
- VPC A and VPC B must have identical CIDR blocks before any traffic can pass over a transit gateway peering attachment
- Transit gateway peering attachments only support routing IPv6 traffic, so IPv4 traffic between the VPCs will never work over this attachment
Why B? And why not the others?
Correct answer: B. Transit gateway peering attachments do not support route propagation; a static route pointing to the peering attachment must be manually added to (and associated with) the transit gateway route tables on both TGW-1 and TGW-2
Unlike VPC and VPN attachments to a transit gateway, peering attachments between transit gateways do not support automatic route propagation; AWS documentation is explicit that to route traffic between peered transit gateways, you must add a static route to the transit gateway route table that points to the peering attachment, and this route table must then be associated with the peering attachment. Skipping this manual step is the most common reason two peered transit gateways still cannot pass traffic even after acceptance succeeds. Option A is wrong because it assumes the very propagation behavior AWS documentation says is unsupported for this attachment type. Option C is wrong; while overlapping CIDRs would break routing (as with any routed connection), the two VPCs are not required to have identical ranges — quite the opposite, identical ranges would make routing between them impossible. Option D is wrong because transit gateway peering explicitly supports routing both IPv4 and IPv6 traffic between the peered gateways, not IPv6 exclusively.
Source: AWS Transit Gateway docs: Transit gateway peering attachments