VPC Peering
What does zop.dev create for VPC Peering?
zop.dev creates VPC peering as part of connecting a cluster to a datastore in another VPC of the same AWS account, in 1 region or across 2. It accepts the peering, adds routes in every route table on both sides, and opens the datastore's engine port to the cluster's CIDR. Peering carries no hourly charge.
| Field | Value |
|---|---|
| Cloud | aws |
VPC peering connects two VPCs so workloads can talk privately. zop.dev sets it up when you connect a cluster to a datastore that lives in a different VPC, and handles the routing and firewall work on both sides.
Peering between a cluster VPC and a datastore VPC
A peering connection from the cluster’s VPC to the datastore’s VPC, accepted automatically, with reciprocal routes and a security-group rule for the datastore’s port.
Inputs come from the connection
cluster VPC and region; datastore VPC and region; datastore engine port. Both VPCs are in the same AWS account; the regions may differ.Created as a datastore-to-cluster connection
Not a free-standing resource type: peering is one step of a connection between a cluster and a datastore.
Accept, route, and open the port
Peering normally takes a request on one side and an acceptance on the other, and an active connection moves no traffic until route tables on both sides point the peer’s CIDR at it. zop.dev does all three: it accepts the peering, adds a route to the peer’s CIDR in every route table of both VPCs, and opens the datastore’s engine port to the cluster’s CIDR on the datastore’s security groups. If traffic still fails, check route tables and security groups you manage outside zop.dev.
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.