What a Misconfigured VPC Peering Connection Actually Breaks

A team peers their application VPC with a partner's VPC so one internal service can call a shared API over private IPs instead of the public internet. The route table entry they add, to keep things simple, covers the partner's entire CIDR block rather than the single subnet the shared service lives in.

At the time, this looks harmless: the security group on the calling service still restricts which ports are open, so the wider route doesn't seem to matter.

Months later, the partner spins up a new subnet in that same VPC for an unrelated internal tool, with a permissive security group because it's meant to be internal-only on their side. Because the peering route covers the whole CIDR block, every instance in the original VPC can now reach that new subnet, and because the new subnet's own security posture assumed nothing outside its VPC could reach it, the two teams have accidentally built a path neither side intended or reviewed.

Neither team's own change, viewed alone, looks wrong. The original wide route and the partner's assumption of isolation only become a problem together.

A routine network scan turned up a service responding on an unexpected private IP range. Tracing it back took longer than it should have, because the peering connection wasn't documented anywhere beyond the initial ticket that created it, and nobody currently on the team had context on why the route existed at that scope.

Scope every peering route to the specific subnet or CIDR the integration actually needs, never the whole VPC, even when it's more convenient to write once. Document every peering connection with the specific service and subnet it's meant to serve, in a place your team actually checks, not just the ticket that created it. Review peering routes on a schedule, not only when something breaks, since drift on the other side of the connection is invisible to you until you look. Treat any new subnet inside a peered VPC as a security review trigger on your own side, since your security posture now depends on decisions made outside your team.

Run these checks on every peering connection:

• Scope each peering route to the specific subnet or CIDR the integration needs, never the whole VPC, even when the broad route is quicker to write.
• Document the service and subnet each peering connection exists for, in a place your team actually checks rather than only in the original ticket.
• Review peering routes on a schedule, and again whenever a partner adds subnets, instead of waiting for something to break.
• Assign a named owner to every peering connection so responsibility persists after the engineer who created it moves on.

Nobody owned the route after the ticket that created it closed. That's the real pattern behind most stale network configuration: it was correct and reasonable at the moment someone wrote it, and became wrong through a change on a system nobody on your side was watching. The fix isn't reviewing harder once; it's assigning ownership that persists past the original engineer moving to a different project.

If you can't name, right now, who owns each peering connection in your account, that's the gap to close before the next audit or the next incident finds it for you.

The remediation itself took under an hour: narrow the route table entry to the one subnet the shared API lived in, confirm the calling service still worked, and remove the broader entry. The slower part was the process change that came after: a short internal policy that every new peering connection required a named owner and a route scoped to a specific subnet before it could be approved, checked at the same review gate as any other production network change.

That policy change is the part worth copying even if you've never had an incident like this one. It costs almost nothing to add a scoping requirement to a peering request template, and it removes the exact ambiguity that let this gap sit unnoticed for months.