Isolation rules are the core of Netway's compliance feature. You define which environment groups must never connect — production must not route to staging, CDE must not route to development — and on every scan Netway checks whether a routing-plane path between those groups exists. If one is found, the rule fails and you get an alert.
This post covers what isolation rules are, how to set them up in the dashboard, what the engine actually checks under the hood, the most useful configurations for different environments, and the things isolation rules explicitly do not cover.
Concepts: Environment Groups and Rules
Isolation rules operate on environment groups — logical labels you assign to your VPCs. A group is just a string: production, staging, development, cde, dmz, or any label that makes sense for your environment.
Every VPC you have scanned appears in the dashboard's Environment Groups panel. By default, VPCs are unassigned. You assign each one to a group, and Netway uses those assignments to evaluate your rules.
An isolation rule has three fields:
- Name — a human-readable label, up to 100 characters. Shown in the dashboard, alerts, and compliance reports. Example: Production ↔ Staging.
- Group A — the first environment group. Example:
production. - Group B — the second environment group. Example:
staging.
The rule type is isolated — meaning these two groups must have no routing-plane path between them. This is the only rule type currently supported.
Setting Up Isolation Rules: Step by Step
Run a topology scan
Your VPCs, peering connections, TGW attachments, and route tables must be scanned before you can assign groups. Trigger a scan from the dashboard or via the deployed Lambda.
Assign VPCs to environment groups
Go to Compliance → Environment Groups. Each discovered VPC is listed with its ID, CIDR, region, and current group. Click a VPC and enter the group name: production, staging, development, cde, or any label. Netway may suggest group names based on existing tags — for example, if a VPC has a tag env=prod, it will suggest production.
Create an isolation rule
Go to Compliance → Isolation Rules and click + Add Rule. Fill in the name, Group A, and Group B. Group A and Group B must be different. You cannot create two rules with the same group pair.
Run the next scan
Isolation rules are evaluated on every topology scan. After the next scan completes, the rule shows PASS or FAIL in the dashboard. For a newly created rule with no prior results, the status shows as never evaluated until the first scan runs.
Review results and configure alerts
Each rule shows its current status, a pass streak (consecutive scans passing), last evaluated time, and last violation timestamp. Click a failing rule to see the exact network path: which VPCs are connected, via which peering or TGW attachment, with the full hop-by-hop trace.
Here's what the form looks like in the Compliance tab:
| Rule | Groups | Status | Streak | Last Evaluated |
|---|---|---|---|---|
| Production ↔ Staging | production ↔ staging | PASS | 14 days | 2 hours ago |
| CDE ↔ Development | cde ↔ development | FAIL | — | 2 hours ago |
| Production ↔ Dev | production ↔ development | NOT EVALUATED | — | — |
What the Engine Actually Checks
Understanding what Netway checks under the hood helps you write rules that are meaningful and interpret results correctly.
Graph traversal, not traffic analysis
Netway builds a topology graph of all your scanned infrastructure: VPCs as nodes, and peering connections, TGW attachments, and TGW routes as edges. When evaluating an isolation rule, it runs a breadth-first search (BFS) from every VPC in Group A to every VPC in Group B.
If BFS finds a path — any sequence of edges connecting a Group A VPC to a Group B VPC — the rule fails. The path is recorded in full: VPC IDs, edge types, and edge IDs. If no path exists, the rule passes.
Which edge types are traversed
| Edge type | Traversed? | Reason |
|---|---|---|
| VPC peering | ✅ Yes | Direct routing-plane path between two VPCs |
| TGW attachment | ✅ Yes | Connects a VPC to the Transit Gateway fabric |
| TGW route | ✅ Yes | Represents active routing through TGW |
| Internet Gateway | ❌ No | Connects to public internet, not to another VPC |
| NAT Gateway | ❌ No | Outbound internet only — not a private path between VPCs |
The key design choice: IGW and NAT edges are not traversed because they represent internet connectivity, not private connectivity between your environments. Two VPCs that both have internet access via their own IGWs are not considered connected by Netway.
What a violation looks like
When a rule fails, Netway records the exact path. In the dashboard, clicking the failing rule shows:
Rule: CDE ↔ Development [FAIL]
Path found:
vpc-cde-123 (cde)
→ pcx-0abc456 [peering]
vpc-shared-services-789 (shared-services)
→ tgw-attach-0def012 [tgw_attachment]
vpc-dev-345 (development)
Edges on path: pcx-0abc456, tgw-attach-0def012
Edge types: peering, tgw_attachmentThis tells you exactly which connections form the path. It is not always a direct connection — Netway finds indirect paths too. In the example above, the CDE VPC is peered to a shared-services VPC which is attached to the TGW that also connects the development VPC.
Alert on new connections
Beyond the per-scan rule evaluation, Netway also runs a change detection pass comparing each new scan to the previous one. If a new peering connection or TGW attachment appears between two VPCs whose groups are covered by an isolation rule, you get an alert immediately — before the full scan completes — labeled New connection added between [group_a] and [group_b].
This means you are notified of structural changes that may affect isolation even in the window between scans.
Common Use Cases
Cardholder Data Environment (CDE) isolation
The most critical use case. Define a cde group for your VPCs that process, store, or transmit cardholder data. Create rules against every other environment group. Any accidental peering, TGW attachment, or route change that creates a path to the CDE will immediately fail.
Preventing staging-to-production crosstalk
A common infrastructure mistake: staging VPCs accidentally gain connectivity to production through new TGW attachments or shared-services VPC peerings. A production ↔ staging rule catches this the moment it happens, before any traffic flows.
Keeping development fully isolated
Development VPCs often have looser security configurations — overly permissive security groups, test credentials, experimental code. Ensure they can never reach production or the CDE regardless of how infra is provisioned.
Continuous isolation evidence for auditors
SOC 2 CC6.1 and CC6.6 require logical access controls between environments. Isolation rules provide daily PASS/FAIL history that serves as continuous routing-plane evidence. The compliance report covers any date range and can be handed directly to your auditor.
Tenant-to-tenant isolation
If you run separate VPCs per customer or business unit and need to prove they cannot reach each other, assign each to a distinct group (e.g. tenant-a, tenant-b) and create a rule between them. Useful in SaaS environments with strict data residency requirements.
DMZ must not connect to internal production
Public-facing services in a DMZ VPC should connect to the internet, not directly to your core production environment. A dmz ↔ production rule ensures any change that creates that path is caught immediately.
What to Configure First
If you're starting with isolation rules for the first time, the recommended order:
- Assign all VPCs to groups. Don't leave any as
unassignedif they are in scope — an unassigned VPC is excluded from all rule evaluations. - Create your highest-risk rule first:
production ↔ stagingorcde ↔ development. - Run a scan and review the result. If the rule fails immediately, investigate the path Netway found — it may be a real gap, or it may reveal that a shared-services VPC needs its own group assignment.
- Add remaining rules once the first one is understood and passing.
shared-services) and check whether it creates indirect paths. A rule between production and staging will fail if both are connected to the shared-services VPC and that VPC is in a third group — because Netway finds the indirect path through it.
The Compliance Dashboard View
The Compliance tab in the Netway dashboard has three panels relevant to isolation rules:
Isolation Rules panel
Shows all active rules with: current status (PASS / FAIL / never evaluated), pass streak (consecutive scans passing), last evaluated timestamp, and last violation timestamp. Clicking a failing rule opens a modal showing the violation path in full detail, plus a 14-scan history for that rule.
Environment Groups panel
Lists all scanned VPCs grouped by their assigned environment group. Unassigned VPCs are flagged. Clicking a VPC allows you to reassign its group without re-scanning.
Topology Findings panel
Lists all findings from the most recent scan, including isolation-related findings: env_isolation_breach (a rule is currently violated), new_cross_env_connection (a new connection between two groups was added in this scan). These are severity-rated: isolation breaches are critical, new cross-env connections are high.
The Compliance Report
On Standard and Enterprise plans, you can download a compliance report from the Audit Report panel. Select a date range and download as HTML or PDF (PDF on Enterprise). The report includes:
- Per-rule isolation verdicts with daily PASS/FAIL history for the full period
- For any FAIL day: the exact path traced, with VPC IDs and edge IDs
- Auto-generated network diagram from the latest topology snapshot
- Topology change log (new VPCs, peerings, TGW attachments detected in the period)
- Anomaly and alert log
- Scope boundary statement noting which PCI/SOC2 requirements are covered
The report is HMAC-SHA256 signed. Your auditor can verify independently that it has not been modified after generation.
Limitations
Isolation rules are a powerful tool for routing-plane verification, but there are things they explicitly do not check. Understanding these limits prevents false confidence.
A rule passes if no routing-plane path exists between the groups. It does not verify that security groups or NACLs would block traffic even if a path existed. Conversely, a rule fails if a path exists — even if security groups would deny all traffic on that path. The routing plane is the authoritative check for isolation, but defense-in-depth (SGs, NACLs) is complementary and is not verified here.
Rules operate at the VPC-to-VPC routing level. If you have a CDE subnet and a non-CDE subnet inside the same VPC, isolation rules will not distinguish between them. If both groups are in the same VPC, they will appear connected. For intra-VPC isolation, NACLs and security groups at the subnet level are the right control — not isolation rules.
Isolation rules evaluate the topology Netway has discovered. VPCs in accounts or regions not included in your scan are not part of the graph. If you have cross-account peerings to VPCs Netway has not scanned, those connections will not appear in the graph and cannot be evaluated. For comprehensive coverage, ensure all relevant accounts and regions are scanned.
VPCs that have not been assigned an environment group are listed as unassigned. They participate in the topology graph — Netway can traverse through them — but they do not belong to any group in a rule. A path that goes through an unassigned VPC may be traversed, but the unassigned VPC will not itself trigger a rule violation unless it routes into a named group.
You cannot create a rule where Group A and Group B are the same string. A rule like production ↔ production is rejected at creation time. Rules are always between two different groups.
You can only have one active rule per group pair. If a rule for production ↔ staging already exists, attempting to create another one returns a 409 error. Delete the existing rule first if you want to rename it or modify it.
Rules are evaluated once per scan. On the Standard plan, scans run daily. On Enterprise, every 6 hours. Between scans, the topology may change — a peering could be created and deleted — and this would not be captured if it happened entirely between scan windows. The change detection alert for new cross-environment connections helps narrow this window but does not eliminate it.
What Isolation Rules Replace (and Don't Replace)
| Approach | What isolation rules add |
|---|---|
| Annual pen test | Daily (or 6-hourly) routing-plane verification vs. annual point-in-time testing. Catches changes introduced between pen tests. |
| Static network diagram | Automatically updated on every scan. No manual diagram maintenance required. |
| AWS Config rules | Cross-VPC path analysis — AWS Config checks individual resource config, not whether a routing path exists between two VPCs via peering + TGW combinations. |
| Security group audits | Routing-plane evidence (no path exists) — complementary to SG audits, not a replacement. SGs are host-level; isolation rules are network-level. |
| AWS Network Reachability Analyzer | Continuous automated runs on every scan vs. manual one-shot checks. Persistent history and audit trail vs. ephemeral results. |
Related Articles
→ PCI DSS 1.3 Network Segmentation Evidence [What QSAs Actually Ask For] → AWS TGW Route Tables: Why VPC Isolation Still Fails [Peering Bypass] → 4 Hidden AWS Network Risks None Visible in the Console → AWS VPC Topology Mapping: What the Console HidesFrequently Asked Questions
What does an isolation rule in Netway actually check?
It performs a BFS graph traversal across all scanned VPCs, peering connections, and TGW attachments to find whether any routing-plane path connects a VPC in Group A to a VPC in Group B. If a path exists, the rule fails — regardless of whether security groups would block traffic on that path.
Will a rule fail if both groups connect through a shared-services VPC?
Yes. Netway finds indirect paths, not just direct connections. If production connects to shared-services via peering, and staging connects to shared-services via a TGW attachment, a production ↔ staging rule will fail — the path goes production → shared-services → staging.
What are the main limitations of isolation rules?
They check routing-plane connectivity, not traffic blocking. They operate at the VPC level, not subnet or resource level. They only cover VPCs included in your scan. Unassigned VPCs are excluded from group membership. Rules evaluate at scan cadence — daily on Standard, every 6 hours on Enterprise.