AWS Nuke: A practical guide to safely deleting AWS resources

Managing cloud environments often involves provisioning, testing, and eventually cleaning up infrastructure. While tools like Terraform or CloudFormation are commonly used to automate resource provisioning, in many cases — especially in test or sandbox environments — some resources may still be created manually for quick experiments or one-off tasks. This mix of automated and manual provisioning makes tearing down the environment more complex, as not all resources are tracked or managed by infrastructure-as-code tools.

That’s where AWS Nuke comes in: a powerful, open-source tool for deleting all resources from an AWS account. But with great power comes great responsibility — AWS Nuke can wipe out an entire account if not used carefully.

In this article, we’ll explore what AWS Nuke is, how it works, and most importantly — how to fully automate the nuking process across multiple AWS accounts in a safe, scalable, and centralized way.

What is AWS Nuke?

AWS Nuke is a CLI tool written in Go that automatically deletes supported AWS resources across regions and accounts. It’s ideal for:

• Cleaning up test or sandbox environments,
• Resetting accounts for training or workshops,
• Managing cloud cost hygiene by removing unused resources.

AWS Nuke is especially helpful when you’re dealing with multiple AWS regions and a wide variety of services — manually cleaning them would be time-consuming and error-prone.

Source on GitHub: ekristen/aws-nuke

How does AWS Nuke work?

AWS Nuke operates based on a configuration file (config.yaml) where you specify rules:

• The AWS accounts to target,
• The regions to scan,
• Resource filters (which resources to include/exclude).

By default, Nuke runs in dry-run mode, which shows what would be deleted given the current config, but without making actual changes just yet.

regions:  - global  - us-east-1  - us-east-2blocklist:  - "987654321098" # Production Accountsettings:  EC2Image:    IncludeDisabled: true    IncludeDeprecated: true    DisableDeregistrationProtection: true  EC2Instance:    DisableStopProtection: true    DisableDeletionProtection: true  RDSInstance:    DisableDeletionProtection: true  CloudFormationStack:    DisableDeletionProtection: true  DynamoDBTable:    DisableDeletionProtection: true

Once your config.yaml is defined, you can run the nuke command (i.e. aws-nuke nuke).

Resource tagging for protection

To protect business-critical resources, each team can apply the tag that they choose, ex.:

excludeFromNuke: true

The configuration ensures that any resource with this tag will be excluded from deletion:

filters:  __global__    - property: "tag:excludeFromNuke"      value: true

This gives teams autonomy over what gets deleted, without modifying the central configuration.

How I automated it — centralized CodeBuild in delegated admin

While it’s entirely possible to run AWS Nuke manually by configuring credentials for each account and executing the aws-nuke command from your terminal, we prefer automation — especially in environments where regular cleanup is needed.

If you anticipate the need to run AWS Nuke on a recurring basis, it makes sense to automate the process. In this section, I’ll walk you through a robust solution for automating AWS Nuke execution safely, centrally, and regularly across specific accounts in your AWS Organization.

The entire system runs from a delegated admin account. Here’s the architecture in a nutshell:

• Terraform modules were written and orchestrated via Terragrunt, which deploy one AWS CodeBuild project per AWS account (but all projects are hosted in the delegated admin account),
• These CodeBuild jobs are scheduled to run once per week using EventBridge.

Each CodeBuild project is configured to:

• Assume a cross-account role into its respective target account,
• Run the aws-nuke command with a pre-defined config.yaml,
• Execute on a weekly schedule (via EventBridge),
• Exclude resources tagged with awsNuke:false (you can choose tag by yourself setting it up in the config.yaml file) to prevent accidental deletion.

This design allows all execution to remain centralized, while still performing cleanup actions per-account, with full isolation and proper access boundaries.

Dynamic config.yaml generation from Organization Units

Instead of hardcoding account IDs into config.yaml, the setup can be made fully dynamic.

Using Terragrunt, a list of Organization Units (OUs) is passed in to target for cleanup. During provisioning, a script queries AWS Organizations to:

• Discover all accounts within the given OUs,
• Automatically generate a valid config.yaml file with those account IDs.

This means any new account added to an OU is automatically included in the next cleanup cycle — no manual updates needed.

Be careful with IAM Identity Center (SSO)

One of the most frequently reported issues with AWS Nuke is the accidental deletion of IAM Identity Center (formerly AWS SSO) resources. These include users, permission sets, and configurations critical for account access.

To avoid deleting them, you must explicitly add them to the filters:

presets:  sso:    filters:      IAMSAMLProvider:      - type: "regex"        value: "AWSSSO_.*_DO_NOT_DELETE"      IAMRole:      - type: "glob"        value: "AWSReservedSSO_*"      IAMRolePolicyAttachment:      - type: "glob"        value: "AWSReservedSSO_*"

Failing to do this may result in losing access to the account, especially if it’s managed through an AWS Organization or Control Tower setup.

Best practices for using AWS Nuke

To use AWS Nuke safely and effectively:

1. Always run in dry-run mode first,
2. Validate what will be deleted before --no–dry-run mode,
3. Use filters to exclude important IAM users, roles, buckets, or security configurations,
4. Use account-blocklist to ensure AWS Nuke never targets your live environments,
5. Only include the regions you actively use,
6. Use tag-based logic within filters for more control (e.g. only delete resources with nuke=true),
7. Avoid experimenting in real environments — mistakes can be irreversible.

Limitations and risks

AWS Nuke is powerful but not foolproof. Some limitations to consider:

• Not all services are supported. For example, newer AWS services or specific regional-only features might not be handled.
• No automatic dependency handling. For instance, you can’t delete a VPC if dependent subnets still exist.
• No rollback. Deleted resources are gone — there’s no built-in undo mechanism.
• Can remove login or billing configurations . Use extreme caution on Organization root accounts or IAM Identity Center setups.

Conclusion

AWS Nuke is a fast, powerful, and dangerous tool. It’s perfect for quickly wiping clean test or sandbox environments, but it requires careful configuration, auditing, and usage discipline. Used incorrectly, it can cause serious — and irreversible — damage.

If you’re looking to implement AWS Nuke in your environment, start with small test runs, build a robust filter list, and ensure production environments are never in scope.

When used wisely, AWS Nuke can become a key part of your infrastructure lifecycle management toolkit.