Picture this: It’s Friday afternoon, you’ve been testing Kubernetes deployments all week, and suddenly you realize those EC2 instances are still running. Your weekend AWS bill is about to look like a mortgage payment. We’ve all been there. The manual cleanup process is tedious, error-prone, and let’s face it—you’re already thinking about the weekend.
Enter the nuclear option: tools literally designed to obliterate your AWS resources. But here’s the twist—there are two tools with confusingly similar names, and choosing the wrong one could mean either incomplete cleanup or accidentally nuking resources you actually need. So which do you pick: Cloud-Nuke or AWS-Nuke?
The Tale of Two Nukes
Both tools serve the same essential purpose—automatically deleting AWS resources en masse—but they come from different philosophies and different developers. Cloud-Nuke is from Gruntwork, written in Go, and has been around since May 2017, while AWS-Nuke comes from the German e-commerce company rebuy-de and takes a more comprehensive, configuration-heavy approach.
Here’s the reality check: Cloud-Nuke will not destroy as many objects as AWS-Nuke. That sounds like a disadvantage until you realize it might actually be a feature, depending on your use case.
Why Anyone Would Want a Destruction Tool
Before we dive into the comparison, let’s address the elephant in the room: why would you want a tool specifically designed to delete everything? It sounds reckless, right?
The Gruntwork team learned this lesson the hard way. They built Cloud-Nuke after realizing their AWS testing accounts were costing them hundreds of dollars monthly from resources left running after automated tests. After implementing Cloud-Nuke to delete resources older than 24 hours, they reduced their AWS bill by roughly 85%.
Here are the legitimate use cases that make these tools invaluable:
Testing and Development Accounts: Automated tests spin up infrastructure, run for minutes, then leave resources hanging around for 23 hours burning money. Clean them up automatically every few hours, and your bill drops dramatically.
Training Environments: Got a “playground” AWS account for staff training? People inevitably create resources and forget about them. As one Medium user described it, “They then sit there wasting energy and money. Nuke ’em!”
Account Decommissioning: Shutting down an entire AWS account manually is brutal—you spend days hunting through billing dashboards trying to figure out what’s still running. These tools handle it in minutes.
Failed Terraform Runs: When infrastructure-as-code deployments fail halfway through, they leave orphaned resources scattered across your account. A nuke tool can clean up the mess so you can start fresh.
Cloud-Nuke: Simple and Straightforward
Cloud-Nuke takes the minimalist approach. Simply running cloud-nuke aws will start the process of cleaning up your cloud account—you’ll be shown a list of resources that’ll be deleted as well as a prompt to confirm before any deletion actually takes place.
The simplicity is both its strength and limitation. Cloud-Nuke supports a focused set of AWS resources including AMIs, Auto Scaling Groups, EBS volumes, EC2 instances, ECS services and clusters, Elastic IPs, EKS clusters, Load Balancers (both Classic and v2), Lambda functions, Launch Configurations, RDS instances, S3 buckets, Snapshots, SQS queues, and Transit Gateways. That covers most common resources, but it’s not exhaustive.
The killer feature? Time-based filtering. You can nuke only resources older than a specified time period using the --older-than flag, such as cloud-nuke aws --older-than 1h. This means you can run it aggressively in automated testing accounts without worrying about deleting resources someone is actively using.
You can also target specific regions or exclude certain resource types. For example, if you want to keep your EC2 instances and S3 buckets but delete everything else: cloud-nuke aws --exclude-resource-type s3 --exclude-resource-type ec2.
The tool even has a dry-run mode that shows you what would be deleted without actually pulling the trigger—because everyone needs to see the destruction preview before committing to it.
AWS-Nuke: Maximum Destruction, Maximum Control
AWS-Nuke is the nuclear weapon to Cloud-Nuke’s tactical strike. It supports removing resources via the AWS Cloud Control API, automatically removing a manually managed set of resources, though only a subset of Cloud Control supported resources will be removed automatically.
The key difference? AWS-Nuke demands a configuration file. You can’t just run it and hope for the best—you must explicitly define what you’re doing. This config file includes regions, account blocklists (production accounts you never want to touch), and detailed filters for resources you want to preserve.
Here’s a minimal example configuration:
regions:
- eu-west-1
- global # for resources like Route53
account-blocklist:
- "111222333444" # production account
accounts:
"999888777666": {} # dev account
The config file contains a blocklist field—if the Account ID you want to nuke is part of this blocklist, AWS-Nuke will abort. It’s recommended to add every production account to this blocklist. This safety mechanism has probably saved countless jobs.
AWS-Nuke also handles resource dependencies intelligently. When you delete resources with complex relationships (like VPCs with subnets, security groups, and route tables), AWS-Nuke retries deletions until either everything is gone or only resources with persistent errors remain. It doesn’t just fail on the first API error like a naive script would.
The filtering capabilities are extensive. You can filter by resource properties using exact matches, glob patterns, or even invert filters. Want to delete all CloudFormation stacks except the one called “production-stack”? Easy:
CloudFormationStack:
- property: Name
value: "production-stack"
invert: true
The Security Angle Nobody Talks About
Here’s something disturbing: these tools aren’t just for DevOps housekeeping. In 2021-2022, the LAPSUS$ ransomware group targeted organizations using AWS by exploiting compromised AWS credentials and utilizing tools like AWS-Nuke and Cloud-Nuke to destroy cloud infrastructure.
Think about it: if an attacker gets your AWS credentials, they don’t need to write custom deletion scripts. They can just download an open-source nuke tool and obliterate your entire infrastructure in minutes. The LAPSUS$ group demonstrated this wasn’t theoretical—they actually did it to extort companies.
This means your AWS credentials deserve the same protection as production database passwords. Enable MFA everywhere. Use IAM roles with temporary credentials. Monitor CloudTrail for unusual deletion patterns. And for heaven’s sake, implement the account blocklist feature in AWS-Nuke if you use it.
The Fork Situation You Should Know About
Plot twist: AWS-Nuke has actually been forked and is now maintained more actively by a developer named ekristen. This fork became necessary after attempting to make contributions and learning that the current maintainers only have time to work on the project about once a month.
The rebuy-de repository is now archived and read-only as of October 2024, while the ekristen fork continues active development with better test coverage, semantic releases, and ongoing feature additions. If you choose AWS-Nuke, you probably want the fork at ekristen/aws-nuke rather than the original.
So Which One Should You Choose?
Here’s the decision matrix:
Choose Cloud-Nuke if:
- You want simplicity and speed without extensive configuration
- You’re cleaning up development/testing accounts regularly
- Time-based filtering is your primary need (delete anything older than X hours)
- You don’t need to delete every possible AWS resource type
- You prefer tools that don’t require YAML configuration files
Choose AWS-Nuke if:
- You need comprehensive coverage of AWS resources
- You want fine-grained filtering by resource properties
- You’re managing multiple AWS accounts and need blocklist protection
- You’re comfortable with configuration files and prefer explicit control
- You need to handle complex resource dependencies automatically
For most development teams running automated tests, Cloud-Nuke hits the sweet spot—it’s fast, simple, and the time-based filtering prevents accidents. One DevOps engineer put it perfectly: “cloud-nuke is a tool you can use to completely obliterate resources in your AWS account. We’re in the business of building clouds, not destroying them. Well, there are actually several very good reasons.”
For organizations winding down accounts or needing bulletproof safety mechanisms, AWS-Nuke’s required configuration and blocklisting features provide essential guardrails. The extra complexity pays for itself the first time it prevents someone from accidentally nuking production.
The Safety Dance
Regardless of which tool you choose, follow these safety practices:
Always test in a sandbox first: Create a throwaway AWS account, populate it with test resources, and practice with the nuke tool. See what gets deleted and what doesn’t.
Use dry-run mode religiously: Both tools support preview modes. Use them. Every. Single. Time.
Implement AWS account separation: Never run nuke tools in accounts containing production resources. Use separate accounts for dev, staging, and production.
Set up CloudTrail alerts: Configure alerts for mass deletion events. If someone (or some attacker) starts nuking resources, you want to know immediately.
Tag important resources: While Cloud-Nuke has limited tag support, you can use tags with AWS-Nuke filters to protect critical resources.
The Bottom Line
Both Cloud-Nuke and AWS-Nuke are powerful tools that solve real problems—primarily the problem of AWS bills spiraling out of control from forgotten test resources. The Gruntwork team’s 85% cost reduction speaks for itself.
But with great power comes great responsibility, and tools literally designed to delete everything demand respect. Choose based on your needs: simplicity versus comprehensive control. Test thoroughly before using in any account containing resources you care about. And never, ever run either tool in production.
As one developer wisely noted in a DEV Community guide: “By using Cloud-Nuke, you don’t only take control of your AWS resources—you also prevent yourself from unexpected bills. NOTE: always use this tool with caution, especially in production environments, as it can have significant consequences on your infrastructure.”
That’s not paranoia. That’s wisdom earned from experience. Because the only thing worse than manually deleting resources for hours is accidentally deleting resources you actually needed.
Most Useful Links
Cloud-Nuke (Gruntwork):
AWS-Nuke:
Safety & Best Practices:
Community Resources:
