aws-nuke for controlled AWS account teardown

The AWS account cleanup problem aws-nuke addresses

aws-nuke targets the problem of removing resources from an AWS account rather than managing each service by hand. It is relevant to engineers cleaning a temporary test account, dismantling a sandbox, or reconstructing an environment after an exercise. Its scope is intentionally broad. The README describes it as a tool to "Remove all resources from an AWS account," but it also warns that not every AWS resource is covered.

That warning limits the meaning of "all resources." An AWS account can contain compute instances, databases, object storage, IAM entities, networking resources, serverless components, and managed services with different deletion APIs. Some objects also refuse deletion until their dependencies are removed. aws-nuke offers a common discovery and removal interface, but it cannot guarantee that every AWS service is implemented.

The tool is therefore a poor fit for casual use against an account containing production data. It can fit a controlled teardown process in which an engineer has already established what belongs to the target environment. The relevant distinction is between an empty account and an account considered empty by policy. aws-nuke automates enumeration and deletion for supported resources. It does not decide which business data, retained logs, compliance records, or shared infrastructure should be removed.

Version 3 also changes how the operator starts that process. The root command no longer triggers a run, so installation alone does not begin account teardown. The operator must invoke an explicit `run` command.

How aws-nuke Version 3 separates resource handling

Version 3 is a rewrite built around libnuke. The README explains that the earlier implementation was difficult to improve without separating common behavior into a library. The rewrite places command handling, shared listing and removal logic, and service-specific resource implementations in distinct areas.

Based on the repository layout, the Go application starts at `main.go`, with shared packages under `pkg/` and AWS service implementations under `resources/`. Test doubles are stored under `mocks/`. This separation allows a resource implementation to work with the shared lifecycle engine rather than placing all AWS logic in one command. libnuke also passes context through its listing and removal operations, according to the README.

The project reports more than 95% test coverage for libnuke. That number describes the shared library and should not be interpreted as equal coverage for every AWS resource. The stated goals leave "Adding more tests around specific resource types" unfinished. A high core-library coverage figure cannot establish that every service lists, classifies, filters, and deletes its resources correctly.

Architecture support is still incomplete. The goals list AWS SDK Go v2 support as unfinished and dependency graph support as a consideration. The absence of a general dependency graph matters during teardown. AWS resources frequently depend on IAM policies, networks, databases, images, or other services, and a flat removal order may encounter failures. CloudFormation receives specific handling, but that does not amount to documented dependency ordering across every AWS resource type.

Global filters and all-region behavior in aws-nuke

Version 3 adds global filters and the ability to run against all enabled regions. These features address two practical account-cleanup problems. A filter limited to one service or region may be insufficient when related resources are distributed across an AWS account. Global filtering also provides a way to express account-wide exclusions rather than maintaining separate rules for each region.

The README excerpt does not include a filter file example, matching syntax, or precedence rules. It directs users to the `docs/` directory and the documentation site, so those pages are the source for constructing and checking filters. The repository also lists `Explain Account` and `Explain Config` as Version 3 features. Those commands are relevant before deletion because they are intended to show how the tool interprets an account or configuration. The README does not show their exact flags or output format.

Running against all enabled regions removes the need to maintain a regional list, but it also expands the deletion boundary. Operators should verify the AWS account before execution, review which regions are enabled, and inspect any account-wide exclusions. A filter that matches more broadly than intended increases the affected set rather than narrowing it.

CloudFormation is one documented example of lifecycle handling. Stacks support a hold state and can wait for a parent deletion process. Nested stacks are also eligible for deletion instead of being omitted. These changes prevent a known class of leftover resources, but the README does not claim that they resolve arbitrary cross-service dependencies.

Installing aws-nuke and making the first run explicit

The README excerpt does not give a complete installation command. It records a published Homebrew tap named `ekristen/tap/aws-nuke@3`, but it does not show the corresponding `brew install` line. It links documentation at `https://ekristen.github.io/aws-nuke/`, while the repository metadata names `https://aws-nuke.ekristen.dev` as the homepage. Users needing installation instructions should consult the current project documentation rather than infer a package command.

After obtaining `aws-nuke` through a documented route, the minimum execution shape confirmed by the README is:

aws-nuke run

Version 3 requires the `run` subcommand, and `nuke` is its documented alias. The executable name matches the project and the Dockerfile entry point. The README does not provide a dry-run flag, confirmation sequence, account-selection argument, or complete first-use example, so this article does not add one.

Before running it against a real account, confirm that the binary has working AWS credentials and that the configured filters and regions match the intended teardown. Also verify the account identity separately. Bulk deletion with credentials attached to the wrong account is a specific operational risk that account-level preflight checks should address.

The Makefile defines the repository's normal Go test command:

go test ./...

That command executes the project's Go tests. It does not remove AWS resources.

Integration tests use a separate build tag:

go test ./... -tags=integration

The Makefile does not document the credentials, infrastructure, or AWS account required by the integration suite. The command should not be treated as safe merely because it ends in a test package name.

Dockerfile packaging for aws-nuke release images

The repository includes a multi-stage Dockerfile that creates an unprivileged user named `aws-nuke`. Its final images copy the compiled executable to `/usr/local/bin/aws-nuke`, set that binary as the container entry point, and switch to the unprivileged user. The build stage sets `CGO_ENABLED=0` and compiles `main.go` with stripped symbols and static external-link flags.

A separate Dockerfile stage named `goreleaser` copies a platform-specific binary from the build context into an image based on Alpine. This supports release-image assembly, but the Dockerfile does not document an exact `docker build` tag, `docker run` command, AWS credential mount, or configuration mount. Those operations must come from the current project documentation before an image can be used for teardown.

There is a concrete toolchain mismatch to check when building from source. `go.mod` declares `go 1.26.1`, while the Dockerfile uses `golang:1.21` as its build image. The repository files do not explain how that version gap is handled. A contributor should confirm the supported source-build route rather than treating the checked-in Dockerfile as a verified local build recipe.

The repository includes `cosign.pub` and `.goreleaser.yml`, which indicates a release-signing and packaging setup. The README does not document a signature verification command. It would therefore be inaccurate to prescribe a particular `cosign` invocation without the project's release instructions.

Unsupported resources and aws-nuke deletion failures

The main limitation is stated directly in the README: aws-nuke is stable, but likely does not cover every AWS resource. A run can finish with resources left behind. There is no repository claim that the tool enumerates every resource type in every region.

Authorization can create a second failure boundary. Removing infrastructure often requires different permissions from creating it. A supported resource may be listed but not deleted if the active identity lacks permission, if a service-specific condition blocks the request, or if AWS rejects deletion for that object. The README does not define a minimum IAM policy or fully describe how partial authorization failures appear, so successful discovery is not evidence that removal succeeded.

CloudFormation dependencies are only one part of this problem. Other AWS objects can refer to IAM roles, subnets, security groups, images, KMS keys, databases, or storage resources. The project has not completed a DAG for resource and dependency ordering. That means operators should inspect failures rather than assuming repeated execution is a guaranteed recovery mechanism, although the README does not define retry behavior either.

The Go module includes both AWS SDK Go v1 and selected AWS SDK Go v2 service packages. At the same time, full SDK Go v2 support remains an unchecked project goal. The module dependency list therefore does not prove which resources have completed the migration. Operators using particular services should inspect the corresponding files under `resources/` and verify behavior against a disposable account before relying on it.

The MIT license governs reuse and modification under its terms. Operators should read the repository `LICENSE` and preserve required notices when redistributing binaries or modified code. That observation is not legal advice.

aws-nuke compared with infrastructure-as-code teardown

aws-nuke approaches cleanup through AWS resource discovery and a shared removal engine. This is useful when an account mixes deployment methods, original state files are missing, or the objective is to remove supported resources without reconstructing every CloudFormation stack or Terraform resource definition. Global filters and all-region execution make a single account-wide workflow possible.

The project also documents a fork history from `rebuy-de/aws-nuke`. It states that this fork became a separate maintenance line and that Version 3 was rewritten around libnuke. The README does not provide a feature-by-feature comparison between the two implementations, so lineage alone is not enough for a technical superiority claim.

Release activity and aws-nuke upgrade costs

The repository is not archived. Its last push was on 2026-10-14. The listed releases include v3.68.3 from 2026-10-02, v3.68.2 from 2026-09-21, and v3.68.1 from 2026-09-21. This release cadence and the recent push show continued repository activity, but they do not prove equal coverage or testing for every AWS service.

The `.releasererc.yml` file indicates semantic release configuration, while `mkdocs.yml` and the `docs/` directory support project documentation. Several open goals still affect operators. More resource-specific tests are unfinished, full AWS SDK Go v2 support remains listed as a goal, and the Dockerfile's Go version differs from the `go.mod` declaration. These are concrete maintenance concerns rather than abstract upgrade concerns.

A new release may add AWS resource implementations, alter filters, or change deletion behavior, particularly around CloudFormation. An upgrade is therefore not limited to replacing the binary. Existing filters and account targets should be reviewed against the documentation for the selected version. The README does not document an automatic configuration migration command or promise backward compatibility for every configuration file.

Credentials, filters, selected resources, and account identity determine the operational cost of an incorrect run. Teams that adopt aws-nuke for disposable environments still need to confirm the release's supported resource list and review failures after each run, because unsupported AWS objects will not be removed merely because another service was deleted.

Editorial conclusion

Adopt aws-nuke when an AWS account is disposable or teardown follows an explicit resource inventory and deletion policy. Do not treat it as proof that every AWS resource will disappear, particularly when unsupported services, dependencies, retention controls, or organization-level protections may be present. Before a deletion run, verify the documented resource types, configured filters, enabled regions, AWS account identity, IAM permissions, and CloudFormation hold behavior in the selected release. The repository is not archived, its last push was on 2026-10-14, and its latest listed release is v3.68.3 from 2026-10-02.

Frequently asked questions

Official sources

1. ekristen/aws-nuke on GitHub
2. License: MIT
3. Project website
4. README
5. Releases