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.

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:

  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

Register to get your API key. You can do this from the homepage or via curl.

1

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
2

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.

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

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.

3

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.

4

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
5

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

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.

2

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.

3

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 infers environment groups from VPC tags (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.

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.

Tier note: HTML report available on Standard and Enterprise tiers. PDF export requires Enterprise tier.

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.

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
4

Check stack status

./netway-deploy.sh status
5

Update all regions to the latest version

./netway-deploy.sh update

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

6

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").

Tier limits apply: Starter allows 1 account, Standard allows 3, Enterprise is unlimited.

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_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.

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:

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.

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, delete the CloudFormation stack. This removes the Lambda, S3 buckets, VPC Flow Logs created by Netway, IAM role, Athena workgroup, and EventBridge rules.

1

Delete the stack

aws cloudformation delete-stack --stack-name netway-v1 --region YOUR_REGION
2

Wait for deletion to complete (~3 min)

aws cloudformation wait stack-delete-complete --stack-name netway-v1 --region YOUR_REGION
Note: The data S3 bucket (flow logs, Athena results) is deleted automatically as part of stack deletion. The bootstrap bucket (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.