aws-nuke

[!CAUTION] This repository for aws-nuke is no longer being actively maintained. We recommend users to switch to the actively maintained fork of this project at ekristen/aws-nuke. We appreciate all the support and contributions we've received throughout the life of this project. We believe that the fork will continue to provide the functionality and support that you have come to expect from aws-nuke. Please note that this deprecation means we will not be addressing issues, accepting pull requests, or making future releases from this repository. Thank you for your understanding and support.

aws-nuke

Remove all resources from an AWS account.

Development Status aws-nuke is stable, but it is likely that not all AWS resources are covered by it. Be encouraged to add missing resources and create a Pull Request or to create an Issue.

Caution!

Be aware that aws-nuke is a very destructive tool, hence you have to be very careful while using it. Otherwise you might delete production data.

We strongly advise you to not run this application on any AWS account, where you cannot afford to lose all resources.

To reduce the blast radius of accidents, there are some safety precautions:

1. By default aws-nuke only lists all nukeable resources. You need to add --no-dry-run to actually delete resources.
2. aws-nuke asks you twice to confirm the deletion by entering the account alias. The first time is directly after the start and the second time after listing all nukeable resources.
3. To avoid just displaying a account ID, which might gladly be ignored by humans, it is required to actually set an Account Alias for your account. Otherwise aws-nuke will abort.
4. The Account Alias must not contain the string prod. This string is hardcoded and it is recommended to add it to every actual production account (eg mycompany-production-ecr).
5. The config file contains a blocklist field. If the Account ID of the account you want to nuke is part of this blocklist, aws-nuke will abort. It is recommended, that you add every production account to this blocklist.
6. To ensure you don't just ignore the blocklisting feature, the blocklist must contain at least one Account ID.
7. The config file contains account specific settings (eg. filters). The account you want to nuke must be explicitly listed there.
8. To ensure to not accidentally delete a random account, it is required to specify a config file. It is recommended to have only a single config file and add it to a central repository. This way the account blocklist is way easier to manage and keep up to date.

Feel free to create an issue, if you have any ideas to improve the safety procedures.

Use Cases

• We are testing our Terraform code with Jenkins. Sometimes a Terraform run fails during development and messes up the account. With aws-nuke we can simply clean up the failed account so it can be reused for the next build.
• Our platform developers have their own AWS Accounts where they can create their own Kubernetes clusters for testing purposes. With aws-nuke it is very easy to clean up these account at the end of the day and keep the costs low.

Releases

We usually release a new version once enough changes came together and have been tested for a while.

You can find Linux, macOS and Windows binaries on the releases page, but we also provide containerized versions on quay.io/rebuy/aws-nuke and docker.io/rebuy/aws-nuke. Both are available for multiple architectures (amd64, arm64 & armv7).

Usage

At first you need to create a config file for aws-nuke. This is a minimal one:

regions:
- eu-west-1
- global

account-blocklist:
- "999999999999" # production

accounts:
  "000000000000": {} # aws-nuke-example

With this config we can run aws-nuke:

…

As we see, aws-nuke only lists all found resources and exits. This is because the --no-dry-run flag is missing. Also it wants to delete the administrator. We don't want to do this, because we use this user to access our account. Therefore we have to extend the config so it ignores this user:

regions:
- eu-west-1

account-blocklist:
- "999999999999" # production

accounts:
  "000000000000": # aws-nuke-example
    filters:
      IAMUser:
      - "my-user"
      IAMUserPolicyAttachment:
      - "my-user -> AdministratorAccess"
      IAMUserAccessKey:
      - "my-user -> ABCDEFGHIJKLMNOPQRST"

…

As you see aws-nuke now tries to delete all resources which aren't filtered, without caring about the dependencies between them. This results in API errors which can be ignored. These errors are shown at the end of the aws-nuke run, if they keep to appear.

aws-nuke retries deleting all resources until all specified ones are deleted or until there are only resources with errors left.

AWS Credentials

There are two ways to authenticate aws-nuke. There are static credentials and profiles. The later one can be configured in the shared credentials file (ie ~/.aws/credentials) or the shared config file (ie ~/.aws/config).

To use static credentials the command line flags --access-key-id and --secret-access-key are required. The flag --session-token is only required for temporary sessions.

To use shared profiles the command line flag --profile is required. The profile must be either defined with static credentials in the shared credential file or in shared config file with an assuming role.

Using custom AWS endpoint

It is possible to configure aws-nuke to run against non-default AWS endpoints. It could be used for integration testing pointing to a local endpoint such as an S3 appliance or a Stratoscale cluster for example.

To configure aws-nuke to use custom endpoints, add the configuration directives as shown in the following example:

…

This can then be used as follows:

…

Specifying Resource Types to Delete

aws-nuke deletes a lot of resources and there might be added more at any release. Eventually, every resources should get deleted. You might want to restrict which resources to delete. There are multiple ways to configure this.

One way are filters, which already got mentioned. This requires to know the identifier of each resource. It is also possible to prevent whole resource types (eg S3Bucket) from getting deleted with two methods.

• The --target flag limits nuking to the specified resource types.
• The --exclude flag prevent nuking of the specified resource types.

It is also possible to configure the resource types in the config file like in these examples:

---
regions:
  - "eu-west-1"
account-blocklist:
- 1234567890

resource-types:
  # only nuke these three resources
  targets:
  - S3Object
  - S3Bucket
  - IAMRole

accounts:
  555133742: {}

---
regions:
  - "eu-west-1"
account-blocklist:
- 1234567890

resource-types:
  # don't nuke IAM users
  excludes:
  - IAMUser

accounts:
  555133742: {}

If targets are specified in multiple places (eg CLI and account specific), then a resource type must be specified in all places. In other words each configuration limits the previous ones.

If an exclude is used, then all its resource types will not be deleted.

Hint: You can see all available resource types with this command:

aws-nuke resource-types

AWS Cloud Control API Support

This feature is not yet released and is probably part of v2.18.

aws-nuke supports removing resources via the AWS Cloud Control API. When executing aws-nuke it will automatically remove a manually managed set of resources via Cloud Control.

Only a subset of Cloud Control supported resources will be removed automatically, because there might be resources that were already implemented and adding them too would bypass existing filters in user configs as Cloud Control has another naming scheme and a different set of properties. Moreover, there are some Cloud Control resources that need special handling which is not yet supported by aws-nuke.

Even though the subset of automatically supported Cloud Control resources is limited, you can can configure aws-nuke to make it try any additional resource. Either via command line flags of via the config file.

For the config file you have to add the resource to theresource-types.cloud-control list:

resource-types:
  cloud-control:
  - AWS::EC2::TransitGateway
  - AWS::EC2::VPC

If you want to use the command line, you have to add a --cloud-control flag for each resource you want to add:

aws-nuke \
    -c nuke-config.yaml \
    --cloud-control AWS::EC2::TransitGateway \
    --cloud-control AWS::EC2::VPC

Note: There are some resources that are supported by Cloud Control and are already natively implemented by aws-nuke. If you configure to use Cloud Control for those resources, it will not execute the natively implemented code for this resource. For example with the --cloud-control AWS::EC2::VPC it will not use the EC2VPC resource.

Feature Flags

There are some features, which are quite opinionated. To make those work for everyone, aws-nuke has flags to manually enable those features. These can be configured on the root-level of the config, like this:

---
feature-flags:
  disable-deletion-protection:
    RDSInstance: true
    EC2Instance: true
    CloudformationStack: true
  force-delete-lightsail-addons: true

Filtering Resources

It is possible to filter this is important for not deleting the current user for example or for resources like S3 Buckets which have a globally shared namespace and might be hard to recreate. Currently the filtering is based on the resource identifier. The identifier will be printed as the first step of aws-nuke (eg i-01b489457a60298dd for an EC2 instance).

Note: Even with filters you should not run aws-nuke on any AWS account, where you cannot afford to lose all resources. It is easy to make mistakes in the filter configuration. Also, since aws-nuke is in continous development, there is always a possibility to introduce new bugs, no matter how careful we review new code.

The filters are part of the account-specific configuration and are grouped by resource types. This is an example of a config that deletes all resources but the admin user with its access permissions and two access keys:

---
regions:
- global
- eu-west-1

account-blocklist:
- 1234567890

accounts:
  0987654321:
    filters:
      IAMUser:
      - "admin"
      IAMUserPolicyAttachment:
      - "admin -> AdministratorAccess"
      IAMUserAccessKey:
      - "admin -> AKSDAFRETERSDF"
      - "admin -> AFGDSGRTEWSFEY"

Any resource whose resource identifier exactly matches any of the filters in the list will be skipped. These will be marked as "filtered by config" on the aws-nuke run.

Filter Properties

Some resources support filtering via properties. When a resource support these properties, they will be listed in the output like in this example:

global - IAMUserPolicyAttachment - 'admin -> AdministratorAccess' - [RoleName: "admin", PolicyArn: "arn:aws:iam::aws:policy/AdministratorAccess", PolicyName: "AdministratorAccess"] - would remove

To use properties, it is required to specify a object with properties and value instead of the plain string.

These types can be used to simplify the configuration. For example, it is possible to protect all access keys of a single user