DOCUMENTATION

Netway — Cloud Network Intelligence

Everything you need to deploy Netway, configure it, and interpret your findings.

What is Netway?

Netway is a lightweight AWS Lambda that runs inside your own AWS account. On every daily scan it does two things: maps your VPC topology (VPCs, Transit Gateways, peerings, internet gateways, NAT gateways, subnets, compute instances) and analyses VPC Flow Logs for network cost waste. Results are sent to the Netway service where detectors run server-side.

Netway gives you three capabilities from a single deployment:
Network Topology — interactive graph of your entire AWS network across all accounts and regions.
Compliance — isolation rule enforcement with 365-day history and one-click PDF evidence report for PCI-DSS and SOC2 audits.
Cost — detection of avoidable network spend (S3 via NAT, cross-AZ traffic, and more) with dollar amounts and exact fix commands.

Your raw VPC Flow Log data and network traffic never leave your AWS account — only aggregated topology metadata and traffic summaries are transmitted.

Netway is also available on the AWS Marketplace — subscribe through your AWS account for consolidated billing and simplified procurement.

Key facts

• Deploys in 3–5 minutes via a single CloudFormation command — works in any AWS region
• You choose which VPCs to monitor — no surprises, no implicit permissions creep
• Runs on a daily schedule and on new resource creation
• Costs ~$0.02 per scan in Athena + Lambda fees
• Read-only access to your EC2, RDS, and networking resources — Netway never modifies your existing infrastructure; the only write access granted is to the S3 bucket and Athena workgroup the stack creates for itself (full IAM policy)
• Raw network data never leaves your AWS account
• Three capabilities in one deploy: topology graph, compliance evidence, cost optimisation
• 14-day free trial, no credit card required — full access from day one

How it works

Each daily scan follows these steps inside your account:

  1. At deploy time, enable VPC Flow Logs on your specified VPCs → S3 bucket in your region
  2. On each scan, collect VPC topology — VPCs, Transit Gateways, peerings, subnets, route tables, EC2 instances
  3. Evaluate isolation rules against the topology graph — check whether any network path exists between selected environment group pairs
  4. Run topology detectors — CIDR conflicts, orphaned VPCs, CDE internet exposure, missing TGW propagations
  5. Query flow logs from S3 using Athena (data never leaves your account)
  6. Map IP addresses to your AWS resources (EC2, RDS, SageMaker, NAT Gateways)
  7. Classify each flow by traffic type (S3, internet, cross-AZ, ML, etc.)
  8. Aggregate flows into compact summaries and ship them to the Netway service (raw logs stay in your account)
  9. Topology detectors evaluate isolation rules, check for CIDR conflicts, CDE exposure, and other compliance issues. Cost detectors identify wasteful traffic patterns and estimate monthly savings.
  10. Findings appear in your Netway dashboard — topology graph, compliance status, and cost findings with one-command fixes

What it detects

Topology & Compliance

Netway evaluates your network topology for compliance and security issues on every scan:

  • Isolation rule violations — production↔staging, CDE↔internet, and any custom rule you define
  • CDE internet exposure — VPC tagged as cardholder data environment with a direct internet gateway
  • CIDR conflicts — overlapping CIDR blocks across VPCs that will cause routing failures
  • Orphaned VPCs — VPCs with no peering, TGW attachment, or internet gateway
  • Missing TGW route propagation — Transit Gateway attachments with incomplete route tables
  • Environment group mismatches — resources tagged inconsistently within the same VPC

Network Cost

Netway detects avoidable AWS network spend from VPC flow logs:

📡 Internet Egress

Large outbound flows to the internet. Identifies top spenders.

MED

🤖 ML Checkpoint via NAT

GPU jobs writing checkpoints to S3 through NAT. Free endpoint fixes this.

HIGH

🌍 Cross-Region S3

Reading S3 data from a different region. Replication saves $0.09/GB.

MED

⚡ ML Gradient Sync Cross-AZ

Distributed training nodes in different AZs syncing gradients.

HIGH

🪣 S3 via NAT Gateway

S3 traffic routed through NAT. A free S3 Gateway Endpoint eliminates this.

HIGH

🗄️ Cross-AZ RDS

App servers querying RDS in a different AZ. $0.01/GB each way.

MED

🌐 AWS API via NAT

Calls to AWS APIs (STS, CloudWatch) through NAT. Interface endpoints fix this.

HIGH

🔄 NAT in Wrong AZ

Instances using a NAT Gateway in a different AZ, doubling transfer costs.

HIGH

Step 1 — Register

Create an account at app.basavytix.com to get your API key.

1

Sign up

Go to basavytix.com/netway, click Get started, enter your email and choose a password. You'll receive a confirmation email — click the link to activate your account.

2

Copy your API key

Sign in to the dashboard, go to Settings → Account, and copy your API key. You'll use this key in the deploy command in the next step.

Step 2 — Install

Netway deploys into your AWS account via a single CloudFormation command. Deploy it in the same region as the VPCs you want to scan — Netway creates its own S3 bucket and Athena workgroup there, and enables VPC Flow Logs on exactly the VPCs you specify.

Region note: Deploy the stack in the same AWS region as your VPCs. Netway scans the region it is deployed in. For multiple regions, use netway-deploy.sh — see Multi-region deployment below.
1

Find the VPC IDs you want to monitor

aws ec2 describe-vpcs \
  --query 'Vpcs[*].{Id:VpcId,Name:Tags[?Key==`Name`].Value|[0],CIDR:CidrBlock}' \
  --output table \
  --region YOUR_REGION

Note the VPC IDs you want Netway to monitor (e.g. vpc-0abc1234,vpc-0def5678). Use ALL to monitor every VPC in the region.

2

Download and run the deploy script

netway-deploy.sh handles the bootstrap bucket, runs CloudFormation, and saves your config for future commands:

curl -O https://netway-public-releases.s3.ap-south-1.amazonaws.com/netway-deploy.sh
chmod +x netway-deploy.sh
./netway-deploy.sh deploy \
  --api-key YOUR_API_KEY \
  --regions YOUR_REGIONS

CloudFormation creates the Lambda, IAM role, S3 bucket, Athena workgroup, and EventBridge schedule — and enables VPC Flow Logs on the VPCs you specify. Replace YOUR_REGIONS with one or more AWS regions, comma-separated (e.g. us-east-1,ap-south-1,eu-west-1). By default all VPCs are monitored. To limit to specific VPCs, add --vpcs vpc-0abc1234,vpc-0def5678.

3

Wait for the stack to complete (~3–5 min)

The script waits and prints a per-region status on completion. You can also check progress with:

./netway-deploy.sh status
4

Wait 10–15 minutes for first flow logs

VPC Flow Logs are delivered to S3 in 60-second batches, then S3 delivery adds ~10 minutes. After the stack is created, wait 10–15 minutes before triggering your first scan so there is data to analyse.

Flow log behaviour: Netway only enables flow logs on VPCs that don't already have S3 flow logs. Existing flow logs are never modified or deleted. On stack deletion, only the flow logs created by Netway are removed — any you had before are left untouched. Set VpcIds to an empty string to skip automatic flow log setup entirely and configure them yourself.

IAM permissions

The CloudFormation stack creates one IAM role for the scanning Lambda (netway-analyzer-<region>), scoped to the minimum permissions the scan needs. Netway follows the principle of least privilege: every action below exists because a specific scan step needs it, and nothing broader is granted. The role can only be assumed by the Lambda service itself (lambda.amazonaws.com) — there is no cross-account trust relationship, and the role is not assumable from outside your own account.

What the role can do

Purpose Actions Resource scope
Read VPC Flow Logs, write to its own bucket s3:GetObject, s3:PutObject, s3:ListBucket, s3:GetBucketAcl, s3:GetBucketLocation Only the S3 bucket the stack creates (or the existing bucket you name, if you opt out of bucket creation) — never any other bucket in your account
Query flow logs with Athena athena:StartQueryExecution, athena:GetQueryExecution, athena:GetQueryResults, athena:StopQueryExecution, glue:GetDatabase, glue:GetTable, glue:CreateTable, glue:CreateDatabase, glue:BatchCreatePartition, glue:GetPartition(s) Account-wide (Athena/Glue actions don't support resource-level ARN scoping for these operations) — used only against the Glue database/Athena workgroup the stack creates
Map topology — read-only describe calls ec2:Describe* (VPCs, subnets, NAT/internet/transit gateways, route tables, peering, EIPs), ec2:SearchTransitGatewayRoutes, rds:Describe*, elasticloadbalancing:DescribeLoadBalancers, lambda:ListFunctions, sagemaker:List*, elasticache:Describe*, fsx:DescribeFileSystems Account-wide, read-only — none of these actions can create, modify, or delete any resource
Identify the account being scanned sts:GetCallerIdentity Account-wide (read-only, no resource scoping exists for this action)
Lambda's own execution logs logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents Scoped to this Lambda's own log group ARN only
AWS Marketplace billing (only if subscribed via Marketplace) aws-marketplace:MeterUsage Account-wide (no resource scoping exists for this action); unused for direct (non-Marketplace) customers

Netway never requests any :Create, :Modify, :Delete, or :Put action against your existing EC2, RDS, networking, or compute resources. The only write actions in the entire policy (s3:PutObject, the Glue/Athena create-table/create-database calls, and the log-group writes) target resources the stack itself creates and owns — never resources you already had.

Full policy document: The exact, current IAM policy is defined in the NetwayRole resource of the published CloudFormation template — netway-deploy.yml. Review it directly before deploying; this page summarizes it but the template is the source of truth.

Step 3 — Run a scan

Netway scans automatically on a daily schedule and whenever a new EC2 instance, VPC, or NAT Gateway is created. Each regional stack runs its own Lambda — in a multi-region setup, each region scans independently and posts results to the same dashboard. To trigger a scan manually:

1

Trigger a scan

# Fire and forget (single or multiple regions)
./netway-deploy.sh scan

# Wait for completion and show per-region status
./netway-deploy.sh scan --wait

Works for any number of regions — the script reads your saved region list and invokes each Lambda in parallel. A successful scan returns {"statusCode": 200} per region. Findings appear in your dashboard within a few minutes.

2

Check the logs if something looks wrong

aws logs tail /aws/lambda/netway-analyzer --region YOUR_REGION --since 1h
First scan tip: Flow logs take 10–15 minutes to land in S3 after traffic occurs. If you just enabled flow logs, wait a few minutes before triggering a scan.
Known limitation — cross-region TGW: Each Lambda resolves Transit Gateway reachability within its own region only. If your TGW spans multiple regions, cross-region TGW routes may be incomplete in the topology graph. Single-region TGW and inter-region VPC peering are not affected.

Step 4 — View findings

Once a scan completes, findings appear in your dashboard and can also be fetched via the API.

1

Open the dashboard

The dashboard has three tabs — Topology (network graph and compliance), Cost (findings and savings), and Settings. Enter your API key to view all tabs.

Go to app.basavytix.com/netway/dashboard and enter your API key.

2

Or fetch via the API

# Cost findings
curl https://api.basavytix.com/netway/v1/cost/dashboard \
  -H 'x-api-key: YOUR_API_KEY'

# Topology graph
curl https://api.basavytix.com/netway/v1/topology/graph \
  -H 'x-api-key: YOUR_API_KEY'

Topology Graph

After your first scan the Topology tab in the dashboard shows an interactive force-directed graph of your entire AWS network. VPCs, Transit Gateways, Internet Gateways, and NAT Gateways are shown as AWS Architecture Icons.

The graph shows reachability between VPCs visually. Click any VPC node to open the sidebar — showing CIDR blocks, environment group, finding count, and compute instances within each subnet. Switch to the Matrix panel to see a full reachability grid across all VPC pairs. Use the pill switcher at the top to navigate between Graph, Matrix, CIDR Map, and History panels.

Environment groups: Netway auto-assigns environment groups from VPC tags on every scan. Tag keys checked (in order): environment, env, stage, tier, netway:env. PCI/CDE tags (pci, pci-scope, data-classification) are checked first and take priority. Known values and their aliases:
  • production — prod, prd, production
  • staging — staging, stage, stg, uat, pre-prod, preprod
  • development — dev, development, develop
  • dmz — dmz
  • cde — pci=true/yes/1/in-scope, data-classification=cde
Any other tag value (e.g. eu-data, shared-services) is preserved verbatim as a custom group. Netway also falls back to the VPC Name tag if no env tag is set. Manual overrides from the Compliance tab are preserved across re-scans.

Isolation Rules

Isolation rules define network boundaries that must be maintained. Netway evaluates each rule on every scan and records a pass/fail result with a timestamp — building an immutable 365-day audit log.

Create rules from the Compliance tab in the dashboard: choose two environment groups (e.g. production and staging) and Netway will alert you immediately if a route between them is ever detected.

Violation alerts: When an isolation rule fails, a Slack alert fires immediately with the rule name, the VPC pair, and the edge that caused the breach. The violation is recorded in the audit log regardless of whether Slack is configured.

Compliance Report

The compliance evidence report is generated on demand from the Compliance tab. Choose a date range and click Download HTML or Download PDF. The report covers your isolation rule history, topology findings, network diagram, traffic flows, and change log for the selected period.

Every report is signed with HMAC-SHA256 using your customer API key — the signature is embedded in the report header and can be independently verified. Hand the PDF directly to your QSA as PCI-DSS or SOC2 evidence.

All report formats — HTML and HMAC-signed PDF — are included with your Netway subscription.

Multi-region deployment

For multiple regions, use netway-deploy.sh — a single script that deploys, updates, scans, and removes Netway across all your regions in parallel. Each region gets its own independent Lambda, S3 bucket, and Athena workgroup, all reporting to the same dashboard.

1

Download the script

curl -O https://netway-public-releases.s3.ap-south-1.amazonaws.com/netway-deploy.sh
chmod +x netway-deploy.sh
2

Deploy to all regions at once

./netway-deploy.sh deploy \
  --api-key YOUR_API_KEY \
  --regions us-east-1,eu-west-1,ap-south-1

Deploys in parallel. Your region list is saved to ~/.netway/regions — subsequent commands read it automatically.

If a previous deployment left a stack in ROLLBACK_COMPLETE or DELETE_FAILED state, the script automatically deletes the stale stack and performs a clean deploy — no manual cleanup required.

3

Trigger a scan across all regions

# Fire and forget
./netway-deploy.sh scan

# Wait for results with per-region findings summary
./netway-deploy.sh scan --wait

The Lambda function name is resolved automatically from the CloudFormation stack outputs, so --stack-name is respected end-to-end — no hardcoded names.

4

Check stack status

./netway-deploy.sh status
5

Inspect stack outputs

# Human-readable table
./netway-deploy.sh outputs

# Machine-readable JSON (for scripting)
./netway-deploy.sh outputs --json

Shows all CloudFormation stack outputs per region — Lambda function name, S3 bucket, Athena workgroup, and IAM role ARN. Useful for verifying a deployment or wiring up external tooling.

6

Upgrade all regions to the latest version

./netway-deploy.sh upgrade

Downloads the latest netway-deploy.yml from S3 and updates all stacks in parallel.

7

Remove from a region

./netway-deploy.sh delete --regions eu-west-1
Requirements: AWS CLI configured with credentials, Bash 4+ (macOS ships Bash 3 — run brew install bash if needed). No other dependencies.

Multi-account setup

To monitor VPCs across multiple AWS accounts, deploy one Netway stack per account using the same API key. No cross-account IAM trust or management account access is required — each stack operates entirely within its own account.

1

Link the additional account in your dashboard

Before a second account can post findings, you must add it to your allow-list. Go to Dashboard → Settings → Account → AWS Accounts+ Link another AWS account. Enter the 12-digit AWS account ID and an optional label (e.g. "staging").

Your subscription includes support for multiple AWS accounts. Contact support@basavytix.com if you need to increase your account limit.

2

Deploy a stack in the additional account

Use netway-deploy.sh with a named AWS CLI profile for the target account:

# Deploy into account B using a named AWS CLI profile
./netway-deploy.sh deploy \
  --api-key YOUR_API_KEY \
  --regions YOUR_REGIONS \
  --profile staging-account

Each stack creates its own Lambda, S3 bucket, IAM role, and Athena workgroup — all scoped entirely within that account. Pass the same API key each time.

3

Trigger scans across all accounts

Use --profile to scan a specific account, or pass multiple profiles to scan all accounts in parallel:

# Scan a single account
./netway-deploy.sh scan --profile staging-account

# Scan multiple accounts in parallel
./netway-deploy.sh scan --profile prod-account --profile staging-account

After each scan completes, all accounts appear together in the same topology graph, labelled by AWS account ID.

4

View the combined topology

Open the Netway dashboard → Topology tab. VPCs from all accounts are shown in the same graph. Use the account filter dropdown above the graph to focus on a single account. VPC peering connections and Transit Gateway attachments that span account boundaries are shown as edges — including cross-account isolation breaches.

Allow-list enforcement: Only accounts you explicitly link in the dashboard can post findings. If a Lambda from an unlinked account tries to post, the request is rejected with a clear error. This ensures a leaked API key cannot be used by an unknown account to corrupt your data.
Cross-account isolation rules: Isolation rules evaluate reachability across all accounts posting to the same API key. If a production VPC (Account A) is peered to a staging VPC (Account B), Netway detects the reachable path and flags the isolation breach — even across account boundaries — provided both accounts have Netway deployed and linked.
Note: Each account's Lambda scans on its own daily schedule. If you want all accounts to scan at the same time, use ./netway-deploy.sh scan --profile <profile> as shown in Step 3. The AWS Accounts panel in Settings shows a Last scan timestamp per account so you can see if any account's data is stale.

Slack Notifications

Netway can post a rich summary of every scan directly to a Slack channel — showing the total monthly waste, quick wins, and top findings with severity and fix actions. Compliance violation alerts (isolation rule failures) are also sent to the same Slack channel immediately on detection — not as part of the scan summary, but as real-time alerts.

Configuration takes about 2 minutes. You only need to create a Slack Incoming Webhook URL (no bot token, no app store listing required) and save it to your Netway account.

Privacy: The webhook URL is stored encrypted server-side and is only used to POST scan results. No Slack data is ever read by Netway.
1

Create a Slack app with an Incoming Webhook

Go to api.slack.com/appsCreate New AppFrom scratch. Name it anything (e.g. "Netway") and pick your workspace.

2

Enable Incoming Webhooks and add to a channel

In the app settings sidebar, click Incoming Webhooks → toggle Activate Incoming WebhooksAdd New Webhook to Workspace. Choose the channel where you want scan reports (e.g. #infra-costs) and click Allow.

3

Copy the Webhook URL

After authorising the channel, Slack shows a webhook URL like:

https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

Copy this URL — you'll use it in the next step.

4

Save the webhook URL to your Netway account

Option A — Dashboard: Go to your Netway dashboard → click the ⚙ Settings tab → select Notifications in the left sidebar → click Add Slack → paste your webhook URL in the input box → click Save.

Option B — API / curl:

curl -X PATCH https://api.basavytix.com/netway/v1/config \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"slack_webhook": "https://hooks.slack.com/services/T.../B.../...."}'
5

Trigger a scan to test it

Run a manual scan to verify the webhook is working:

./netway-deploy.sh scan --wait

A Slack message with your scan results should appear in the channel within a few seconds of the scan completing.

6

Remove the webhook (optional)

To stop Slack notifications, clear the webhook in the dashboard panel or via the API:

curl -X PATCH https://api.basavytix.com/netway/v1/config \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"slack_webhook": ""}'

Uninstall

To remove Netway from your AWS account completely, use netway-deploy.sh delete. This deletes the CloudFormation stack, which removes the Lambda, IAM role, S3 buckets, VPC Flow Logs created by Netway, Athena workgroup, and EventBridge rules.

1

Delete from one region

./netway-deploy.sh delete --regions YOUR_REGIONS
2

Delete from multiple regions at once

./netway-deploy.sh delete --regions us-east-1,eu-west-1,ap-south-1

Deletions run in parallel. The script waits for each stack to reach DELETE_COMPLETE before returning.

Note: Only VPC Flow Logs created by Netway are removed — any you had before are left untouched. The bootstrap bucket (netway-bootstrap-<account>-<region>) is created outside the stack and must be deleted manually if you want to clean it up: aws s3 rb s3://netway-bootstrap-ACCOUNT-REGION --force. For multi-account setups, run the delete command once per account using --profile.