# cloud-nuke: deleting 125+ AWS resource types from a test account > cloud-nuke is a Go CLI from Gruntwork that deletes every resource in an AWS account, or just the ones a config file names. It is built for throwaway test accounts, and its destructive mode is exactly as blunt as it sounds. **gruntwork-io/cloud-nuke** — A tool for cleaning up your cloud accounts by nuking (deleting) all resources within it - Repository: https://github.com/gruntwork-io/cloud-nuke - Website: https://gruntwork.io/ - Stars: 3,189 · Forks: 381 - Language: Go - License: MIT - Published: 2026-09-24 · Updated: 2026-09-24 · Language: en - Canonical page: https://hysenlabs.com/projects/gruntwork-io-cloud-nuke ## The problem cloud-nuke solves: leftover resources in accounts nobody owns Test accounts accumulate. An EC2 instance here, an S3 bucket there, a default VPC with an open security group, an EKS cluster someone forgot to tear down. Deleting them one service at a time through the console is slow and easy to do incompletely, and the leftovers cost money and widen the attack surface. cloud-nuke exists to answer that with one command: `cloud-nuke aws` deletes all resources in the account, and the README describes this mode in capitals as HIGHLY DESTRUCTIVE, with the instruction that it should never be used in a production environment. The audience is narrow and deliberate. Gruntwork positions the tool for cleaning up test accounts, removing leftover resources, and eliminating defaults such as default VPCs and permissive security group rules. If your organisation hands engineers short-lived AWS accounts for experiments, cloud-nuke is the janitor. If you have one account that runs the business, it is a loaded gun with a confirmation prompt. ## How cloud-nuke works: a Go binary, per-service SDK clients, and a region sweep The repository is a Go module, `github.com/gruntwork-io/cloud-nuke`, on Go 1.25.0, and the layout tells you the architecture before you read any docs. Top-level directories include `aws/` and `gcp/`, `commands/`, `config/`, `resource/`, `renderers/`, `reporting/`, `telemetry/`, and `util/`. The `go.mod` file lists per-service AWS SDK v2 modules, one for each resource family the tool knows how to delete: `service/ec2`, `service/s3`, `service/eks`, `service/dynamodb`, `service/cloudformation`, `service/cloudwatchlogs`, `service/elasticache`, and dozens more, alongside Google Cloud clients for artifact registry, functions, pubsub, and storage. That dependency list is the mechanism. Each resource type is backed by a client for the relevant API, and the CLI walks the account region by region, enumerating what exists and then deleting it. The README states support for 125+ AWS resource types, with a full list in `docs/supported-resources.md`. Four commands sit on top of that machinery: `cloud-nuke aws` for the full sweep, `cloud-nuke inspect-aws` to list without deleting, `cloud-nuke defaults-aws` to remove default VPCs and the default ingress and egress rules on default security groups, and `cloud-nuke aws --config path/to/config.yaml` for filtered runs. The filters are the part that makes the tool usable outside a pure sandbox. `--region` restricts the sweep to named regions, `--resource-type` restricts it to named services, and `--dry-run` previews what would be deleted. A config file goes further, and the README points to `docs/configuration.md` for the format and filter examples. The GCP directory and the Google Cloud dependencies in `go.mod` indicate that the project is not AWS-only in its codebase, but the README's quick start, resource count, and warnings are all written around AWS. ## Installing cloud-nuke and running a first dry run The README gives two install paths. The first is a binary from the releases page: download the build for your OS, move it onto your `PATH`, add execute permissions, and check that it runs. The second is a package manager, with the caveat that package managers are third party and may not carry the latest version, so you should compare your installed version against the releases page. For macOS or Linux with Homebrew, the install is one line. On Windows the README uses winget. ```bash brew install cloud-nuke ``` ```bash winget install cloud-nuke ``` If you take the binary route instead, the README's example moves the macOS build to `/usr/local/bin` and marks it executable: ```bash mv cloud-nuke_darwin_amd64 /usr/local/bin/cloud-nuke chmod u+x /usr/local/bin/cloud-nuke cloud-nuke --help ``` Credentials come from the standard AWS CLI credential mechanisms, so whatever profile or environment variables your AWS CLI already uses will be picked up. Before deleting anything, run the inspection command, which lists resources without touching them: ```bash cloud-nuke inspect-aws ``` Then preview a scoped deletion. This example limits the sweep to two regions and two resource types, which is the shape most first runs should take: ```bash cloud-nuke aws --region us-east-1 --region us-west-2 --resource-type ec2 --resource-type s3 --dry-run ``` If the preview matches what you expect, drop `--dry-run` to execute the deletion. For a config-driven run, the README shows `cloud-nuke aws --config path/to/config.yaml`. The README does not document a rollback path, and there is no undo for a deleted resource. ## Where cloud-nuke is the wrong tool The obvious failure mode is running `cloud-nuke aws` against the wrong account. The confirmation prompt is the only guardrail the README describes, and no amount of `--dry-run` discipline protects a script that omits the flag. The README's own warning is unambiguous: this mode should never be used in a production environment. A subtler problem is that deletion is not always complete or safe in the order it happens. Resources have dependencies. Deleting a VPC before the instances inside it, or a security group still attached to a load balancer, can fail or leave orphans, and the repository's `reporting/` and `renderers/` directories exist because the tool has to tell you what it did rather than guarantee a clean slate. Treat a run as a report to read, not a transaction. `cloud-nuke defaults-aws` is a different risk profile. It deletes default VPCs and default security group rules, and the README says it can be used in production, but with caution. If anything in your account still relies on the default VPC (an old instance, a Lambda in a default subnet, a developer's quick test), that command removes the network under it. The README gives no inventory of what depends on the default VPC before deletion. Finally, cloud-nuke is not an inventory or compliance tool. `inspect-aws` lists resources, but the project does not claim to track drift, cost, or ownership over time. If your problem is knowing what you have, this is the wrong instrument. ## cloud-nuke vs aws-nuke: two different answers to the same question The comparison people search for is cloud-nuke vs aws-nuke, and the difference in approach is worth stating precisely. Both delete AWS resources. aws-nuke is built around a configuration file that must account for every resource before anything is deleted: resources not covered by an explicit filter are treated as unmanaged and the run refuses to proceed without an override. That is a safety-first design, and it makes the config file the centre of the workflow. cloud-nuke inverts the default. `cloud-nuke aws` deletes everything it finds; filtering is opt-in through `--region`, `--resource-type`, and a config file. The README frames the tool around that aggressive default, warning in the same breath that it is highly destructive. The trade-off is real: aws-nuke forces you to enumerate what you want to keep, cloud-nuke lets you run first and narrow later. For a disposable test account, cloud-nuke's default is faster. For an account with anything you care about, aws-nuke's refusal to delete unlisted resources is the property you actually want. A second difference is scope. cloud-nuke's README documents 125+ AWS resource types and a `defaults-aws` command aimed at default VPCs and default security groups, which aws-nuke does not frame as a separate workflow. cloud-nuke's `go.mod` also carries Google Cloud clients, though the README does not document a GCP quick start. ## Maintenance, releases, and what the MIT licence leaves to you The repository is not archived and the last push was on 2026-09-18. Releases are frequent: v0.50.0 on 2026-04-26, v0.51.0 on 2026-06-10, and v0.52.0 on 2026-06-13. If you install through Homebrew or winget, the README warns that those channels are third party and may lag, so checking your binary against the releases page is part of the upgrade routine rather than an optional step. Upgrade cost is mostly operational, not technical. There is no migration to run and no server to restart; you replace a binary. The thing to watch is the config file. As resource types are added, a filter written for an older version may not cover resource types the newer binary knows about, and since cloud-nuke deletes by default, a filter that was exhaustive in v0.50.0 is not guaranteed to be exhaustive in v0.52.0. Re-read `docs/configuration.md` and `docs/supported-resources.md` when you bump the version. Telemetry is a policy decision, not a technical one. Since v0.29.0 the tool sends the command name, version, and AWS account ID to Gruntwork; the README states that IP addresses and resource names are never collected, and `DISABLE_TELEMETRY=1` turns it off. Licence-wise, the code is MIT, which permits commercial use and modification with the copyright notice retained. That is a statement about the licence text, not advice about your situation; if you redistribute cloud-nuke inside a product, read `LICENSE.txt` yourself. ## Conclusion Adopt cloud-nuke if you run disposable AWS test accounts and want a single binary that sweeps them clean, or if you want to delete default VPCs and permissive default security group rules across an estate. Do not point `cloud-nuke aws` at a production account, and do not expect it to be an inventory tool: `inspect-aws` lists, it does not protect. Before you rely on it, verify three things in your own account: which resource types your config file actually filters, whether the telemetry payload (command name, version, AWS account ID) is acceptable under `DISABLE_TELEMETRY=1` or not, and whether your AWS credentials are scoped narrowly enough that a wrong `--region` cannot reach a shared account. The README states plainly that the `aws` command should never be used in production; treat that line as the specification, not as a disclaimer. ## FAQ ### What is cloud-nuke used for? It deletes resources in a cloud account. The README describes it as a CLI for cleaning up test accounts, removing leftover resources, and eliminating defaults such as default VPCs and permissive security group rules. ### What is cloud-nuke? cloud-nuke is a Go CLI from Gruntwork that deletes all resources in an AWS account, or a filtered subset of them. It supports 125+ AWS resource types per the README, and also ships an `inspect-aws` command that lists resources without deleting. ### Is cloud-nuke free or paid? The code is released under the MIT License, per the README, so there is no licence fee to use it. The README does not describe any paid tier for the tool itself. ## Sources - [gruntwork-io/cloud-nuke on GitHub](https://github.com/gruntwork-io/cloud-nuke) - [License: MIT](https://github.com/gruntwork-io/cloud-nuke/blob/master/LICENSE) - [Project website](https://gruntwork.io/) - [README](https://github.com/gruntwork-io/cloud-nuke/blob/master/README.md) - [Releases](https://github.com/gruntwork-io/cloud-nuke/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gruntwork-io-cloud-nuke