Instances in a spoke VPC reach the transit gateway, and that attachment's transit gateway route table has a route to a shared-services VPC. Return traffic dies. The shared-services attachment uses a route table with no route to the spoke. What should be added?
Select an answer to reveal the explanation.
Short Explanation
You opened the door into the lobby and locked the door back to the street. The spoke route table can send traffic toward shared services, but the route table on the shared-services attachment has no route back to the spoke, so the return dies there. Add that return route, because a transit gateway does not fill a route into every attachment's table for you.
Full Explanation
Each transit gateway attachment is associated with a route table, and that table is what the attachment uses for the next hop. The spoke's table has a route to the shared-services VPC, so traffic can leave the spoke. The shared-services attachment uses a different route table, and that table has no route to the spoke, so the return packet dies on the gateway. Transit gateway route tables are not filled in for every attachment. Add the return route in the shared-services table so traffic for the spoke goes back to the spoke attachment. A default route from the spoke subnet to an internet gateway sends traffic to the internet, not back from shared services through the gateway. A second transit gateway does not invent the missing route in the table that is already dropping the return. A public hosted zone answers DNS. It does not install a route for the return packets. Caveat: the shared-services subnet route table still needs the spoke CIDR pointed at the transit gateway, or the packet never gets back onto the gateway. Operational check: after the return route exists, confirm a spoke instance receives replies from a shared-services host and that the gateway route table shows the spoke CIDR.