The multi-account visibility problem
The multi-account AWS strategy is correct. Separate IAM boundaries, separate security controls, separate blast radii. That's the whole point.
But the networks connecting those accounts don't respect account boundaries. A VPC peering, a Transit Gateway attachment, a cross-region route — and suddenly two accounts that are supposed to be isolated have a path between them that nobody put on a diagram and nobody is monitoring.
Palo Alto Unit 42
Gartner
The attack pattern is almost always the same: an attacker gains access to a lower-trust account — dev, staging, an acquired company — and finds a network path into production that nobody knew existed. Not because of a configuration error. Because nobody had a map.
The demo environment
The topology below shows a three-account environment: a corporate production account with five VPCs across two regions (us-east-2 and eu-west-1), a staging account, and an acquired company's account. On paper, the architecture follows AWS best practices — a shared-services hub, environment separation, a dedicated EU data VPC for GDPR compliance.
One Netway scan across all three accounts produced three findings. Here's what was found — and what it means.
Finding 1: EU data routable to US infrastructure
EU personal data with a network path to US infrastructure
eu-data — the EU personal data VPC in eu-west-1 — holds EU customer PII: names, emails, transaction records. It sits in eu-west-1 specifically because it has to, for data residency compliance.
A cross-region VPC peering connects eu-data to prod-data in us-east-2. That peering means EU personal data has a routable network path to US infrastructure.
The peering was added during a database migration. The migration completed. The peering wasn't cleaned up. It had been live for seven months. The DPO didn't know. Netway was the first thing that found it.
Finding 2: Dev-to-production shadow highway
Two-hop path from development into production through shared-services
dev-api and prod-shared are not directly peered — that's correct. But dev-api connects to shared-services, and shared-services connects to prod-shared.
Two hops. dev-api → shared-services → prod-shared. A routable path from development into the production hub — and from there into prod-api and prod-data.
Both peerings are individually legitimate. The dev team connected to shared-services for internal tooling. The prod team connected to shared-services for internal APIs. Neither team created a problem on their own. Together they did. No single team could see the combined path — it crossed account boundaries.
Finding 3: M&A ghost account still in production
Acquired company's VPC peered directly into production — no owner, no patches
acq-prod — the acquired company's VPC — is still peered directly into prod-shared. The acquisition closed. The integration team dissolved. The peering was never reviewed or removed.
No owner tag on any resource. Two EC2 instances running unmonitored. No one on the network team, security team, or finance team knew this account still had access to production.
The peering is a direct connection — not two hops. An attacker with access to the acquired account has direct network access to the production hub.
Why none of this was visible
Each team saw only their own account. The network team saw the prod-shared peerings. The dev team saw the dev-api peering to shared-services. The M&A integration team dissolved before anyone reviewed what they left behind.
The GDPR violation crossed regions. The PCI violation crossed accounts. The M&A ghost crossed both. No single AWS Console view, no single team, and no single account-level audit could have found any of these. They only become visible when you map the entire network — all accounts, all regions — in one graph.
Watch the full demo
The video below walks through the live scan, the topology graph, and each finding — including how Netway distinguishes planned architecture from policy violations.
How Netway finds these
Netway deploys as a lightweight Lambda into each AWS account — one CloudFormation command per account, same API key. No cross-account IAM trust, no management account access. Each Lambda scans its own account and posts findings to a unified dashboard.
One scan command triggers all accounts and all regions in parallel. The topology graph assembles every VPC, peering, Transit Gateway, and internet gateway across all accounts into a single view. Isolation rules evaluate reachability across account boundaries — so a two-hop path through a shared-services account is detected even though neither hop individually violates a rule.
The compliance report — timestamped, HMAC-signed — is one click from a PDF your QSA, DPO, and board can read directly.
Deploys in 5 minutes · No agents · No code changes · Works with existing AWS accounts