Where VPC Peering Breaks Down and How to Isolate Blast Radius Instead

Once two VPCs are peered, every subnet in one can potentially reach every subnet in the other unless you've layered security groups or network ACLs on top. A lot of teams set up peering to solve a connectivity problem, get it working, and never go back to add the restrictive rules that turn a flat connected network into an isolated one.

The peering connection itself doesn't degrade over time, but the assumption that "we'll tighten this later" almost always does. Once the connection works and the immediate task is done, tightening it stops being anyone's priority until an incident or an audit forces the question.

The useful question isn't "which team owns this service," it's "if this service is compromised, what else can it reach." Group services by how much damage a breach there could do, not by which team built them.

A logging pipeline and a payments service might sit in the same VPC today for convenience; they shouldn't share a blast radius, because the two have completely different consequences if compromised, and grouping them by org chart instead of risk is how a low-stakes service ends up with a path to your highest-stakes data.

For example, a logging pipeline and a payments service share a VPC because they were set up in the same sprint. Sort them by consequence instead: the payments service gets its own security group, no inbound path from the logging tier, and an egress allow-list limited to the processors it actually calls. The logging pipeline keeps broader access, but it can no longer reach the payments database. If the pipeline is compromised, the attacker lands in a low-value zone with no route to your most sensitive data. The cost is a few extra rules, and the benefit is a much smaller worst case.

Federal patch rules require closing a known exploited vulnerability on an internet-accessible system on a tight clock, and that clock is far more forgiving for something genuinely internal and isolated¹.

Good network isolation isn't just a security nicety, it directly changes how urgently you have to respond to a given vulnerability, because it changes whether the system in question is exposed at all. A well-isolated internal service that's technically vulnerable is a lower-urgency ticket than the same vulnerability on something internet-facing, and your patch triage should reflect that difference.

Pick a service at random and ask: can someone with access to it reach the production database directly? Can it reach a third-party API with your production credentials?

If the answer is yes for a service that has no business need for that reach, you have connectivity, not isolation, no matter how the network diagram looks. Run this test on two or three services every quarter rather than trying to audit everything at once, since a full audit is easy to schedule and then never actually finish.

Run these checks on two or three services each quarter:

• Ask whether someone with access to the service can reach the production database directly when there is no business need for that reach.
• Ask whether the service can call a third-party API using your production credentials.
• Check which outbound destinations it can reach, and whether a default-deny egress rule with an allow-list built from real traffic logs exists.
• Confirm that staging and development environments holding production-like data get the same blast-radius scrutiny as production.

Most isolation work focuses on what can get in. What can get out matters just as much: a compromised service that can freely call any external endpoint is how a contained breach becomes a data exfiltration incident.

Default-deny egress rules, with explicit allow-lists for what a service actually needs to call, close this gap and are usually cheaper to implement than people expect. Start with your highest-risk service, build its allow-list from real traffic logs rather than guessing, and expand from there.

It's common to lock down production tightly and leave staging or a shared development environment flat, reachable from anywhere, with a copy of production data sitting in it. That's often the weaker door into the same data a well-isolated production network is protecting.

Apply the same blast-radius thinking to non-production environments that hold anything resembling real customer data, or the careful isolation work in production is protecting a system that has a second, easier way in. The simplest fix for a lot of teams is to stop copying real production data into staging at all, and use a scrubbed or synthetic dataset instead, which removes the incentive to isolate that environment as tightly in the first place.