Designing VPC Peering So One Breach Doesn't Spread

A VPC peering connection routes traffic between two networks; it doesn't restrict which resources within those networks can talk to each other. That restriction is a separate layer, built with security groups scoped to specific services and network ACLs scoped to specific subnets, and it has to be designed on purpose.

Teams that skip this step usually don't notice, because normal traffic flows exactly as expected. The gap only shows up during an incident, when something that should have been contained instead has a clear path to everything else.

Before connecting anything, ask: if this specific service were compromised, what should it be able to reach, and what should it never be able to reach? A public-facing API service should reach its own database. It has no legitimate reason to reach your internal admin tooling, your CI/CD credentials store, or another team's production database.

Once you've answered that for your highest-risk services, the network design follows from the answer, rather than the answer being an afterthought bolted onto whatever topology was easiest to set up.

Take a common starting point: one VPC holding public-facing services, internal tools, and a database, all able to reach each other freely. Split it into three tiers, public-facing, internal, and data, each in its own subnet with security groups that only allow the specific, named connections each tier actually needs.

The public tier can reach the data tier on its specific database port. It cannot reach the internal tier at all. If a public-facing service is compromised, the attacker's next move is blocked at the network layer, not just hoped against.

The internal tier gets its own, tighter rule: it can reach the data tier, and it can reach the public tier's services on the specific ports those services expose, but nothing reaches it from outside except through a bastion or a VPN, so internal tools never end up sitting one misconfigured rule away from the open internet.

The split follows these steps:

1. Place public-facing services, internal tools, and the database into three tiers, each in its own subnet.
2. Write security groups for each tier that allow only the specific, named connections that tier actually needs.
3. Let the public tier reach the data tier only for the specific data access it requires.
4. Add network ACLs at the subnet level as a coarse backstop that blocks whole classes of traffic.
5. Test from a public-tier instance that internal-tier resources are actually unreachable, rather than trusting the diagram.

Security groups are stateful and attached to specific resources, which makes them good for expressing "this service can talk to that service." Network ACLs are stateless and attached to subnets, which makes them a good coarse backstop, a rule that blocks a whole class of traffic regardless of which specific resource is misconfigured.

Use both. A security group misconfiguration is a mistake anyone can make; a network ACL at the subnet boundary is what keeps that single mistake from becoming a wide-open path.

The two also fail differently, which is the real reason to use both. A security group that's too permissive usually still requires the attacker to know a resource exists and target it directly. A network ACL gap tends to be broader and easier to stumble into by accident, which is exactly the kind of mistake a coarse, subnet-level rule is meant to catch.

The only real test is to try the connection you designed against. From a test instance in your public tier, attempt to reach a resource in your internal tier that shouldn't be reachable, and confirm it's actually blocked, not just assumed blocked because the diagram says so.

Federal guidance treats a critical vulnerability on an internet-accessible system as urgent enough to need remediation within 15 days, twice the window given to the same flaw on an internal-only system; good isolation is what keeps more of your services out of that faster, harder tier in the first place¹.