VPC A is peered with VPC B, and VPC B is peered with VPC C. Instances in A cannot reach instances in C even though every route table looks right. Why, and what are your options?

## The rule, stated precisely A VPC peering connection joins exactly two VPCs and carries only traffic whose destination lies in the peer VPC's own address space. It is not a router you can chain. "Non-transitive" means: peering A–B and B–C creates two independent links, not a three-node network. Nothing you configure in A, B or C makes A–B–C work. This is not a bug or an oversight. Each peering connection is a permission granted between two specific VPC owners. If peering were transitive, accepting one connection would silently expose you to everything your peer has peered with, and to everything *their* peers have peered with. The blast radius of a single acceptance would be unbounded. ## Why the obvious workaround fails The intuitive fix is to add, in VPC A, a route sending C's CIDR to `pcx-AB`, and in VPC C a route sending A's CIDR to `pcx-BC`, on the theory that B will forward. It does not work. The peering fabric is not a hop that consults B's route table; it is a link between two address spaces, and traffic addressed outside the peer's space is discarded. You will see the route sitting there looking perfectly healthy while every packet vanishes — which is exactly why this shows up in interviews as a debugging scenario rather than a definition question. ## The same restriction, other faces The edge-to-edge routing restriction is the generalization: you cannot use a peering connection to reach *any* edge device belonging to the peer VPC. Concretely, VPC A cannot: - route to the internet through B's internet gateway or NAT gateway, - reach on-premises through a VPN or Direct Connect connection attached to B, - use a gateway VPC endpoint that lives in B. Candidates who know only the A–B–C form of the rule get caught by the "can I share one NAT gateway across peered VPCs?" version of the same question. The answer is no — peering does not give you shared egress. ## Option 1: peer directly For a small number of VPCs, just peer A to C. Costs nothing per hour, adds no hop, no bandwidth ceiling of its own. The problem is combinatorial: a full mesh of *n* VPCs needs *n(n−1)/2* connections, and every VPC's route tables accumulate one entry per peer. At five VPCs that is ten connections and it is still fine; at twenty-five it is three hundred connections and every new VPC is a change to twenty-five route tables. ## Option 2: Transit Gateway A Transit Gateway is a regional hub. Each VPC gets one attachment and one route pointing at the gateway, and the gateway routes between attachments — transitively, which is the whole point. It also terminates VPN and Direct Connect gateway attachments, so on-premises reaches every VPC through the same hub, and it can be shared across accounts with AWS Resource Access Manager. You pay per attachment-hour and per GB processed, which peering does not charge, and you take one extra hop. Be aware that transitivity through a Transit Gateway is *governed*, not automatic: which attachments can reach which is decided by the gateway's route tables. The default configuration, where every attachment associates with and propagates into one default route table, does give you any-to-any — often before anyone intended it. ## Option 3: don't connect the networks at all If A needs one API in C rather than general reachability, joining two address spaces is the heavyweight answer. Exposing that single service privately keeps the networks independent, works with overlapping CIDRs, and is one-directional by construction. Mentioning this option is usually what separates a good answer from a correct one. ## The appliance hairpin Someone always asks about running a proxy or firewall appliance in B. It is possible in the narrow sense — A can send traffic to an instance in B over the A–B peering, and that instance can originate its own connections to C over the B–C peering — but only because the appliance terminates and re-originates the traffic, typically with source NAT. You are not routing transitively; you are proxying. It adds a stateful bottleneck you now have to scale and keep highly available, and it is almost never the right answer when a Transit Gateway exists. ## What interviewers listen for Say "peering is non-transitive" quickly and confidently, then show you know the consequence (no shared NAT, no shared VPN through a peer) and can name the escalation path to a Transit Gateway with its cost. Candidates who insist a cleverer route table would fix it have revealed they have never built this.