aws-nuke v3 teardown issues encountered

[Josersif24]

While using aws-nuke v3.62.2 to tear down a sandbox AWS account, multiple systemic issues were encountered that required architectural workarounds and phased execution. The tool ultimately works, but not reliably in a single pass for large or constrained environments.

1. S3Object listing causes severe performance and memory issues
   Symptoms
   aws-nuke consistently stalls or crashes during the scan phase when S3Object is included.
   In multiple runs, this resulted in:
   Extremely long scan times with no visible progress
   Out-of-memory (OOM) crashes, even on very large instances
   Stack traces indicate the issue occurs in:
   S3ObjectLister.List()

Root cause

• aws-nuke attempts to list and buffer large numbers of S3 objects / versions in memory.
• Versioned buckets significantly amplify this issue.
• There is no streaming or bounded-memory object enumeration.

Mitigation applied

• S3Object was explicitly excluded from aws-nuke configs.

• S3 cleanup was split into a separate phase (or handled outside aws-nuke).

• Outcome

• Excluding S3Object stabilizes scan and delete phases.

• This was the single most impactful fix.

2. EC2 Volumes and Snapshots repeatedly fail and slow execution
Symptoms

aws-nuke logs many:
failed (EC2Volume: …)
failed (EC2Snapshot: …)
Execution appears “stuck” for long periods despite continued background activity.

Root causes

EBS volumes cannot be deleted while still attached to instances.

Volume detach is asynchronous eventually consistent sometimes blocked by instance shutdown delays

Snapshots cannot be deleted whilereferenced by an AMI managed by AWS Backup / recovery points

aws-nuke behavior

aws-nuke attempts best-effort deletion but does not synchronously wait for detach completion

retries failed deletes without strong progress indication

This leads to long retry cycles and perceived hangs.

Mitigation applied

Multiple aws-nuke passes

Manual verification of:attached volumes

AMI → snapshot dependencies

Exclusion or protection of critical AMIs

[ekristen]

Thank you for your feedback. The documentation, our pinned issues, and our default example configurations has S3Object disabled and it will be disabled by default going forward in v4 of the tool (no exact timeline just yet).

As for the rest, you are 100% correct, best effort is made, but there's no direct wait for this dependency. I started on a dependency feature, it's experimental in the docs, but it doesn't work very well, or at least not the way I like.

You are right multiple runs is unfortunately the only way especially when you have very complex AWS environments.

The way the tool works is that it continues to retry a resource until it gets a success OR until we get 3 failures on all failed resources in a row. The tool was built in this way to handle the async blocked operations and retry those that fail due to an attached volume, etc.

I'm unsure on your slow execution, those API calls usually fail pretty quickly and it continues to dive through the list of resources it finds and then starts the loop over again.

Beyond sharing this very detail report, what are you looking for or how can I help?