VPC Peering

What is VPC peering?

VPC peering connects two VPCs — same account or different, same region or across — so instances communicate via private IPs over AWS’s backbone, no internet, gateways, or VPNs involved. Setup is a handshake (request, accept), then both sides add routes toward each other and open security groups. There’s no hourly charge; you pay standard inter-AZ/inter-region data transfer.

Non-transitivity: the property that shapes everything

Peering is strictly pairwise. If A peers with B and B peers with C, A cannot reach C through B — no transit, ever. At three VPCs this is trivia; at thirty it’s an architecture crisis: full connectivity requires n(n-1)/2 meshed peerings (435 for 30 VPCs), each with route and security-group maintenance. This cliff is precisely why Transit Gateway exists — hub-and-spoke attachment with transitive routing, at per-attachment and per-GB prices. The mature rule of thumb: a handful of stable, point-to-point relationships → peering; a growing estate → transit gateway before the mesh metastasizes.

Peering versus PrivateLink

Peering merges networks — bidirectional, all-protocol, subject to CIDR overlap constraints (overlapping ranges cannot peer, which is why IP planning matters years in advance). PrivateLink exposes one service through a keyhole, tolerates overlapping CIDRs, and grants no lateral network access. Security teams increasingly default to PrivateLink and reserve peering for genuinely network-level integration.

What people get wrong

• Adding the route on one side only — traffic flows out and dies; both directions need routes and security-group allowances.
• Assuming DNS just works: cross-VPC private DNS resolution requires enabling DNS resolution options on the peering, a checkbox found only after an hour of debugging.
• Peering as the default when the need was one API — that’s a PrivateLink-shaped requirement.

Primary source: AWS VPC peering documentation

The Non-Transitive Limitation in Practice

VPC peering’s non-transitive nature — a direct connection between A and B, and a separate direct connection between B and C, does not let A reach C — is the single most common source of confusion for teams new to multi-VPC architectures, since it violates the intuitive assumption that network connectivity should compose the way it often does in simpler, flatter networks. This constraint is precisely what motivated the development of Transit Gateway, which acts as a central hub specifically so that connectivity between many VPCs doesn’t require a full mesh of individual pairwise peering connections — a good rule of thumb is that peering remains a reasonable choice for connecting a handful of VPCs with a stable, well-understood topology, while anything approaching a dozen or more interconnected VPCs usually benefits from migrating to a hub-and-spoke model instead.