Skip to content

AWS Security

A Safer AWS Baseline: Cleaning Up Default VPCs Across Regions

How a focused Python and boto3 utility turns default VPC cleanup into a deliberate, reviewable security operation with dry runs, region controls, least privilege and post-change verification.

Security starts with removing ambiguity

Every AWS account can begin with default VPCs in enabled regions. That convenience is useful for experimentation, but it can also leave teams with an unclear network baseline: default subnets, routes and internet gateways may exist in regions where no workload should run.

The aws-security repository takes a focused approach to that problem. It provides a Python utility for finding and removing default VPCs across an account, while keeping the scope deliberately narrow enough to review. It does not attempt to manage custom VPCs or become a general-purpose cloud cleanup tool.

What the utility does

  1. Discovers the AWS regions available to the current account or selected profile.
  2. Finds default VPCs in each region through the EC2 API.
  3. Displays the account ID, account alias and exact VPC IDs before any deletion.
  4. Applies optional region allowlists and exclusion lists.
  5. Exports the proposed cleanup plan as JSON or CSV when an audit artifact is useful.
  6. Stops after a dry run or asks for explicit confirmation before destructive work.
  7. Removes known dependencies such as internet gateways and subnets, then deletes the default VPC.
  8. Queries the account again after cleanup so the result can be verified.

Why default VPC cleanup can improve a security baseline

A default network is not automatically a vulnerability, and deleting one is not a substitute for network design. The security benefit is reducing accidental reliance on an unreviewed starting point. Custom VPCs make subnet placement, routing, security groups, network ACLs and public exposure explicit for the workloads that actually need them.

The repository's narrow scope is an important control. It limits the blast radius and makes the operation easier to understand in a change review. Resources in custom VPCs are outside the tool's intended scope.

The safety sequence

The script treats deletion as a workflow rather than a single API call:

discover regions
  -> filter or exclude regions
  -> identify account and default VPC IDs
  -> export or review the cleanup plan
  -> dry run, or confirm explicitly
  -> remove dependencies
  -> delete default VPCs
  -> verify the post-cleanup state

That sequence gives operators several chances to catch the most dangerous mistake: running against the wrong account or region set. The --profile, --region and --exclude-region options make the execution context visible and constrainable.

Start with a dry run

Preview the operation before allowing any deletion:

python3 default_vpc_cleanup.py --dry-run
python3 default_vpc_cleanup.py --dry-run --export-json cleanup-plan.json

For a staged rollout, target a small region set first:

python3 default_vpc_cleanup.py   --profile staging   --region us-east-1   --region us-west-2

Automation can use --yes, but that flag should be reserved for a controlled pipeline where the AWS identity, region list and dry-run output have already been validated.

Least-privilege permissions

The documented IAM policy is intentionally limited to the APIs needed by this utility: region and VPC discovery, internet gateway and subnet inspection or deletion, VPC deletion, and optional account-alias lookup. The policy still uses Resource: * because these EC2 actions do not provide a narrower resource scope for every operation. Attach it to a dedicated role or profile rather than broad administrator credentials, and protect the profile with the normal controls for production access.

CloudTrail should be enabled so deletion API calls can be reviewed independently of the script's console output. JSON or CSV exports provide an additional record of the plan that was reviewed before execution.

Testing without touching AWS

The repository includes unit tests that mock AWS clients and exercise the safety-oriented parts of the CLI: dry-run parsing, profile and confirmation flags, region filtering, exclusions, account-alias handling and normalized user input. Run them before testing in a sandbox account:

python3 -m unittest -q

This separation matters. Local tests validate control flow and argument behavior cheaply, while a sandbox account validates the real AWS resource relationships. Production should be the last environment considered, not the first place the script is discovered.

Operational boundaries

  • VPC deletion is irreversible and has no built-in rollback.
  • Workloads or other dependencies can cause AWS to reject deletion; the utility does not replace an inventory of EC2, RDS or other attached resources.
  • The tool only handles default VPCs and should remain separate from broader resource cleanup.
  • A recovery plan should document how an approved default VPC or equivalent custom network would be recreated.

A practical rollout checklist

  1. Use a sandbox account and confirm the active AWS profile.
  2. Run the unit tests and inspect the utility's IAM permissions.
  3. Run a dry run for one or two regions and export the plan.
  4. Check the account ID, alias, VPC IDs and workload dependencies.
  5. Have a second operator review the plan and recovery procedure.
  6. Execute with the smallest approved scope, then verify the post-cleanup report and CloudTrail events.

Explore the implementation

This article summarizes the design; the repository contains the executable utility, tests, security policy, permissions guidance and usage examples. Read the full implementation at github.com/ransarnova/aws-security.