In most organizations, a common pattern of using AWS is to have multiple accounts for production, staging, and development. In such a setup, it is inevitable to lose track of various experimental AWS resources instantiated by your developers. Eventually, you are **billed **for these resources; even though this could have been avoided if you were proactively identifying and deleting all such resources.

So, how should you identify and delete such unnecessary resources?

aws-nuke_ to the rescue._

aws-nuke to the rescue

aws-nuke is a tool that removes all resources from an AWS account.

Our organization recently created an internal Jenkins wizard on top of aws-nuke to help developers clean up their AWS accounts. This identified and deleted long-forgotten resources that were instantiated years back for various POCs.

aws-nuke README page does a great job of explaining how to use the tool, and therefore we won’t reinvent the wheel. Rather, I am sharing some of the issues we faced and our learnings from using this tool for over two months now.

---

1. Create an org-wide standard nuke config that allows customization!

aws-nuke uses a YAML configuration file to target and filter resources. Given how destructive this tool is, no developer in their sane mind would like to play with it on their own. Therefore, you must develop a standard configuration for your entire organization.

I can not emphasize enough on the importance of this step. Run, analyze, and verify your standard configuration a thousand times (and a thousand times more) before making it available to your developers.

There will always be a genuine requirement from some developers to save their resources deleted by your standard configuration. Provide a way for them to override the standard configuration.

2. Provide a dry-run option

aws-nuke’s default mode is non-destructive which only prints all the AWS resources that will be deleted when you run the tool in -no-dry-run mode. Your developers need to be able to use this default mode to save some of their resources from deletion if required.

While optional, you might want to parse and format the report which is generated by aws-nuke to make it more readable.

3. AWS credentials to authenticate aws-nuke

This will depend on how your organization set up AWS. After juggling through various approaches, we finally settled down with this approach of using static credentials:

• For each run of the tool, create a new temporary IAM user in the account which is being nuked.
• Provide root access to this temp-IAM-user.
• Ensure your nuke config filters this temp-IAM-user from deletion.
• Generate accessKeyId and secretAccessKey for this temp-IAM-user.
• Pass these static credentials to the aws-nuke tool.
• Delete this temp-IAM-user user after aws-nuke run finishes.

#aws #cost-reduction #devops