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?
answer
- links, not a network
- two endpoints only, never a hop
- a route table cannot fix it
- the same rule blocks shared NAT
- hub beats mesh past a handful
basics
~20 sVPC peering is non-transitive: each connection carries traffic only between the two VPCs it joins, so A cannot reach C through B. Fix it with a direct A-to-C peering connection, or attach all three VPCs to a Transit Gateway.
solid answer
~50 sPeering is point-to-point, not a network. The connection between A and B moves traffic addressed to B's address space and nothing else, so a packet from A destined for C's CIDR is dropped no matter what you write in A's route table — B never gets a chance to forward it. The same restriction, in a different costume, is why you also cannot use a peering connection to reach the peer VPC's internet gateway, NAT gateway, VPN or Direct Connect connection, or its gateway endpoints; AWS calls that the edge-to-edge routing restriction. Your realistic options are a direct A-to-C peering connection, which is fine for a couple of pairs and becomes a full mesh as VPC count grows, or a Transit Gateway that all three attach to and which does route transitively. If A only needs one service in C, exposing that service privately beats joining the two networks at all.
go deeper
Remember the phrase and the picture: VPC peering is non-transitive, so A peered to B and B peered to C does not let A talk to C. Say it before you start reasoning about route tables.
Explain why no route table entry can rescue it — the peering connection only carries traffic addressed to the peer VPC — and connect it to the edge-to-edge restriction that also blocks using a peer's NAT gateway or VPN.
Show the decision, not just the rule: a direct peering for one or two hot pairs, a Transit Gateway once the mesh and its route-table churn stop scaling, and a private single-service exposure when only one API is actually needed.
Own the topology standard for the estate — where the hub lives, who may create peerings, how address space is allocated to keep CIDRs disjoint, and what the segmentation boundaries between environments are before any of it is built.
## 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.
- Can VPC A reach the internet through a NAT gateway that lives in peered VPC B?No. AWS's edge-to-edge routing restriction means a peering connection cannot be used to reach the peer VPC's internet gateway, NAT gateway, VPN or Direct Connect connection, or gateway endpoints. Shared egress needs a Transit Gateway with a central egress VPC, or a NAT gateway in each VPC.
- Once every VPC attaches to a Transit Gateway, is everything automatically reachable from everything else?Only if you leave the default routing in place, where each attachment associates with and propagates into a single default route table. Reachability is decided by the gateway's route tables, so you can segment prod from dev by giving them separate route tables that never learn each other's routes.
- How many peering connections does a full mesh of ten VPCs need, and why does that number matter?Forty-five, from n(n−1)/2. The count matters less than the churn: adding an eleventh VPC means ten new connections and edits to every existing VPC's route tables, and each route table carries an entry per peer against a per-table route quota.
A peering connection is a private cable strung between two buildings, not a road joining a network of them: a cable from A to B and another from B to C never adds up to a route from A to C.
saying these in an interview costs you the question
- Add a route in A pointing C's CIDR at the A-to-B peering connection
- Peering becomes transitive once routes exist on all three sides
- Enabling route propagation on the VPC route table makes peering transitive
- Peered VPCs can share one NAT gateway to save money
- A Transit Gateway is just peering with a nicer console