Cloud Migration Scenarios
Four scenarios to migrate to AWS – from infrastructure to ML
Last month I began on a new assignment. While waiting to get access to the customer’s Cloud environment, I started the work in my own AWS playground account. I made good progress and after a few days I could switch over. As I forgot to destroy the infrastructure, I ended up with a $1700 bill. To avoid this from happening every again, I automatically destroy all resources in my AWS account every day at 23:00 UTC.
The functionality I created is extremely powerful and extremely dangerous. With a single command, you can wipe out entire production environments. So the use of this utility is entirely at your own risk!!!
What is in the stack?
In the core, it runs the aws-nuke utility which destroys all of the resources in your AWS account. The utility is packaged in a CloudFormation stack with the following components:
A CloudWatch event schedules the CodeBuild project to run aws-nuke. aws-nuke destroys all resources in your AWS account. The configuration is stored in a corresponding codecommit repository. I use a CodeBuild project because it is very easy to run a Docker container in it and because the destruction can take a long time. The
aws-nuke.yaml configuration ensures that it does not delete itself.
How do you install it?
To install the automated destructor of AWS accounts, type:
$ git clone https://github.com/binxio/aws-account-destroyer.git $ cd aws-account-destroyer $ bin/deploy ENABLED WARNING: you are about to install the AWS nuke in account 123456789012/mvanholsteijn it will destroy the content of entire 123456789012/mvanholsteijn every day at 23:00, continue yes/no? yes Waiting for changeset to be created.. Waiting for stack create/update to complete
The nuke is now in place, but not yet armed.
How do you arm it?
You arm it by pushing the aws-nuke configuration to the codecommit repository.
Normally when you use aws-nuke on the command line, there are some safeties to avoid accidental destruction of accounts. It will not delete accounts without an alias, it will show you what it will delete and then prompts you to confirm. In this deployment, the manual protection is out of the window.
To keep your job, I recommend to add all AWS accounts you truly care about to the
account-blacklist: # add ALL account id's that you definitely want to keep - account-id-1 - account-id-2 - account-id-3 - ...
The accounts on the blacklist will not be deleted, even if accidentally specified it in the configuration. You can also add your own filters for resources you want to keep around. Ensure that you test the configuration before committing it, using the dry-run option of aws-nuke.
Now you arm the nuke, by pushing the code to the codecommit repository in your target account:
$ git add aws-nuke.yaml.template $ git commit -m 'account blacklist and filters' $ git remote add aws codecommit://$AWS_PROFILE@aws-account-destroyer $ git push -u aws master
Now, every night aws-nuke will destroy every resource in your account across the globe.
The aws-nuke utility is extremely useful to keep the lid on accidental cloud cost. This deployment makes it even more easy to use. But beware: it can just as easily be used to destroy your production account. So use with extreme caution!