AWS VPC Visualization: 5 Ways to See Your Network Topology

When your AWS environment is small — one or two VPCs, one account, one region — the console is enough. You can see everything by clicking around. But somewhere around five to seven VPCs, clicking around stops working. The console shows you individual VPCs. It does not show you the map.

This post covers five approaches to AWS VPC visualization: what each one actually shows, where it breaks down, and when to use it.

Why VPC Visualization Matters

The network topology determines what can talk to what. It determines whether your production environment is actually isolated from staging, whether S3 traffic is taking a free VPC endpoint or an expensive NAT path, and whether there are VPC peerings from two years ago that nobody remembers but are still live.

None of that is visible in the standard AWS console. The VPC list shows you VPCs. The TGW console shows you TGW attachments. The peering console shows you peerings. There is no view that puts them together into a network map.

Option 1: VPC Resource Map (AWS Console)

When to use it: Auditing the internal structure of a single VPC — confirming which subnets are public vs private, verifying gateway placement. Not useful for understanding how multiple VPCs connect.

Option 2: AWS Network Manager

When to use it: Getting a high-level view of your TGW-connected network. The Route Analyzer is useful for tracing a specific path. The gap is VPC peerings — they are invisible here, and they are the source of most isolation problems.

Option 3: VPC Reachability Analyzer

When to use it: Answering a specific question — "can this EC2 instance in subnet A reach this RDS in subnet B?" Not useful for getting a picture of the overall network. Costs $0.10 per analysis, which adds up if you're running audits at scale.

Option 4: AWS CLI + Custom Scripting

# List all VPCs in an account
aws ec2 describe-vpcs --query 'Vpcs[*].[VpcId,CidrBlock,Tags]'

# List all peering connections
aws ec2 describe-vpc-peering-connections

# List TGW attachments
aws ec2 describe-transit-gateway-attachments

# List route tables
aws ec2 describe-route-tables

The data is all there. The challenge is joining it. Peerings reference VPC IDs and account IDs, TGW attachments reference VPC IDs and TGW IDs, and route tables reference both. Across multiple accounts, you need to assume a cross-account IAM role in each one and repeat. A usable cross-account topology script is several hundred lines.

When to use it: One-time audit, or as the data source for a custom visualization. Tools like Graphviz, D3.js, or draw.io can render the CLI output into a diagram. This approach requires engineering time to build and maintain.

Option 5: Dedicated Network Visibility Tool

Which Approach Is Right for You?

If you have one account and fewer than five VPCs, the VPC console Resource Map and Network Manager together give you enough. If you have multiple accounts, VPC peerings across environment boundaries, or need to track topology changes over time, you need either a custom CLI script or a dedicated tool — the built-in options won't give you a complete picture.

The specific gap that catches most teams is VPC peerings. They are the most common source of unintended connectivity between environments, they are invisible in Network Manager, and they don't appear in TGW route table audits. Whatever visualization approach you use, make sure it includes peerings.

---

Getting Started with Netway