VPC Peering

Two separate VPCs (different teams, accounts, or even a shared-services VPC) often need to talk to each other privately, without routing through the public internet or a VPN. VPC Peering solves this by creating a direct, private network connection between exactly two VPCs — traffic flows over AWS’s internal network as if the two VPCs shared the same network, using private IP addresses.

• A peering connection links exactly two VPCs — it can be same-region, cross-region, and even cross-account.
• Peering is not transitive: if VPC A peers with VPC B, and B peers with C, A cannot reach C through B — you’d need a direct A↔C peering connection too.
• Each VPC’s route table must be updated to send traffic destined for the peer’s CIDR through the peering connection.

graph LR
subgraph A["VPC A — 10.0.0.0/16"]
  A1["App"]
end
subgraph B["VPC B — 10.1.0.0/16"]
  B1["Shared Service"]
end
A <-->|"Peering Connection"| B
classDef vpcA fill:transparent,stroke:#8b3de0,stroke-width:3px
classDef vpcB fill:transparent,stroke:#3b82f6,stroke-width:3px

Creating a peering connection is free — you only pay standard data transfer rates for traffic that crosses it (cross-AZ or cross-region rates apply when relevant).

• Non-transitivity is the single most tested fact about VPC Peering — a full mesh of n VPCs needs n(n-1)/2 individual peering connections, which gets unwieldy fast (this is exactly the problem Transit Gateway solves).
• Peered VPCs cannot have overlapping CIDR blocks — overlapping ranges make peering impossible.
• Peering connections do not support edge-to-edge routing — a peered VPC cannot use the other VPC’s Internet Gateway, NAT Gateway, VPN, or Direct Connect connection to reach beyond itself.
• Security Groups can reference a security group in the peered VPC directly (in supported scenarios), simplifying cross-VPC access rules.