aws-samples / aws-nuke-account-cleanser-example Goto Github PK

This is a completely unacceptable default size for a project of this type. It could easily break the bank.

BUILD_GENERAL1_2XLARGE: Use up to 145 GB memory, 72 vCPUs, and 824 GB of SSD storage for builds. This compute type supports Docker images up to 100 GB uncompressed.

Rediculous.

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-codebuild-project-environment.html#cfn-codebuild-project-environment-computetype

I recommend setting it to BUILD_GENERAL1_SMALL

EDIT: LAMBDA wont work because it has a 15min timeout https://aws.amazon.com/blogs/devops/aws-codebuild-adds-support-for-aws-lambda-compute-mode/

👋 First off, thanks for building this project. The mode of delivery is quite clever and perfect for a project I'm working on. As I've tested this out, I've run across an error with this section of the CF stack template:

- |
if [ "$AWS_NukeDryRun" = "true" ]; then
    for file in $(ls nuke_config_$NukeTargetRegion*) ; do aws-nuke -c $file --force --profile nuke 2>&1 |tee -a aws-nuke.log; done
elif [ "$AWS_NukeDryRun" = "false" ]; then
    for file in $(ls nuke_config_$NukeTargetRegion*) ; do aws-nuke -c $file --force --no-dry-run --profile nuke 2>&1 |tee -a aws-nuke.log; done
else
    echo "Couldn't determine Dryrun flag...exiting"
exit 1
fi

This errors out saying that nuke is not a recognized option of aws-nuke. In searching for other reference material, I don't see that option being used or even part of aws-nuke, and removing it gets rid of the error and leads to successful aws-nuke execution. Am I missing something here?

When there are 0 matches from grep it returns an exit status 1 causing CodeBuild to interpret the command as having failed. I've worked around this by adding a || true in the command

cat aws-nuke.log | grep -c " - would remove" || true >> email_template.txt

What would be the best way to handle the Notification template? The job is failing due to the size of the email_template.txt file when publishing the message to SNS.

Is there any specific reason why you use the quite expensive instance type "general1.2xlarge"?
Wouldn't be a smaller instance type sufficient?

When running in non dry run, this stack is nuking itself and deleting its own resources...

It's a bit dumb because this really meet my usecase with the parallel tasking and the mail report, but yea, as of today not perfect and need a little tweeking with role permissions.