VPC Peering Looks Like Isolation Until You Check the Routes

Peering connects two networks directly, but it doesn't automatically restrict what traffic is allowed between them, that's still down to security groups, network ACLs, and route tables on both sides. A peering connection with no traffic restrictions is functionally one flat network, regardless of how many separate VPCs you drew on the architecture diagram.

Treat the peering connection itself as neutral plumbing. The isolation, or lack of it, lives entirely in the rules layered on top, and those rules need the same review a firewall change would get.

VPC peering is explicitly not transitive by design: if network A peers with B, and B peers with C, A cannot reach C through B automatically. Teams often recreate transitivity anyway, without meaning to, by adding a direct A-to-C peering connection later because two services needed to talk, without revisiting whether that new connection quietly exposes A to everything already reachable from C.

Every new peering connection should be evaluated against the full graph of what's already connected, not just the two networks being joined. A connection that looks isolated in isolation can complete a path across your entire network.

Peering works cleanly for a small, stable number of connections, a handful of VPCs that all need to talk to each other. Past roughly a dozen networks, the number of individual peering connections to manage grows fast enough that a transit gateway, a hub that all networks connect to once, becomes easier to reason about and audit, since there's one central place to review routes instead of a mesh of point-to-point pairs.

PrivateLink, or an equivalent private-endpoint service, fits a different case: exposing one specific service to another network without connecting the networks at all. Reach for it when you want to share one thing, not everything reachable from a peer, such as giving a partner team access to a single API without opening a path to your database subnet in the process.

As a decision rule, ask what you are trying to share. If two networks genuinely need broad, two-way communication, peering or a transit gateway fits. If a partner team needs one API, use a private endpoint and leave the networks unconnected. For example, giving a partner access to a single reporting service through a private endpoint means they never gain a route toward your database subnet, even if someone later widens a security group by mistake. Choosing the narrowest connection that solves the problem keeps the audit smaller and the segmentation easier to prove.

The architecture diagram describes intent. The route tables and security group rules describe reality, and the two drift apart faster than most teams expect, usually because a diagram gets updated when a project launches and never again. A practical audit starts from the route tables, not the diagram, and traces every path a packet could actually take between your most sensitive network and everything else.

Run this as a scheduled review, not a one-time exercise. Every new peering connection, every widened security group rule, is a small change that individually looks safe and collectively can undo a segmentation model built over months. The engineer who added a rule to unblock one deploy rarely comes back later to check whether it's still needed.

A practical route-table audit follows these steps:

1. Start from the route tables instead of the architecture diagram, since the tables describe what is actually reachable.
2. Trace every path a packet could take between your most sensitive network and everything else.
3. Review security group rules and network ACLs on both sides of each peering connection.
4. Evaluate every new peering request against the full graph of existing connections, not just the two networks being joined.
5. Repeat the review on a schedule, because small widened rules add up to real drift.

Network isolation buys you time, not immunity. CISA's own directive to federal agencies still requires patching a critical, internet-facing vulnerability within 15 calendar days¹, and an internal service sitting behind three layers of VPC peering doesn't get a pass on remediation just because it's harder to reach directly from the internet.

Treat isolation and patching as separate controls that both need to work, not as substitutes for each other. A well-isolated network with unpatched services is still one misconfigured route away from an exposed one.