The VPC Peering Mistake That Opens Your Whole Network

The peering connection itself just makes two VPCs able to talk. What determines which subnets, which ports, and which specific resources are actually reachable is the route table and security group configuration on both sides. A common mistake is peering two full VPCs to solve a narrow problem, like letting one service reach one database, and leaving the route tables wide open by default, which means every subnet in VPC A can now reach every subnet in VPC B unless something else stops it.

The fix is treating route tables as the actual access control layer they are: route only the specific address ranges that need to talk to each other, not the whole VPC range, even when peering the whole VPC would be less work today.

VPC peering is explicitly non transitive: if VPC A peers with VPC B, and VPC B peers with VPC C, A cannot reach C through B. This is usually correct and safe, but it creates a different, more dangerous assumption: that because peering isn't transitive, a compromised host in A also can't reach C. That's true only for the network layer. If a service in A authenticates to a shared resource, a database, an internal API, that also happens to be reachable from C through some other path, the isolation you're relying on isn't actually there.

Map out shared resources across your peered VPCs specifically, not just the peering connections themselves, since that's where the real transitive risk lives.

Network isolation is not a substitute for patching. Federal guidance on this is a useful bar even outside government work: critical vulnerabilities on internet accessible systems get fifteen calendar days to remediate, and known exploited vulnerabilities assigned a CVE since 2021 get fourteen¹. If any host inside your peered network has a public IP or sits behind a load balancer that's internet facing, treat it as internet accessible for patching purposes regardless of how private the surrounding network looks, because that's exactly the host an attacker reaches first, and everything peered to it becomes reachable from there.

A well isolated network with an unpatched internet facing host in it is not actually isolated, it just delayed the discovery.

The only reliable way to know your isolation actually works is to attempt the access you believe is blocked, from inside the network, on a recurring schedule rather than once at setup. Pick a handful of paths that should be denied, one VPC's subnet reaching a specific port in another it has no business reaching, and verify the attempt actually fails. Automated network path testing tools exist for this, but even a quarterly manual check with a documented list of expected denials catches configuration drift that accumulates from small changes nobody thought to re-review.

Compare threat detection platforms if you're also evaluating tools that would flag this kind of lateral movement attempt in real time.

A recurring isolation test can follow these steps:

1. List a handful of network paths that should be denied, such as one VPC's subnet reaching a specific port in another VPC.
2. Attempt each blocked connection from inside the network, since that is where a misconfigured peering route would show up.
3. Confirm every attempt actually fails, and treat any success as a finding to fix right away.
4. Automate the checks so they run on a schedule instead of only at initial setup.
5. Update the list whenever a new peering connection or route is added.

Every peering connection should have a one line written justification: which service needs to reach which resource, and why. Without this, route tables accumulate scope creep as engineers widen access to unblock themselves quickly, and six months later nobody can say which of the connections are load bearing and which are leftover from a project that ended. When a security review asks why VPC A can reach a subnet in VPC C, the answer needs to be a documented reason, not a shrug and a promise to look into it.

This document is also what makes testing meaningful: you can't verify access matches intent if intent was never written down.