Two VPCs are peered. Instances in VPC A can send packets toward VPC B, and VPC B never answers. VPC A's route table has a route to VPC B's CIDR through the peering connection. VPC B's route table has no route back to VPC A's CIDR. What is missing?
Select an answer to reveal the explanation.
Short Explanation
Peering is a hallway with two ends, and someone forgot the sign on the way back. You add a route in VPC B for VPC A's addresses, aimed at the peering connection. You do not build a second hallway, and you do not send private traffic out an internet gateway to get home.
Full Explanation
A peering connection is not transitive and it is not one-way, but each VPC's route table must send the other VPC's CIDR to the peering connection or the return packet has nowhere to go. VPC A already has that route, and VPC B does not, which matches one-way success. A second peering connection is unnecessary; the existing one carries both directions once both routes exist. An internet gateway does not forward peered private traffic. Public addresses are not required for traffic that stays on the peering connection. Caveat: security groups and NACLs on both sides still have to allow the port, or the routes can be right and the packet still drops. Operational check: VPC B's route table should list VPC A's CIDR with the peering connection as the target, and a connection from A should complete. Each route is a CIDR and a target. The target for the far VPC is the peering connection id, the same id in both route tables. Security groups on the far instances must allow the source security group or the CIDR, or the route fix still times out. Peering does not cross accounts until the accepter side has accepted, but this stem already has a working direction, so acceptance is done.