AWS Security Group Mapper

Problem

Security Groups are one of those AWS primitives that start simple and end up impossible to reason about at scale:

• Multiple VPCs, environments, and accounts all reusing the same patterns.
• Security Groups referencing other Security Groups, creating implicit trust chains.
• Ports and CIDR ranges woven together in ways that make blast radius analysis painful.

Most teams are left with either:

• Text-only views (CLI, console tables) that don’t show structure, or
• Heavy-weight commercial tools that are overkill for smaller environments or personal use.

You wanted something in the middle: a focused mapper that turns SG relationships into a graph you can actually see and discuss.

Approach

I built AWS Security Group Mapper as a Python CLI that:

1. Discovers Security Groups from AWS

   • Uses boto3 to pull SG configurations (group IDs, names, VPCs, ingress/egress rules).
   • Normalizes rules into a graph-friendly representation: nodes (SGs, CIDRs) and edges (allows traffic from → to on specific ports).

2. Builds a relationship graph

   • Uses NetworkX to model each Security Group and its references as a directed graph.
   • Distinguishes:
     • SG → SG references
     • SG → CIDR ranges
     • Potential “hub” groups that could fan out access to many resources.

3. Visualizes the topology

   • Static diagrams via Graphviz (PNG/SVG) for quick documentation and reviews.
   • Optional interactive HTML visualizations via Plotly (hover for details, filter by tag, zoom into subgraphs).

4. Supports environment-aware runs

   • Simple CLI flags to filter by VPC ID, tag patterns, or environment name (e.g., prod, staging).
   • Output modes for:
     • quick summary reports (e.g., “top 10 most-connected SGs”)
     • a full graph export for offline review.

The core design principle: no magic, no opaque scoring system—just a clear map from AWS configuration to a human-readable graph.

Outcomes

• Turned “I think this SG is safe” into “Here’s a diagram that shows exactly how traffic can reach this cluster.”
• Made it easier to run blast radius reviews before big infrastructure changes—especially when pairing with infra-as-code changes.
• Helped highlight:
  • overly-permissive SGs
  • unexpected transitive trusts (SG referencing SG referencing public CIDR)
  • consolidation opportunities where multiple SGs duplicated rules.

Even as a personal tool, it serves as a strong demonstration of how you approach security, observability, and developer ergonomics at the cloud networking layer.

Key Contributions

• Designed and implemented a graph-based model for AWS Security Group relationships using NetworkX.
• Built a CLI that is usable by both infra engineers and security folks without forcing them into a specific workflow.
• Integrated Graphviz and Plotly to support both static diagrams and interactive views.
• Focused on the questions architects actually ask:
  • “What can reach this subnet?”
  • “Where do we have public exposure?”
  • “What happens if we change this SG?”
• Demonstrated your ability to move from conceptual cloud security concerns to a concrete, inspectable tooling solution.