Three application VPCs must reach each other. The team peered A to B and B to C, and instances in A still cannot reach C. They expected the path to pass through B. What connectivity should they use instead?
Select an answer to reveal the explanation.
Short Explanation
You can’t send traffic from A through B to C over VPC peering, because peering is not transitive. Attach all three VPCs to a transit gateway and add the routes each side needs; an internet gateway or NAT gateway in B won’t bridge the peering connections.
Full Explanation
VPC peering is not transitive: a route from A to B and a route from B to C do not create a path from A to C through B. A transit gateway provides the hub instead. Attach each VPC to it, configure its route table to send each VPC CIDR to the correct attachment, and add routes in each VPC for the other VPC CIDRs pointing to the transit gateway. A third peering connection from a VPC to itself does not provide a route to another VPC. An internet gateway in B does not translate traffic into a private bridge between the peerings, and a NAT gateway with a public route does not stitch those peerings together; using either would put private traffic on a public path without enabling the expected transit. Exam caveat: both the transit gateway route table and each VPC route table must have matching routes, or an attachment can exist while traffic still has no usable path. As a practical check, test from an instance in A to an address in C and confirm that traffic uses the transit gateway. Create the gateway, attach all three VPCs, and add the required CIDR routes; security groups must also allow the far CIDRs. Existing peering can remain for a pair that does not need the third VPC, but it will not carry A’s packets to C.