Terraform-Style Plan/Apply Workflow for AWS Account Resets/Cost Optimization
- Apr 11
- 1 min read
Most AWS cleanup scripts fail for the same reason: they ignore resource dependencies.
You can't delete a VPC while subnets exist in it. You can't release an Elastic IP while it's still associated with a NAT Gateway. You can't delete a security group that another security group references in its rules.
A flat deletion list hits these walls immediately. So I built something that doesn't.
The AWS Account Reset/Cost Optimization Framework follows Terraform's plan/apply pattern:
▸ `plan` — read-only discovery across EC2, RDS, S3, VPC, IAM, Lambda, DynamoDB, and CloudFormation. Returns a prioritized wave plan. Nothing is touched.
▸ `apply` — runs the plan through a GitHub Actions approval gate. An approver sees the full inventory, clicks Approve or Reject, and only then does deletion execute.
Deletion happens in dependency-ordered waves with concurrent execution within each wave. CloudFormation stacks go first (cascade handles their children). Elastic IPs go after NAT Gateways. Security group rules are revoked before the groups are deleted.
I wrote up every design decision, the filter pipeline, the wave architecture, the idempotency logic, and the approval gate in a new post.
If you've ever inherited a messy sandbox account, this might be useful.
The medium link below will take you to the article, feel free to leave a feedback on the. comment section.
Comments