Why VPC Peering Is Not Transitive and What a Transit Gateway Adds

Ten VPCs that all need to reach each other is the point at which the pairwise model stops being workable. The naive count of connections is forty-five, which is unpleasant but survivable; the part that does not scale is that each connection carries its own route entries, its own address-space constraints, and its own failure behaviour. Two mechanisms exist for the many-to-many case, and they differ in a way that is easy to state and easy to get wrong: one is a set of private two-party agreements, the other is a router.

A peering connection is an agreement, not a wire

Two VPCs are peered by creating a connection that both sides accept. After acceptance, each side adds a route for the other’s prefix pointing at the connection, and traffic between them flows directly across the provider’s fabric, encapsulated and delivered without leaving the provider’s network.

The connection has no address of its own. It is not a device that packets pass through, so there is nowhere for a third party’s traffic to be handed off. That is the whole reason for non-transitivity, and it is a property of the design rather than a limitation added on top. A packet from VPC A to VPC C, where A is peered with B and B is peered with C, arrives at B’s virtual switch. B’s route table has an entry for C’s prefix pointing at the B-C connection. If B forwards the packet according to that entry, the packet leaves B addressed to C, but its source address is still A’s. C has no peering with A, so C’s route table has no entry that would return traffic to A’s prefix, and the reply is dropped. The forward direction appears to work and the return direction does not, which is the classic asymmetric half-connection.

Even if C did have a route, the peering connection between B and C is not authorised to carry traffic originating in A. The authorisation is part of the agreement: each side permits the other’s addresses and nothing else. A hub VPC that tried to relay would need its peers to accept addresses that are not the hub’s, and no peering connection does that.

What non-transitivity costs in practice

The immediate cost is the number of connections. For n VPCs that must all reach each other, the count is n(n-1)/2, which is 45 for ten and 4,950 for a hundred. Each connection is a resource with a quota, each requires an acceptance step, and each adds two route entries per participating subnet.

The second cost is the address constraint. Peering requires that the two prefixes do not overlap, and it requires it transitively in the sense that any address reachable through a peer must be distinguishable from every other address reachable through any other peer. A provider that assigned 10.0.0.0/16 to every VPC by default, or an acquisition that brought in a network with the same private range, produces VPCs that cannot be peered at all. There is no workaround within peering: the address has to be renumbered, or the connection has to be replaced by something that translates, which is a different mechanism with its own costs.

The third cost is operational. A route table in a peered VPC contains an entry per peer, and every new peer means editing every participating table. Because tables are per-subnet, a VPC with nine subnets and nine peers has eighty-one route entries to keep consistent. The entries themselves are simple; the bookkeeping is not, and a missed entry produces a subnet that cannot reach one peer while every other subnet can.

The transit gateway as a routing attachment

A transit gateway is a regional router that VPCs and other networks attach to. Each attachment is a connection from a VPC’s subnet to the gateway, and the gateway holds a route table of its own. Traffic from a VPC goes to the gateway because the VPC’s route table has a route for the destination pointing at the attachment; the gateway then looks up the destination in its table and forwards to the appropriate attachment.

The structural difference from peering is that the gateway has an address and a presence. Packets are delivered to it, it makes a decision, and it sends them onward. A third VPC’s traffic can therefore pass through it, because the gateway is a party to every attachment and is authorised to relay between them. Transitivity is restored, and it is restored by inserting a device rather than by changing what a peering connection means.

The route table at the gateway is the control point. Attachments are associated with a table, and the table determines what the gateway will forward where. A common arrangement uses two tables: one for the spoke VPCs, which contains routes to every other spoke and to the shared services VPC, and one for the shared services VPC, which contains routes to the spokes. Separating them means the shared services VPC can reach every spoke while the spokes can reach shared services but not each other, which is a segmentation that peering cannot express at all without a connection per pair.

        ┌──────────── transit gateway (region) ────────────┐
        │  table "spokes"        table "shared"            │
        │   10.1.0.0/16 -> att A   10.0.0.0/16 -> att HUB  │
        │   10.2.0.0/16 -> att B   (default -> none)       │
        └───▲───────────▲──────────────────▲───────────────┘
            │           │                  │
          VPC A       VPC B            VPC HUB (shared services)
        10.1/16      10.2/16            10.0/16

The gateway’s own route lookup obeys the same longest-prefix rule as everything else in the model, and its tables are populated by static entries, by propagation from attachments that support it, and by propagation from VPN or direct-connect attachments that run BGP. That last source is where the gateway stops being a VPC convenience and becomes a piece of routing infrastructure: it can hold routes learned from a customer network and distribute them to every attached VPC, which is the mechanism that makes a hybrid topology manageable. The protocol-level detail of what those sessions carry is in BGP sessions and route propagation over hybrid links.

The costs the gateway introduces

A transit gateway is a device, and devices have properties that a direct connection does not.

Every packet crosses it, so it is a throughput boundary and a failure domain. An attachment is created in a subnet, and the gateway’s availability depends on how many zones it is configured for; a gateway attached in one zone is a single point of failure for every VPC that routes through it. Multi-zone attachment is the standard configuration and it costs an interface per zone per attachment.

The gateway adds a hop to the path, which shows up as additional latency and as an additional place where MTU must be accommodated. An encapsulated packet passing through the gateway may be encapsulated again, and the effective MTU for traffic that traverses two overlays is smaller than for traffic that traverses one. The arithmetic is the same as in MTU and fragmentation across a VPC boundary, applied twice.

Address overlap is not solved. The gateway routes between attachments, and two attachments with the same prefix are indistinguishable to a longest-prefix lookup. Overlapping VPCs still cannot both attach to the same table and expect to reach each other; the gateway reproduces the peering constraint rather than removing it.

And the gateway is a shared resource, so its quotas are shared. Route table entry limits, attachment counts per gateway, and bandwidth per attachment are finite and are consumed by the whole topology. A design that adds one attachment per VPC per environment reaches the attachment limit at a lower VPC count than the per-VPC quotas would suggest, and the limit is on the gateway rather than on any individual VPC.

Choosing between them

Peering is the right mechanism when the number of participants is small, the traffic is heavy, and the relationship is genuinely pairwise. It has no intermediary, so it has no intermediary’s throughput ceiling and no intermediary’s failure mode, and for two VPCs that exchange a large volume of traffic it is strictly cheaper in both latency and cost.

A gateway is the right mechanism when the topology is many-to-many or hub-and-spoke, when segmentation between groups of VPCs is required, and when routes must be learned from outside the provider’s network. Its value is not that it connects VPCs more cheaply per pair; it is that it gives the topology a place to hold policy.

The two compose, and the composition is the common end state. VPCs that exchange the most traffic are peered directly, bypassing the gateway; everything else attaches to the gateway, which carries the learned routes and the segmentation. The routing question then becomes a question of precedence: a VPC with both a peering route and a gateway route for the same prefix has two candidates with the same length, and the tie-break between them determines the path. That tie-break is a documented property of the platform and not a general rule, which is why the two mechanisms should not be pointed at the same prefix unless the intended winner is known.