A Practical Checklist for VPC Peering and Network Isolation
Network isolation is easy to get mostly right and quietly wrong in ways that don't show up until someone goes looking for them, or worse, until an incident does. VPC peering in particular tends to accumulate exceptions over time, a rule added for one integration, a route left over from a project that ended. Here's a checklist for finding those before someone else does.
Vendors Covered in this Article
Disclosure: We may earn a commission if you buy through some links on this page. It doesn't change what we recommend.
Peering connections don't automatically respect your intended boundaries
A VPC peering connection routes traffic between two networks at the network layer, but it doesn't understand or enforce your application's security intent on its own. If you peer a production VPC with a staging or development VPC for convenience, every security group rule and route table entry on both sides now matters for production security, not just the ones you were thinking about when you set up the peering. Review peering connections as a full merge of two security boundaries, not a narrow pipe for one specific purpose.
Why do security group rules drift toward permissive?
Security group rules tend to get added quickly when something breaks and rarely get removed once whatever needed them is gone. A rule opened to unblock a one-time data migration or a debugging session has a way of staying open indefinitely because removing it feels riskier than leaving it, until nobody remembers why it exists. Schedule a recurring review, quarterly is reasonable, that specifically looks for rules with unusually broad scope, like a wide port range or a source that's broader than a specific known service, and either justify or remove each one. Give each surviving rule an owner and a reason, written down, so the next review starts from a record instead of from scratch.
Transit gateways and hub-and-spoke topologies concentrate risk
As the number of VPCs grows, a transit gateway or hub-and-spoke topology is often the right architectural move for manageability, but it also means a misconfiguration at the hub can expose every connected spoke at once. Give changes to hub-level routing tables and shared security groups more scrutiny than a change to any single spoke's configuration, including a mandatory second reviewer, since the blast radius of a mistake there is structurally larger than anywhere else in the network. A staging copy of the hub configuration, tested before rollout, is worth the extra setup for exactly this reason.
Attack surface scanning catches what manual review misses
Manual review of security groups and route tables works until the environment gets too large or changes too often for anyone to hold the whole picture in their head, which happens faster than most teams expect. Continuous attack surface scanning tools like Tenable are built specifically to catch unintentionally exposed ports, overly broad rules, and configuration drift across a growing set of VPCs and peering connections, which is exactly the kind of accumulation manual quarterly review is prone to missing between cycles.
How do you test that network isolation really works?
Reading your own security group rules tells you what you intended. Actually attempting a connection from an isolated network segment to something it shouldn't be able to reach tells you what's actually true. Run this kind of isolation test after any significant network change, and periodically even without one, since configuration drift accumulates from changes nobody remembers making. If the test connection succeeds when it shouldn't, that's a finding worth treating with real urgency, not filing away for later.
Document the intended topology so drift is visible
Keep a simple, current diagram or written description of which networks are supposed to talk to which, and what specifically each peering connection exists for. Without that reference, every review starts from scratch trying to reconstruct intent from configuration alone, which is slow and error-prone, and it's easy to mistake a rule that's merely present for a rule that's actually supposed to be there. A short, maintained document turns the recurring review from an investigation into a comparison, which is faster, catches more, and doesn't depend on one person's memory of decisions made months earlier.
A review checklist for peering and isolation:
- Review each peering connection as a merge of two full security boundaries, especially when staging or development is peered with production.
- Remove security group rules opened for one-time migrations or debugging sessions that no longer have a purpose.
- Require a mandatory second review for changes to transit gateway or hub routing tables and shared security groups.
- Use continuous attack surface scanning to catch exposed ports, overly broad rules and configuration drift.
- Attempt a real connection from a segment that should be isolated to a resource it should not reach.
- Keep a current diagram stating which networks should talk to each other and why each peering exists.
What Good Looks Like
Good network isolation means an actual connection attempt from an unauthorized segment fails, not just that the configuration reads correctly on review.
Building The Capability (5-Stage Skill Ladder)
How to Get Started
Disclosure: We may earn a commission if you buy through some links on this page. It doesn't change what we recommend.
Frequently Asked Questions
Is VPC peering itself a security risk, or is it about how it's configured?
Peering itself is a routing mechanism, not inherently risky. The risk comes from treating a peering connection as a narrow, purpose-specific pipe when it actually merges two full network security boundaries, which means every rule on both sides now matters together.
How often should we review security group rules for drift?
Quarterly is a reasonable baseline for most small and mid-sized teams, with an additional review after any significant infrastructure change. Environments that change frequently or have many contributors may need it more often, since drift accumulates faster than a fixed schedule can always catch.
What's the fastest way to check if our network isolation actually works?
Attempt a real connection from a segment that should be isolated to a resource it shouldn't be able to reach, rather than only reading the configuration. If the connection succeeds, you've found a real gap, and if it fails as expected, you've confirmed the control actually works under test, not just on paper.
About the numbers
This guide doesn't quote a sourced benchmark. Figures in it are estimates or general guidance, so check them against your own numbers.
Related Guides
Where VPC Peering Breaks Down and How to Isolate Blast Radius Instead
Why VPC peering alone doesn't isolate anything, and a more reliable way to contain blast radius between services and environments.
What a Misconfigured VPC Peering Connection Actually Breaks
A walkthrough of a real VPC peering misconfiguration, what it exposed, and the four checks that would have caught it before it shipped.
The VPC Peering Mistake That Opens Your Whole Network
How VPC peering misconfigurations quietly expose more of your network than intended, and four concrete checks that catch the mistake before an audit does.
VPC Peering Looks Like Isolation Until You Check the Routes
VPC peering can silently become transitive, undoing the isolation you thought you had. Here is how to audit what can actually reach what in your network.
Four Network Isolation Checks Most VPC Peering Setups Skip
Four specific checks for VPC peering and network isolation setups, plus the pitfalls that let a segmentation boundary look correct while quietly failing.
Designing VPC Peering So One Breach Doesn't Spread
Why VPC peering isn't isolation by default, how to draw blast radius before you draw a network diagram, and how to prove a compromised service is contained.