A new VPC attachment on a Transit Gateway is available, and the VPC route table sends the remote CIDR to that gateway. Traffic still drops. The attachment is not associated with any Transit Gateway route table. What should be configured?
Select an answer to reveal the explanation.
Short Explanation
The VPC route hands traffic to the Transit Gateway, and the attachment has no route table of its own to consult. You associate the attachment with the Transit Gateway route table that should forward it. Propagation only advertises routes, and it does not give an unassociated attachment a table to use.
Full Explanation
A Transit Gateway attachment forwards traffic with the Transit Gateway route table it is associated with. The VPC route can send the remote CIDR to the gateway, and that only delivers packets to the attachment. With no association, the attachment has no Transit Gateway route table to consult, so the packets go nowhere. Associating the attachment with the route table that should carry this traffic gives it that forwarding table. Route propagation advertises the attachment's CIDRs into route tables. Propagation does not associate the attachment, and an attachment that is only propagated still has no table of its own. An internet gateway route leaves the private transit path and does not make this attachment forward. Appliance mode changes how one attachment hashes flows for a middlebox. It does not create a route table association. Caveat: the associated route table still needs a route to the destination, and the far-side attachment needs its own association, or this side forwards into a table that cannot finish the path. Operational check: confirm the attachment details show the intended route table, then test a connection from the VPC to the remote CIDR.