Skip to main content
provisioning · aws

VPC Peering

category
Networking

What does zop.dev create for 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.

Module backing VPC Peering.
Field Value
Cloudaws

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

Terminal window
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.

See it fire on your bill.

Connect an account read-only. The first findings land in minutes.

417 rule families across 353 resource types on 22 platforms. Every threshold, metric, and IAM action is documented on these pages before you grant anything.

417 rule families documented
353 resource types covered
read-only default access level
Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console· Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console·