Why architecture matters here
The architecture matters because the private path it provides is not a convenience but a security and performance requirement. Routing inter-VPC traffic over the public internet — via public IPs, NAT, and internet gateways — exposes it to the internet's threat surface, adds latency and egress cost, and forces encryption and firewalling you would not otherwise need. Peering keeps the traffic on the provider's backbone, addressed by private IP, isolated from the internet entirely. For workloads moving sensitive data between a shared-services network and an application network, that private path is the difference between a clean internal architecture and a pile of internet-facing endpoints that each become an attack surface.
It matters because the non-overlapping-CIDR rule forces address planning to be a first-class design activity rather than a per-team accident. When VPCs are created independently, each team reaches for the same friendly default range, and two 10.0.0.0/16 networks can never be peered because a packet destined for 10.0.1.5 is ambiguous. Retrofitting non-overlapping ranges after the fact means renumbering a live network — one of the most painful operations in infrastructure. The peering model makes IP address management (IPAM) a prerequisite: allocate disjoint blocks from a central plan up front, and peering stays trivial; skip it, and every future connection becomes a renumbering project.
The architecture matters, too, because non-transitivity dictates topology. Because A-B and B-C does not yield A-C, you cannot build a large network by chaining peerings through a hub VPC — the hub can reach every spoke, but the spokes cannot reach each other through it. To fully connect N VPCs with raw peering you need a mesh of N(N-1)/2 connections, and both the connection count and the route-table entries explode quadratically. This is the single most important thing to internalize about peering: it is a two-party primitive, and the moment your topology needs many-to-many connectivity, peering alone stops scaling and you must reach for a transit gateway, a cloud WAN, or a routed hub appliance.
Finally, it matters because connectivity is symmetric and easy to get half-right. For traffic to flow, both VPCs must have a route to the other's CIDR through the peering connection, and the security groups or firewall rules on both sides must permit the peer's address ranges. A one-directional route or a missing security-group rule produces the maddening symptom of packets leaving but never returning, or a connection that opens but hangs. Peering makes the network path available, but it deliberately does not open any traffic; the operator must configure routing and filtering on both ends, and the discipline of keeping those symmetric is where peering setups succeed or silently fail.
The architecture: every piece explained
Left and right: the two networks. VPC A and VPC B are independent virtual networks, each with its own address range — say 10.0.0.0/16 and 10.1.0.0/16. The single hard requirement before anything else is that these ranges do not overlap; if they did, a private IP could belong to either network and routing would be undefined, so the provider refuses the peering. Disjoint CIDRs are the precondition, which is why the diagram calls out 'no CIDR overlap' as a first-class element rather than a footnote.
Center: the connection handshake. A peering connection is established by a two-party handshake — one VPC is the requester, which initiates, and the other is the accepter, which approves. This deliberate accept step exists because peering often crosses ownership boundaries (different teams, different accounts, even different organizations), and no one should be able to attach to your network unilaterally. Once requested and accepted, the connection exists — but, critically, no traffic flows yet. The connection is merely the possibility of private routing between the two.
Middle row: making traffic actually flow. Two more things must be configured on both sides. First, route tables in each VPC must add a route for the peer's CIDR pointing at the peering connection, so packets destined for the other network are sent over it rather than dropped or sent to a gateway. Second, security groups (or network ACLs / firewall rules) must permit traffic from the peer's address ranges, because peering opens a path but grants no permissions. Both must be symmetric: a route on only one side means replies have nowhere to go, and a security-group rule on only one side means the handshake never completes. The no CIDR overlap box sits here too as the constant invariant that makes the routes unambiguous.
Bottom row: the scaling limits and the escape hatch. Peering is non-transitive — an A-B peering plus a B-C peering does not yield A-C connectivity; B will not forward between its peers. This is by design (it keeps peering a clean two-party relationship) and it is the reason a hub-and-spoke built purely from peerings does not give spoke-to-spoke reach. When the topology needs many-to-many connectivity, teams graduate to a transit gateway (a managed routed hub that is transitive) or a full mesh. The ops strip captures the disciplines that keep peering healthy: central CIDR planning so ranges never collide, symmetric routes and security groups on both sides, DNS configured to resolve across the peer, and awareness of per-VPC peering count limits before the mesh grows too large.
End-to-end flow
Trace connecting an application VPC to a shared-services VPC that hosts centralized logging, monitoring, and an internal package registry, then watch what happens as the topology grows.
Address planning: before any connection, the platform team confirms the two VPCs have disjoint ranges — the app VPC on 10.20.0.0/16 and shared-services on 10.10.0.0/16, both allocated from a central IPAM plan that reserves a distinct block per VPC. Because the ranges were planned up front, no renumbering is needed; the peering can proceed immediately. Had both defaulted to 10.0.0.0/16, this step would have stalled into a renumbering project.
Handshake: the app VPC's owner initiates a peering request to the shared-services VPC; because the two live in different accounts owned by different teams, the shared-services owner reviews and accepts. The peering connection now exists. A quick connectivity test still fails — no traffic flows yet — because the connection alone routes nothing. This is the expected intermediate state, and mistaking it for a broken peering is a common early confusion.
Routing and filtering: the app team adds a route in the app VPC's route tables for 10.10.0.0/16 via the peering connection, and the shared-services team adds a mirror route for 10.20.0.0/16 back through it. Then each side updates security groups: the logging endpoints in shared-services allow inbound from the app VPC's range, and the app instances allow the responses. With symmetric routes and symmetric rules in place, an app instance can now reach the internal registry by private IP over the backbone — low latency, no internet, no gateway. A test connection succeeds in both directions.
DNS across the peer: the app team wants to reach services by name, not raw IP, so they enable cross-VPC DNS resolution and associate the shared-services private hosted zone with the app VPC. Now registry.internal resolves to the shared-services private IP from inside the app VPC, and the connection works by hostname. Without this step, peering would carry the packets but names would not resolve — a frequent and confusing gap where connectivity 'works' by IP but every application configured with hostnames fails.
Growth exposes the limit: months later there are a dozen application VPCs that all need shared-services, and several also need to reach each other. Peering each pair directly would mean dozens of connections and route entries, and the many-to-many requirement runs straight into non-transitivity — spokes cannot reach each other through the shared-services hub. The team migrates to a transit gateway: every VPC attaches once to the gateway, which routes transitively between them, collapsing the quadratic mesh into a linear hub. Peering was the right tool for two networks; the transit gateway is the right tool for twelve. Recognizing exactly when to cross that line is the architectural judgment the whole flow builds toward.