The VPC Cleanup Discipline

VPCs accumulate. Each costs nothing alone; the cumulative effect is a tangle.

VPC inventory

VPC cleanup starts with knowing which VPCs exist and who owns them. Without a tagged, queryable inventory the rest of the discipline runs on guesswork.

• List every VPC. Cross-account inventory tagged with owner, purpose, age, and last-modified. Pull from AWS Config or a one-time describe-vpcs sweep.
• Untagged is suspect. A VPC with no owner tag is treated as a deletion candidate. Either someone claims it within 30 days or it goes.
• Quarterly refresh. Rebuild the inventory each quarter. New VPCs surface immediately rather than aging into orphans.
• Central registry. The catalog is searchable by every team. Cross-team visibility prevents the “I thought your team owned that” conversation.

Retirement criteria

Retirement criteria are explicit so the team can act on them without re-litigating each case. Three triggers cover almost every retirement decision.

• 30 days no activity. No instances, no traffic, no recent modifications. Strong deletion candidate.
• Owner team retired. The service or team that owned the VPC no longer exists. Surviving teams confirm or release.
• Security violations. Open security group, public exposure, or unencrypted resources. Immediate action: retire or fix, not both later.
• Published candidate list. Each quarter publishes the named retirement candidates. Reviewers see the set; nothing slips through silently.

Retirement process

The retirement process is three stages with a rollback window. Each stage gives owners a chance to intervene before the deletion lands.

• 30-day notice. Explicit warning to the listed owner. Owner has time to claim, migrate, or document the exception.
• Drain. Redirect inbound traffic and watch for unexpected dependencies. Surprise dependencies surface here, not after deletion.
• Tear-down. terraform destroy or equivalent. Audit log captures the destruction with operator identity.
• Rollback window. Post-tear-down restore option for 7 days. The window catches the rare “we deleted the wrong one” case.

Preventing accumulation

Prevention is cheaper than cleanup. Four habits stop the VPC catalog from accumulating orphans in the first place.

• Owner at creation. IaC enforces an ownership tag. Apply fails without one; orphans cannot be born.
• Quarterly ownership review. Listed owners reconfirm continued need each quarter. Stale ownership surfaces immediately.
• Naming convention. Descriptive names embed purpose and team. Old or unmaintained VPCs surface by name alone in the inventory.
• IaC-only creation. Console-built VPCs fail compliance. The discipline closes the easiest path to a future orphan.