# VPC Peering

> zop.dev creates VPC peering connections from 5 inputs (requester and accepter VPC IDs, account ID, region, and CIDRs) covering the cross-account handshake. Peering carries no hourly charge, but the CIDR constraint is permanent: 2 VPCs with overlapping ranges can never peer, and peering is never transitive.

Source: https://zop.dev/integrations/provision/aws/vpc-peering
Updated: 2026-08-19

---

VPC peering connects two VPCs so workloads can talk privately across accounts or regions. zop.dev manages peering connections through its provisioner API, including the cross-account handshake details.

## Peering between a requester and accepter VPC

VPC peering connections between a requester and accepter VPC.

## VPC IDs, account, region, and CIDR inputs

```text
requester and accepter VPC IDs, account ID, region, and CIDRs.
```

## Exposed as the vpc_peering resource type

Available through the cloud-resource-provisioner API (resource type vpc_peering).

## A handshake, then routing homework

Peering is a two-party act: a request created in the requester account, an acceptance in the
accepter account, which is why the inputs include both VPC IDs, the account ID, region, and
CIDRs. The provisioner handles that handshake. What an active connection does not do is move
traffic: packets flow only once route tables on both sides point the peer's CIDR at the
connection, and security groups admit the traffic. A peering connection in state active with no
routes moves exactly 0 packets. The most common "peering is broken" report is a missing route,
not a broken peer.

## Overlap is a permanent veto

Two VPCs whose CIDR ranges overlap can never peer, not with any setting and not with any support
ticket. The check happens at connection time, but the mistake happens months earlier, when two
teams independently pick 10.0.0.0/16 because it was the default. Renumbering a VPC later is
effectively a rebuild, so address planning is the one piece of peering work that has to happen
before anyone needs peering.

## No hourly fee, but not free

A peering connection itself has no hourly charge. An idle peer costs nothing, which makes it
safe to establish ahead of need. Traffic across it bills as data transfer at inter-AZ or
inter-region rates, so a chatty service dependency across a peering link has a per-GB cost that
the same dependency within one VPC and AZ would not. Peering is for controlled cross-boundary
access, not for pretending two VPCs are one network.

## Two peers do not make a triangle

Peering is not transitive: A peered with B and B peered with C gives A no path to C. Every pair
that needs to talk needs its own connection, and a full mesh grows quadratically. At hub scale,
that is the point where AWS Transit Gateway becomes the better architecture than peering
sprawl.