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.
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
How it works
Each daily scan follows these steps inside your account:
- At deploy time, enable VPC Flow Logs on your specified VPCs → S3 bucket in your region
- On each scan, collect VPC topology — VPCs, Transit Gateways, peerings, subnets, route tables, EC2 instances
- Evaluate isolation rules against the topology graph — check whether any network path exists between selected environment group pairs
- Run topology detectors — CIDR conflicts, orphaned VPCs, CDE internet exposure, missing TGW propagations
- Query flow logs from S3 using Athena (data never leaves your account)
- Map IP addresses to your AWS resources (EC2, RDS, SageMaker, NAT Gateways)
- Classify each flow by traffic type (S3, internet, cross-AZ, ML, etc.)
- Aggregate flows into compact summaries and ship them to the Netway service (raw logs stay in your account)
- 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.
- 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.
HIGHStep 1 — Register
Register to get your API key. You can do this from the homepage or via curl.
Get your AWS account ID
You'll need this so Netway can grant your account access to pull the Lambda package during deployment.
aws sts get-caller-identity --query Account --output text
Register via the homepage or curl
Submit your email and AWS account ID. Your API key is returned immediately.
curl -X POST https://api.basavytix.com/netway/v1/register \
-H 'Content-Type: application/json' \
-d '{"email": "you@company.com", "aws_account_id": "123456789012"}'
Save the api_key from the response — you'll need it for the deploy command and dashboard.
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.
netway-deploy.sh — see Multi-region deployment below.
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.
Get your personalised deploy command
curl https://api.basavytix.com/netway/v1/install \ -H 'x-api-key: YOUR_API_KEY'
This returns a deploy_command pre-filled with your API key and tier settings.
Run the deploy command
The recommended way is netway-deploy.sh — it handles the bootstrap bucket, runs CloudFormation, and saves your config for future commands:
./netway-deploy.sh deploy \ --api-key YOUR_API_KEY \ --regions YOUR_REGION
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_REGION with your AWS region (e.g. us-east-1, eu-west-1). To monitor specific VPCs instead of all, add --vpcs vpc-0abc1234,vpc-0def5678.
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
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.
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.
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:
Single region — invoke the Lambda directly
aws lambda invoke \ --function-name netway-analyzer \ --region YOUR_REGION \ /tmp/out.json && cat /tmp/out.json
A successful scan returns {"statusCode": 200}. Findings appear in your dashboard within a few minutes.
Multiple regions — use netway-deploy.sh
# Trigger scans across all deployed regions at once ./netway-deploy.sh scan # Wait for results and show findings summary per region ./netway-deploy.sh scan --wait
See Multi-region deployment below for setup.
Check the logs if something looks wrong
aws logs tail /aws/lambda/netway-analyzer --region YOUR_REGION --since 1h
Step 4 — View findings
Once a scan completes, findings appear in your dashboard and can also be fetched via the API.
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.
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.
env, Environment, Env). Supported values: production, staging, development, cde. Override manually from the Compliance tab.
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.
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.
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.
Download the script
curl -O https://netway-public-releases.s3.ap-south-1.amazonaws.com/netway-deploy.sh chmod +x netway-deploy.sh
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.
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
Check stack status
./netway-deploy.sh status
Update all regions to the latest version
./netway-deploy.sh update
Downloads the latest netway-deploy.yml and updates all stacks in parallel.
Remove from a region
./netway-deploy.sh delete --regions eu-west-1
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.
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").
Tier limits apply: Starter allows 1 account, Standard allows 3, Enterprise is unlimited.
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_REGION \ --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.
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.
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.
./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.
Create a Slack app with an Incoming Webhook
Go to api.slack.com/apps → Create New App → From scratch. Name it anything (e.g. "Netway") and pick your workspace.
Enable Incoming Webhooks and add to a channel
In the app settings sidebar, click Incoming Webhooks → toggle Activate Incoming Webhooks → Add New Webhook to Workspace. Choose the channel where you want scan reports (e.g. #infra-costs) and click Allow.
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.
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.../...."}'
Trigger a scan to test it
Run a manual scan to verify the webhook is working:
aws lambda invoke \ --function-name netway-analyzer \ --region YOUR_REGION \ /tmp/out.json
A Slack message with your scan results should appear in the channel within a few seconds of the scan completing.
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, delete the CloudFormation stack. This removes the Lambda, S3 buckets, VPC Flow Logs created by Netway, IAM role, Athena workgroup, and EventBridge rules.
Delete the stack
aws cloudformation delete-stack --stack-name netway-v1 --region YOUR_REGION
Wait for deletion to complete (~3 min)
aws cloudformation wait stack-delete-complete --stack-name netway-v1 --region YOUR_REGION
netway-bootstrap-<account>-<region>) is created outside the stack by the deploy script and must be deleted manually if you want to clean it up: aws s3 rb s3://netway-bootstrap-ACCOUNT-REGION --force. Only VPC Flow Logs created by Netway are removed — any you had before are left untouched. If you deployed stacks in multiple regions or accounts, delete each stack separately.