Transit Gateway route tables are the standard answer to environment isolation in AWS. You put production VPCs on one route table, staging on another, and prevent cross-propagation between them. It works — at the TGW layer.
The problem is that the TGW layer is not the only layer.
We see this gap repeatedly in AWS environments that have grown beyond a handful of VPCs. The TGW isolation is real, correctly configured, and completely bypassed by a single VPC peering connection that nobody is tracking.
How TGW Isolation Is Supposed to Work
Transit Gateway route tables control which VPC attachments can reach each other through the TGW. A typical isolation setup looks like this:
At the TGW layer, production and staging cannot reach each other. Traffic from prod-api destined for 10.3.0.0/16 (staging-api) has no TGW route and is dropped. Most teams stop here and consider the environments isolated.
Where the Gap Opens
VPC peering connections operate completely independently of Transit Gateway routing. A VPC peering is a direct, private connection between two VPCs — it does not pass through the TGW, is not subject to TGW route table rules, and is not visible in the TGW console.
If a peering exists between prod-api and staging-api, and both VPCs have routes pointing to that peering, traffic flows directly between them — regardless of what your TGW route tables say. The route table in prod-api might look like this:
10.1.0.0/16 → tgw-xxxxxxxxx # prod-data, via TGW ✓
10.2.0.0/16 → tgw-xxxxxxxxx # prod-shared, via TGW ✓
10.3.0.0/16 → pcx-xxxxxxxxx # staging-api, via peering ✗
0.0.0.0/0 → nat-xxxxxxxxxThat third route is the breach. It sits in the same route table as the legitimate TGW routes, unremarkable unless you are specifically looking for cross-environment peering routes.
How This Happens in Practice
VPC peerings get added for legitimate reasons and then outlive their purpose:
The debugging peering
A developer needs to debug an issue that crosses the production/staging boundary and adds a peering temporarily. The incident is resolved, the ticket is closed, the peering stays.
The migration remnant
A shared service was initially deployed in staging before being promoted to production. The peering that enabled the transition was never removed after the migration completed.
The incident shortcut
An infrastructure change was made under incident pressure, documented in a ticket that got closed, and the cleanup task was never created. The peering is still active six months later.
In the TGW console, everything looks correct — separate route tables, no cross-environment propagations. In the VPC peering console, the connection shows as "active" — which is technically accurate, but gives no indication that it violates an isolation policy.
The Compliance Consequence
PCI-DSS Audit Finding
For environments carrying PCI scope, a direct network path from a non-PCI environment into a PCI-scoped VPC is an automatic audit finding.
PCI-DSS requirements 1.3.1 and 1.3.2 require that inbound and outbound traffic to and from the cardholder data environment is restricted to only that which is necessary. A VPC peering from staging into a PCI-scoped production VPC does not meet this bar — and your QSA will find it.
The worst part: by the time the QSA finds it, the peering has been in place for months. The audit trail shows a sustained period of non-compliance, not a momentary misconfiguration.
What Complete Isolation Verification Looks Like
Checking TGW route tables is necessary but not sufficient. A complete isolation audit requires:
Enumerate all VPC peering connections — not just the ones you know about, but all active peerings in every account.
Check both sides of each peering — a peering connection existing is not enough; routes must exist in both VPCs for traffic to actually flow.
Map peering endpoints to environment groups — identify which environment each peered VPC belongs to (production, staging, CDE, etc.).
Flag any peering that crosses environment boundaries — prod↔staging, prod↔dev, PCI-scope↔non-PCI.
Repeat across all accounts and regions — peerings can cross account boundaries and are managed per-account, not centrally.
Run this continuously — networks change. New peerings get added. The check needs to run on every scan, not once a quarter.
How Netway Detects This
Netway's topology collector maps all VPC peerings across your configured accounts and regions on every scan. It evaluates each peering against the isolation rules you define — for example, "production must not connect to staging."
The evaluation is routing-plane: Netway checks whether a network path actually exists between the two environment groups, not just whether a peering connection exists. A peering with no matching routes on both sides does not constitute a path and is not flagged as a breach.
When a breach is found, Netway traces the full path — which VPC, which peering, which destination — and records it with a timestamp in an immutable log. The finding triggers a Slack alert immediately. The full path is included in the compliance report for your QSA.
The Fix
Getting Started
Register at netway.basavytix.com
Run the CloudFormation deploy command shown in your dashboard
Run the scan
Define your isolation rules in the Compliance tab — Netway evaluates every peering and TGW path against them on every scan