How to Visualize AWS VPC Peering Connections — Tools and CLI Approach

Open the AWS console, go to VPC, and click "Peering connections." What you get is a table. Each row has a peering connection ID, two VPC IDs, two CIDR blocks, and a status. If you have ten peering connections, you have ten rows. If you have forty, you have forty rows.

There is no graph. There is no diagram. There is no way to look at the console and immediately understand whether your VPCs form a hub-and-spoke topology, a full mesh, or something that has grown organically and no longer resembles any intentional design. The list tells you which connections exist; it does not tell you what they mean together.

This post covers how to build a VPC topology diagram yourself using the CLI and boto3, what AWS-native tools exist and what they're missing, and what any static visualization approach leaves out.

Building an Adjacency List with the AWS CLI

The raw data for a VPC topology graph lives in three API calls. Chain them together to build a complete picture of how your VPCs are connected.

Step 1 — Get all VPCs and their names:

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

Step 2 — Get all active peering connections:

aws ec2 describe-vpc-peering-connections \
  --filters "Name=status-code,Values=active" \
  --query 'VpcPeeringConnections[*].{PeeringId:VpcPeeringConnectionId,Requester:RequesterVpcInfo.VpcId,Accepter:AccepterVpcInfo.VpcId,RequesterCIDR:RequesterVpcInfo.CidrBlock,AccepterCIDR:AccepterVpcInfo.CidrBlock}' \
  --output table

Step 3 — Get Transit Gateway attachments to understand TGW-connected VPCs:

aws ec2 describe-transit-gateway-attachments \
  --filters "Name=resource-type,Values=vpc" "Name=state,Values=available" \
  --query 'TransitGatewayAttachments[*].{TGW:TransitGatewayId,VPC:ResourceId,AttachmentId:TransitGatewayAttachmentId}' \
  --output table

With these three outputs, you can build a complete adjacency list: which VPCs are directly connected (via peering), and which VPCs share a Transit Gateway (and therefore have potential connectivity depending on TGW route tables).

Generating a DOT Graph with boto3

Once you have the raw data, converting it to a Graphviz DOT file is straightforward. The following Python script requires only boto3 and produces a .dot file you can render with Graphviz or paste into an online DOT viewer:

import boto3

ec2 = boto3.client('ec2')

# Collect VPCs
vpcs = {}
for vpc in ec2.describe_vpcs()['Vpcs']:
    name = next((t['Value'] for t in vpc.get('Tags', []) if t['Key'] == 'Name'), vpc['VpcId'])
    env = next((t['Value'] for t in vpc.get('Tags', []) if t['Key'] == 'Environment'), 'unknown')
    vpcs[vpc['VpcId']] = {'name': name, 'env': env, 'cidr': vpc['CidrBlock']}

# Collect active peering connections
peerings = []
paginator = ec2.get_paginator('describe_vpc_peering_connections')
for page in paginator.paginate(Filters=[{'Name': 'status-code', 'Values': ['active']}]):
    for pcx in page['VpcPeeringConnections']:
        peerings.append((
            pcx['RequesterVpcInfo']['VpcId'],
            pcx['AccepterVpcInfo']['VpcId'],
            pcx['VpcPeeringConnectionId']
        ))

# Emit DOT format
lines = ['digraph vpc_topology {', '  rankdir=LR;', '  node [shape=box style=filled fillcolor="#1e2a38" fontcolor="white" fontname="Helvetica"];']

for vpc_id, info in vpcs.items():
    label = f"{info['name']}\\n{info['cidr']}\\nenv:{info['env']}"
    lines.append(f'  "{vpc_id}" [label="{label}"];')

for req, acc, pcx_id in peerings:
    lines.append(f'  "{req}" -> "{acc}" [label="{pcx_id}" dir=both color="#58a6ff"];')

lines.append('}')
print('\n'.join(lines))

Run it and pipe to Graphviz:

python3 vpc_topology.py | dot -Tsvg -o vpc-topology.svg
# or for PNG:
python3 vpc_topology.py | dot -Tpng -o vpc-topology.png

The result is an SVG or PNG showing every VPC as a node and every peering connection as an edge, labeled with the peering connection ID. For environments with fewer than 20 VPCs, this produces a readable diagram in seconds.

AWS Network Manager: What It Can and Can't Do

AWS provides a built-in topology tool called Network Manager. It offers a global network view with a geographic map and a topology diagram. Before concluding it solves the problem, understand its constraints:

Capability	Network Manager
Requires Transit Gateway	Yes — Network Manager is a TGW feature. VPC-only environments with peering but no TGW are not supported.
Shows VPC peering connections	Partially — only peerings that are associated with a registered TGW network. Standalone VPC peerings are not shown.
Shows security context	No — the diagram shows connectivity but not whether connections are intentional or violate isolation rules.
Tracks changes over time	No — you see the current state. There is no built-in diff or change history.
Cost	No additional charge for Network Manager itself, but requires a registered TGW.

Network Manager is useful for understanding large TGW-centric topologies at a glance, especially across regions. For environments that rely on VPC peering without a TGW, or for teams that need security context alongside the topology, it falls short.

Third-Party Visualization Tools

Several tools produce AWS network diagrams, each with different trade-offs:

What Static Visualization Misses

All of the approaches above — the boto3 DOT script, Network Manager, Cloudcraft, Lucidchart — share the same fundamental gap: they show you what is connected but not whether those connections are correct.

A topology diagram showing 12 VPCs and 8 peering connections is accurate as a map. It does not tell you:

• Whether any of those peering connections violate an isolation rule you care about
• Whether a connection that appears on the diagram today appeared last week, or was added three days ago without a ticket
• Whether a connection that was supposed to be temporary has quietly persisted for four months
• Whether the diagram reflects the current state of the AWS API, or was generated from a snapshot taken before the last infrastructure change

What Netway Adds

Netway runs as a Lambda in your own account and generates a topology graph on every scan — pulling live data from the EC2 API, not from a snapshot or a registered resource set. A few things it does differently from a static visualization:

Environment grouping: VPCs are grouped by their Environment tag (or a custom tag you specify). The diagram shows which VPCs belong to production, staging, shared services, and so on — so peering connections that cross environment boundaries are visually distinct from connections within an environment.

Isolation violation highlighting: If you define isolation rules (e.g., production VPCs must not be reachable from staging VPCs), Netway runs a BFS on the topology graph and flags any violating edge in red. The violation includes the exact path — not just "these VPCs are connected" but the specific peering connection IDs and intermediate hops involved.

Change tracking between scans: Each scan is diffed against the previous one. New edges (peering connections that appeared) and removed edges (connections that were deleted) are surfaced explicitly. This means you don't have to compare two diagrams visually — the diff tells you exactly what changed and when the change was first detected.

Scan history: Every topology diagram is stored with its scan timestamp. You can look at what your VPC topology looked like 30 days ago, or at the moment before a specific infrastructure change. This is the evidence layer that static diagrams lack entirely.

For teams who want the DOT-format approach for quick one-off inspection, the boto3 script above is a solid starting point. For teams who need continuous visibility, change detection, and evidence that their topology is correct — not just that it exists — Netway handles the graph generation automatically on every scan.