Four Network Isolation Checks Most VPC Peering Setups Skip

A security group can deny traffic correctly while a route table still sends packets somewhere they should never reach, because route tables and security groups are enforced independently. Peering two VPCs adds routes on both sides; if a route was added more broadly than intended, for instance to an entire CIDR block rather than the specific subnet that needed access, a security group misconfiguration elsewhere can now reach further than anyone realized. Review actual route table entries per VPC, not the peering connection's existence alone.

VPC peering is not transitive: if VPC A peers with VPC B, and VPC B peers with VPC C, A cannot reach C through B without an explicit additional peering connection or a transit gateway. Teams sometimes assume transitivity exists, design a network diagram around that assumption, and only discover it does not work when a service can't reach a dependency two hops away. Confirm this explicitly rather than assuming either way.

A network boundary that is correctly isolated at the routing layer can still leak data if what crosses it is unencrypted and something downstream (a misconfigured load balancer, a debug proxy, a third-party monitoring agent) can observe it. Isolation at the network layer and encryption in transit are two different controls that get conflated. Confirm both independently for anything crossing an environment or trust boundary.

The isolation is only as strong as the permissions on whoever can modify route tables, security groups, and peering connections. If a broad set of engineers has write access to network configuration in a production account, the boundary can be changed by mistake as easily as it was set up correctly, and a well-intentioned fix at 11 p.m. for an unrelated problem is a common way a boundary quietly widens. Restrict write access to network configuration to a small group and require review on changes to anything touching a trust boundary, the same way you would require review on a change to production database permissions.

A common way this goes wrong is testing that a boundary blocks inbound traffic without also testing that it blocks outbound traffic from the more trusted side, since a boundary meant to be one-directional is sometimes accidentally bidirectional or vice versa. Test both directions explicitly, and retest after any change to peering, routing, or security group rules, since a boundary that held yesterday is not guaranteed to hold after today's change. Keep a short record of when each boundary was last tested and by whom, so "we checked that once" has an actual date attached to it instead of being a claim nobody can verify six months later.

Test the boundary in both directions with these steps:

• Confirm the boundary blocks inbound traffic toward the protected side, using the actual route tables and rules rather than the diagram.
• Confirm it also blocks outbound traffic from the more trusted side, since a boundary meant to be one-directional is sometimes accidentally bidirectional.
• Retest after any change to peering, routing or security group rules, because a boundary that held last quarter may not hold now.
• Record what you tested and the result next to the configuration, so the next reviewer can repeat it.

Treat each trust boundary as something with an explicit contract: what is allowed to cross it, in which direction, and why. A diagram alone tends to drift from reality within a few months, because nobody updates a picture when they add one more allowed port for a one-off debugging session. A short written record next to the actual route table and security group configuration, updated whenever either changes, is what lets the next engineer trust the boundary instead of having to re-derive it from scratch.