Automating AWS Account Cleanups

Managing AWS resources across multiple accounts is one of those challenges that grows quietly in the background until it becomes impossible to ignore. As organizations scale, temporary environments, proofs of concept, and development sandboxes start piling up, each leaving behind unused resources that continue to consume cost and expand your attack surface. Cleaning them up manually is tedious, error-prone, and rarely sustainable.

That’s where aws-nuke proves invaluable. It’s an open-source tool that can systematically remove every resource in an AWS account, restoring it to a clean state. However, running aws-nuke safely in a multi-account environment isn’t as straightforward as it sounds. Without the right orchestration and guardrails, a single misconfiguration could have destructive consequences.

This article introduces Autonuke — a production-ready solution that wraps aws-nuke in a secure, automated architecture built entirely with AWS managed services. Autonuke turns aws-nuke from a tedious manual operation into a controlled, scalable process that integrates seamlessly into your organization’s account lifecycle management.

Background and Use Cases
Architecture Overview
Getting Started
Safety and Security
Configuration
Triggering & Scheduling
Operating and Optimizing
Cost Analysis
Conclusion & Next Steps

Background and Use Cases

Organizations face several challenges when managing temporary AWS accounts:

Resource sprawl: Developers create resources for testing and forget to clean them up
Cost accumulation: Orphaned resources (EC2 instances, RDS databases, S3 buckets) generate ongoing charges
Security hygiene: Stale resources increase the attack surface and compliance risks
Manual toil: Cleaning accounts manually is tedious and risks missing resources or deleting critical infrastructure
Scale limitations: Managing dozens or hundreds of accounts requires automation

This solution is designed for:

Ephemeral environments: Automatically tear down short-lived accounts after workshops, training sessions, or time-limited POCs
Development sandboxes: Reset developer accounts to a clean state on a regular schedule (e.g., weekly)
Account offboarding: Safely decommission accounts when projects end or business units reorganize
Cost control: Eliminate orphaned resources in non-production accounts to reduce cloud spend
Compliance hygiene: Reset accounts to a known-clean baseline for security audits or compliance requirements

Architecture Overview

The autonuke solution implements a robust, multi-layered architecture designed for safe and efficient AWS account cleanup operations. The system leverages AWS managed services to provide scalability, reliability, and comprehensive monitoring.

Architecture Diagram

AutoNuke Architecture

Core Components

Infrastructure Layer

ECS Fargate Cluster: Provides serverless container execution with automatic scaling and resource management
ECR Repository: Stores the custom aws-nuke container image with immutable tags for version control
VPC & Security Groups: Ensures network isolation and controlled outbound access for the cleanup tasks
Parameter Store: Centralized configuration management for protected accounts and runtime parameters

Orchestration Layer

Step Functions State Machine: Central orchestrator that manages the entire cleanup workflow with built-in retry logic and error handling

Monitoring & Observability Layer

CloudWatch Logs: Comprehensive logging and monitoring for audit trails and troubleshooting

Security & Access Layer

Cross-Account IAM Roles: Secure role-based access control for executing cleanup operations in target accounts
Organization-Level Permissions: Ensures cleanup operations are restricted to accounts within the same AWS Organization
Account Blockist: Prevents accidental cleanup of critical production or shared service accounts

Execution Layer

Containerized aws-nuke: Alpine-based image that dynamically fetches the latest aws-nuke binary at build time
Pre-cleanup Optimizations: Custom scripts for efficient S3 bucket deletion and DynamoDB protection removal
Resource Scaling: Automatic CPU/memory scaling on out-of-memory errors to handle large cleanup operations

Workflow

The system follows a multi-stage workflow designed for reliability and safety:

Initialization: Validates input parameters (account ID) and sets up execution context
Protection Check: Queries SSM Parameter Store and verifies the target account is not in the blocklist
Role Assumption: Securely assumes the NukeExecutionRole in the target account with credential refresh capabilities
Pre-cleanup: Optimizes resource deletion for S3 buckets (batch deletion), DynamoDB tables (removes deletion protection), and backup vaults
Main Cleanup: Executes aws-nuke with comprehensive resource filtering based on configured presets
Error Handling: Implements intelligent retry logic with resource scaling for recoverable errors (OOM = double CPU/memory)
Monitoring: Captures detailed logs in CloudWatch for audit trails and troubleshooting

Getting Started

Prerequisites

Before deploying this solution, ensure you have:

AWS Organization Setup:

An AWS Organization with multiple accounts (sandbox, development, or test accounts)
Organization ID for restricting cross-account access
Designated “management” or “tools” account to host the autonuke infrastructure

Administrative Access:

Administrator-level permissions in the management account to deploy CloudFormation stacks
Ability to create cross-account IAM roles in target accounts
Access to create ECR repositories and push container images

Infrastructure Requirements:

Existing VPC with at least one subnet that has internet access (for pulling aws-nuke binaries)
AWS CLI configured with appropriate credentials
Docker with buildx support for multi-architecture builds

Knowledge Requirements:

Familiarity with AWS Step Functions, ECS Fargate, and CloudFormation
Understanding of IAM roles and cross-account access patterns
Basic knowledge of container operations and Docker

Deployment Guide

1) Deploy the Infrastructure (CloudFormation)

First, customize the parameters file cloudformation/parameters/values-autonuke.json with the following values:

VpcId: The VPC ID that will host the ECS cluster
VpcSubnetId: The subnet ID for the ECS task (must have internet connectivity for pulling container images)
OrgId: Your AWS Organization ID (used to restrict cross-account access)
AccountBlocklist: A comma-separated list of account IDs that should never be cleaned up by this tool (e.g., production accounts, shared services accounts)
ExcludeBucketPrefixes: Comma-delimited list of S3 bucket name or prefixes to exclude from deletion. If not provided or empty, all buckets will be deleted.

[
    {
        "ParameterKey": "ECRRepositoryName",
        "ParameterValue": "aws-nuke"
    },
    {
        "ParameterKey": "VpcId",
        "ParameterValue": "vpc-xxxxxxxxx"
    },
    {
        "ParameterKey": "VpcSubnetId",
        "ParameterValue": "subnet-xxxxxxxxx"
    },
    {
        "ParameterKey": "OrgId",
        "ParameterValue": "o-xxxxxxxxxx"
    },
    {
        "ParameterKey": "AccountBlocklist",
        "ParameterValue": "111111111111,222222222222"
    },
    {
        "ParameterKey": "ExcludeBucketPrefixes",
        "ParameterValue": ""
    }    
]

Deploy the CloudFormation stack (creates ECR, ECS cluster, task definition, IAM roles, Step Functions state machine, and SSM parameter):

aws cloudformation create-stack \
  --stack-name autonuke-stack \
  --template-body file://cloudformation/auto-nuke.yaml \
  --parameters file://cloudformation/parameters/values-autonuke.json \
  --capabilities CAPABILITY_NAMED_IAM

2) Build and Push the Container

The Dockerfile installs aws-nuke dynamically from GitHub Releases and adds the runner script:

FROM alpine:3.22.1

# Install dependencies
RUN apk add --no-cache bash curl jq unzip aws-cli coreutils

# Fetch the latest version of aws-nuke dynamically and install it
RUN REPO="ekristen/aws-nuke" && \
    ARCH=$(uname -m | sed 's/aarch64/arm64/' | sed 's/x86_64/amd64/') && \
    OS=$(uname -s | tr '[:upper:]' '[:lower:]') && \
    LATEST_RELEASE=$(curl -s https://api.github.com/repos/$REPO/releases/latest) && \
    VERSION=$(echo "$LATEST_RELEASE" | grep '"tag_name":' | sed -E 's/.*"([^"]+)".*/\1/') && \
    DOWNLOAD_URL="https://github.com/$REPO/releases/download/$VERSION/aws-nuke-$VERSION-$OS-$ARCH.tar.gz" && \
    echo "Downloading aws-nuke from $DOWNLOAD_URL" && \
    curl -Lo aws-nuke.tar.gz "$DOWNLOAD_URL" && \
    tar -tzf aws-nuke.tar.gz && \
    tar -xzf aws-nuke.tar.gz -C /usr/local/bin aws-nuke && \
    chmod +x /usr/local/bin/aws-nuke && \
    rm aws-nuke.tar.gz

# Add a shell script to generate the aws-nuke config and run aws-nuke
COPY run-nuke.sh /usr/local/bin/run-nuke.sh
COPY config.yaml.template /root/config.yaml.template
RUN chmod +x /usr/local/bin/run-nuke.sh

# Set entrypoint
ENTRYPOINT ["/usr/local/bin/run-nuke.sh"]

Build and push (multi-architecture for both AMD64 and ARM64 Fargate):

# Authenticate to ECR
aws ecr get-login-password --region <region> | docker login --username AWS --password-stdin <account-id>.dkr.ecr.<region>.amazonaws.com

# Build and push multi-arch image
docker buildx build --provenance=false --platform linux/arm64,linux/amd64 \
  -t <account-id>.dkr.ecr.<region>.amazonaws.com/aws-nuke:latest \
  containers/awsnuke --push

3) Configure Protected Accounts

The CloudFormation stack automatically creates the SSM parameter with the accounts specified in AccountBlocklist. You can update it later via AWS CLI if needed:

aws ssm put-parameter \
  --name "/autonuke/blocklist" \
  --value "111111111111,222222222222,333333333333" \
  --type "String" \
  --overwrite

Best Practice: Include your organization management account, shared services account, production accounts, and the account hosting autonuke infrastructure.

4) Deploy the Execution Role in Target Accounts

The aws-nuke container and runner script both assume the execution role in the target account for cleanup operations. Deploy this stack in each account you want to clean:

aws cloudformation create-stack \
  --stack-name auto-nuke-role \
  --template-body file://cloudformation/nuke-role.yaml \
  --parameters ParameterKey=AutoNukeHostAccount,ParameterValue=<management-account-id> \
  --capabilities CAPABILITY_NAMED_IAM \
  --profile <target-account-profile>

For multiple accounts, use StackSets for easier deployment:

# Create the StackSet
aws cloudformation create-stack-set \
  --stack-set-name autonuke-execution-role \
  --template-body file://cloudformation/nuke-role.yaml \
  --parameters ParameterKey=AutoNukeHostAccount,ParameterValue=<management-account-id> \
  --capabilities CAPABILITY_NAMED_IAM \
  --permission-model SERVICE_MANAGED \
  --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false

# Create stack instances (for SERVICE_MANAGED, use OUs instead of individual accounts)
aws cloudformation create-stack-instances \
  --stack-set-name autonuke-execution-role \
  --deployment-targets OrganizationalUnitIds=ou-xxxx-xxxxxxxx \
  --regions us-east-1

Safety and Security

Multi-Layer Protection

Account Blocklist

Stored in SSM Parameter Store (/autonuke/blocklist), this parameter maintains a comma-separated list of account IDs that should never be cleaned. The blocklist is enforced at two levels:
1. State Machine Level: Before launching the aws-nuke container, the Step Functions state machine validates the target account against the blocklist.
2. Container Level: If the aws-nuke container is executed directly, the runner script injects the blocklisted accounts into the aws-nuke configuration at runtime.
In both scenarios, execution fails immediately if the target account is protected, preventing any cleanup operations from starting.
Resource Filtering with Presets

Presets are predefined filter rules that exclude specific resources from cleanup operations. These filters prevent accidental deletion of critical infrastructure, shared services, and resources managed by other AWS services. The following presets are configured:
- nuke preset: Prevents deletion of the autonuke infrastructure itself (CloudFormation stacks, IAM roles containing “nuke”)
- sso preset: Protects AWS SSO/IAM Identity Center resources (AWSReservedSSO_* roles, SAML providers)
- controltower preset: Preserves AWS Control Tower infrastructure (stacksets, log groups, SNS topics, etc.)
- excludebuckets preset: Skips buckets with specific naming patterns (access logs, CloudTrail, Cloudformation stacks, etc.)
- excludebackupsnapshots: Skips deleting snapshots and AMIs that contain a particular tag. This is required if you use AWS Backup and have EBS snapshots or EC2 AMIs. aws-nuke tries to delete these resources using EC2 API which fails. The snapshots should be deleted through the backup service instead.

Best Practices

Before Deployment:

Test in a dedicated sandbox account first
Review and customize the resource type inclusion list
Verify account blocklist includes all production and critical accounts
Document the VPC and subnet IDs used for the ECS tasks

During Operation:

Monitor CloudWatch Logs regularly for unexpected errors
Set up CloudWatch Alarms for failed executions
Review Step Functions execution history weekly
Keep the container image updated with the latest base image and aws-nuke versions

For Ongoing Management:

Schedule regular reviews of the blocklisted accounts
Audit the resource presets as your infrastructure evolves
Test configuration changes in non-critical accounts first
Maintain runbooks for common issues and recovery procedures

Security Considerations

Cross-Account Role Permissions

The NukeExecutionRole deployed in target accounts uses AdministratorAccess managed policy. This is a deliberate design choice with important security implications:

Why Administrator Access?

aws-nuke needs broad permissions to enumerate and delete resources across all AWS services. The tool discovers resources dynamically and attempts to delete them based on configuration. Specific scenarios requiring elevated permissions include:

Service-Specific APIs: Each AWS service has unique deletion APIs (e.g., ec2:TerminateInstances, s3:DeleteBucket, rds:DeleteDBInstance)
Dependency Resolution: Some resources can’t be deleted until dependencies are removed (e.g., VPCs require subnet/route table cleanup first)
DynamoDB & RDS Protection: Disabling deletion protection requires dynamodb:UpdateTable and rds:ModifyDBInstance
Backup Vault Cleanup: Deleting recovery points requires backup:DeleteRecoveryPoint permissions
IAM Role Cleanup: Detaching policies and deleting roles requires multiple IAM permissions

Attempting to craft a minimal permission set would require hundreds of specific actions across 50+ AWS services, and would break whenever:

You add new resource types to clean up
AWS introduces new services or changes APIs
Resources have service-specific protection mechanisms

Security Mitigations:

Despite the broad permissions, several controls limit the risk:

Organization Boundary: The trust policy restricts assumption to principals within your AWS Organization only
```
Condition:
  StringEquals:
    aws:PrincipalOrgID: !Ref OrgId
```
Single-Account Scope: The role can only be assumed from the designated management account (specified by AutoNukeHostAccount parameter)
ECS Task Role Limitation: Only the ECS task role in the management account can assume this role, not individual users
Audit Trail: All role assumptions and API calls are logged in CloudTrail for security monitoring
Account Blocklist: Critical accounts are excluded from cleanup eligibility entirely
No Persistent Credentials: The role uses temporary STS credentials that expire automatically

Configuration

aws-nuke Config Template

The containers/awsnuke/config.yaml.template defines regions, resource types, and safety presets. The runner script injects the account blocklist, regions and target account ID at runtime.

Template structure:

blocklist:
  __BLOCKLISTED_ACCOUNTS__

bypass-alias-check-accounts:
  - __ACCOUNT_ID__

regions:
  __REGIONS__

Resource Type Strategy:

aws-nuke can operate in two modes:

Exclude-Mode (Not Recommended): Attempts to delete all resource types except those explicitly excluded. While comprehensive, this approach has significant drawbacks:
- Scans every AWS API endpoint, including deprecated and legacy services
- Prone to transient failures from unsupported operations
- New AWS services are automatically targeted without review
- Unpredictable behavior as AWS deprecates or changes APIs
Include-Mode (Default): Only targets explicitly listed resource types, providing:
- Predictable behavior: You control exactly what gets deleted
- Stability: Avoids deprecated API endpoints that cause failures
- Safer defaults: New AWS services require deliberate opt-in
- Faster execution: Reduced API calls mean quicker cleanup cycles
- Easier troubleshooting: Clear scope for debugging issues

This solution defaults to include-mode with a curated list of commonly used resource types (EC2, S3, RDS, Lambda, VPC components, etc.). While this requires periodic maintenance to add new resource types, it significantly reduces operational risk and API-related failures. The included configuration template covers 40+ resource types that handle 95% of typical cleanup scenarios.

Recommendation: Start with the default include-mode configuration, monitor cleanup results, and incrementally add resource types as needed rather than attempting comprehensive coverage from day one.

Included resource types (excerpt):

resource-types:
  includes:
    # Compute
    - EC2Instance
    - EC2Volume
    - EC2Snapshot
    - LambdaFunction
    - ECSCluster
    - EKSCluster
    
    # Storage
    - S3Bucket  # Handled by pre-cleanup script
    - EFSFileSystem
    - FSxFileSystem
    
    # Databases
    - RDSDBInstance
    - DynamoDBTable
    
    # Networking
    - VPC
    - Subnet
    - SecurityGroup
    - ElasticIPAddress
    
    # Containers
    - ECRRepository
    
    # IaC
    - CloudFormationStack

Safety Presets:

Presets filter out resources that should never be deleted:

presets:
  nuke:
    filters:
      CloudFormationStack:
        - type: contains
          value: nuke
      IAMRole:
        - type: contains
          value: nuke
  
  sso:
    filters:
      IAMRole:
        - type: glob
          value: AWSReservedSSO_*
      IAMSAMLProvider:
        - type: regex
          value: "AWSSSO_.*_DO_NOT_DELETE"
  
  controltower:
    filters:
      CloudFormationStack:
        - type: contains
          value: AWSControlTower
      CloudTrailTrail:
        - type: contains
          value: aws-controltower
      CloudWatchLogsLogGroup:
        - type: contains
          value: aws-controltower

Resource-Specific Settings:

The settings section configures behavior for specific resource types during cleanup. This section is essential for handling resources that have deletion protection enabled:

settings:
  EC2Instance:
    DisableDeletionProtection: true
  RDSInstance:
    DisableDeletionProtection: true

These settings automatically disable deletion protection on EC2 instances and RDS database instances before attempting to delete them. Without these settings, aws-nuke would fail when encountering instances with deletion protection enabled, as AWS prevents deletion of protected resources by default.

Runner Script Optimizations

Before invoking aws-nuke, the run-nuke.sh script performs pre-cleanup optimizations:

AWS Session Management & Credential Refresh:

Due to role chaining, the maximum session length is 1 hour. When cleaning accounts with large numbers of resources, cleanup operations can run for several hours, resulting in session timeouts and failed executions.

To address this limitation, the runner script implements credential refresh functionality for pre-cleanup actions. Before calling aws-nuke, it restores the ECS execution role credentials and passes the role ARN to aws-nuke. This allows aws-nuke to automatically refresh credentials during long-running operations, preventing session timeouts and enabling successful cleanup of accounts with extensive resources.

S3 Bucket Deletion (Concurrent & Batched):

aws-nuke has known performance issues when deleting S3 buckets containing millions of objects, particularly log buckets with small files. These issues are documented in GitHub issue #613 and GitHub issue #661.

When processing large buckets, aws-nuke’s sequential deletion approach causes several problems:

Performance degradation: Sequential deletion of millions of objects can take hours
Memory exhaustion: Loading large object lists into memory causes out-of-memory errors
Session timeouts: With a maximum session duration of 1 hour, large bucket deletions often exceed this limit

The recommended workaround is to exclude large S3 buckets from cleanup, but this conflicts with the goal of completely cleaning accounts. Instead, the runner script implements a pre-cleanup optimization that uses concurrent batch deletion.

Performance Improvements:

The pre-cleanup script uses two optimization techniques:

Batch Deletion: Groups 1,000 objects per API call instead of individual deletions
Concurrency: Processes up to 12 buckets in parallel

Example Calculation:

For a bucket containing 1 million objects:

aws-nuke approach: 1,000,000 sequential API calls ≈ 2-4 hours (assuming ~10-15ms per call)
Batch deletion: 1,000,000 ÷ 1,000 = 1,000 API calls
With 12 concurrent jobs: 1,000 ÷ 12 ≈ 83 batches per job
Estimated time: ~2-3 minutes (assuming ~1-2 seconds per batch)

Result: Approximately 40-80x faster than aws-nuke’s sequential approach, with significantly lower memory usage and no session timeout issues.

# List all S3 buckets and delete them with concurrency
while read -r bucket; do
  refresh_credentials_if_needed

  # Check if bucket matches any excluded prefix
  skip_bucket=false
  for prefix in "${EXCLUDE_PREFIXES[@]}"; do
    if [[ $bucket =~ $prefix ]]; then
      skip_bucket=true
      break
    fi
  done

  if [ "$skip_bucket" = true ]; then
    echo "Skip bucket: $bucket"
  else
      delete_bucket "$bucket" &
      while [[ $(jobs -r | wc -l) -ge $MAX_JOBS ]]; do sleep 1; done
  fi
done < <(aws s3 ls | cut -d" " -f 3)

The delete_bucket function uses s3api delete-objects with batches of 1,000 objects per API call, dramatically reducing the number of API requests and execution time.

DynamoDB Deletion Protection:

aws-nuke’s configuration settings don’t support disabling deletion protection for DynamoDB tables. To handle this, the runner script enumerates all tables and disables deletion protection before aws-nuke attempts to delete them:

# Disable DynamoDB deletion protection
for REGION in "${REGIONS[@]}"; do
  for table in $(aws dynamodb list-tables --region "$REGION" --query 'TableNames[]' --output text || true); do
    aws dynamodb update-table --table-name "$table" --no-deletion-protection-enabled --region "$REGION" || true
  done
done

Backup Vault Cleanup:

AWS Backup recovery points must be deleted before vaults can be removed:

for vault in $(aws backup list-backup-vaults --region "$REGION" --query 'BackupVaultList[].BackupVaultName' --output text); do
  for arn in $(aws backup list-recovery-points-by-backup-vault \
      --backup-vault-name "$vault" \
      --region "$REGION" \
      --query 'RecoveryPoints[].RecoveryPointArn' \
      --output text); do
    
    aws backup delete-recovery-point \
      --backup-vault-name "$vault" \
      --recovery-point-arn "$arn" \
      --region "$REGION" || true
  done
done

Triggering & Scheduling

Manual Execution

Execute via AWS CLI:

aws stepfunctions start-execution \
  --state-machine-arn arn:aws:states:<region>:<account>:stateMachine:AccountCleanupStateMachine \
  --input '{"account_id": "123456789012"}'

EventBridge Scheduled Rule

EventBridge scheduled rules enable automated, recurring cleanup operations. There are several approaches to scheduling cleanups:

1. One Rule Per Account

Create a separate EventBridge rule for each account that needs regular cleanup. Each rule directly targets the Step Functions state machine with a specific account ID. This approach is straightforward but requires managing multiple rules as the number of accounts grows.

2. Lambda Fan-Out with Multiple Account IDs

Use a single EventBridge rule that triggers a Lambda function. The Lambda function receives a list of account IDs and invokes the Step Functions state machine for each account. This approach centralizes scheduling logic and makes it easier to manage multiple accounts from a single rule.

3. Lambda Fan-Out with Organizational Unit (OU)

Similar to the multiple account IDs approach, but the Lambda function queries AWS Organizations to discover all accounts within a specified Organizational Unit (OU). This enables automatic cleanup of all accounts under an OU without maintaining explicit account lists, making it ideal for dynamic environments where accounts are frequently created or moved.

API Gateway Integration

You can integrate API Gateway to trigger cleanup operations on-demand via HTTP endpoints. This enables programmatic access and integration with external systems or CI/CD pipelines.

Operating and Optimizing

Cost Analysis

The autonuke solution is cost-effective, especially compared to the cost of orphaned resources it cleans up. Note that we assume the management VPC has internet connectivity, and we don’t include network infrastructure charges in our estimates.

Infrastructure Costs (eu-west-1)

Fixed Costs:

ECR Repository: $0.10/GB storage (typically <500MB = $0.05/month)
SSM Parameter Store: Free (standard parameters)
Step Functions: First 4,000 state transitions/month free, then $0.025 per 1,000 transitions
CloudWatch Logs: $0.50/GB ingested, $0.03/GB stored

Variable Costs (Per Execution):

ECS Fargate (x86, eu-west-1):
- 0.25 vCPU, 512 MB: $0.01512/hour
- 0.5 vCPU, 1 GB: $0.03024/hour (after OOM scaling)
- Typical execution: 30-60 minutes for thorough cleanup
Data Transfer: Minimal (API calls only, typically <100 MB per execution)

Example: Weekly Cleanup of 10 Accounts

Scenario: Clean 10 sandbox accounts every Sunday (40 executions/month)

Monthly Costs:

ECR storage: $0.05
Step Functions: 40 executions = $0.00 (within free tier)
ECS Fargate: 40 executions × 45 min avg × $0.01512/hour ≈ $0.45
CloudWatch Logs: 2 GB (aws-nuke is verbose) × $0.53 = $1.06
S3 storage (logs/reports): ~$0.10
Total: ~$1.66/month

Cost Savings Perspective:

A single forgotten RDS instance ($50-500/month) or unused NAT Gateway ($32.40/month) quickly justifies the automation cost. Organizations typically see 10-50x ROI from automated cleanup of sandbox accounts.

Conclusion & Next Steps

This solution provides a production-ready approach to automating AWS account cleanups using aws-nuke. By wrapping the powerful aws-nuke tool in a secure, scalable architecture with comprehensive guardrails, you can safely manage account lifecycle operations across your AWS Organization.

Key Takeaways

Safety First: Multiple layers of protection (account blocklist, resource filters, organization boundaries) prevent accidental damage
Scalable: Handles accounts of any size with automatic resource scaling
Cost-Effective: Pays for itself many times over by eliminating orphaned resources
Auditable: Comprehensive logging and execution history for compliance
Extensible: Easy to customize resource types, regions, and filtering rules

Recommended Next Steps

1. Start Small

Deploy in a non-critical test account first
Run with test_mode to validate configuration
Verify logs and monitoring before production use

2. Establish Cadence

Daily: Ephemeral CI/CD sandbox accounts
Weekly: Developer sandbox accounts
Monthly: Long-lived test/staging accounts
On-demand: Account offboarding and decommissioning

3. Integrate with Existing Workflows

Connect to AWS Control Tower account factory for new account provisioning
Trigger cleanup automatically when accounts are tagged for decommissioning
Include in runbooks for incident response and security remediation

4. Continuous Improvement

Review CloudWatch Logs monthly for patterns and optimization opportunities
Update resource type lists as new services are adopted
Test new aws-nuke versions in sandbox before updating production
Gather feedback from development teams on cleanup effectiveness

5. Extend Functionality

Add Slack/Teams notifications for execution results
Create a self-service portal for developers to trigger cleanups
Implement cost tracking to measure savings from cleanup operations
Build account age policies to automatically clean accounts older than N days

Additional Resources

aws-nuke documentation: https://github.com/ekristen/aws-nuke
AWS Step Functions best practices: https://docs.aws.amazon.com/step-functions/latest/dg/best-practices.html
ECS Fargate pricing: https://aws.amazon.com/fargate/pricing/
IAM cross-account access: https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html

Contributing

If you implement improvements or additional safety features, consider contributing back:

Enhanced resource type coverage
Additional safety presets for other AWS services (e.g., AWS Config, GuardDuty)
Cost optimization techniques
Integration examples with other AWS services

Final Thoughts

Account cleanup is a crucial but often overlooked aspect of AWS management. Automating this process not only saves time and money but also improves security posture and compliance. With proper guardrails and monitoring, autonuke can become a trusted part of your AWS operations toolkit.

Remember: Test thoroughly, start small, and always verify your protected accounts list before deploying to production.

Comments

Loading comments...