{"id":6144,"date":"2023-08-18T08:00:00","date_gmt":"2023-08-18T06:00:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=6144"},"modified":"2023-09-01T17:30:31","modified_gmt":"2023-09-01T15:30:31","slug":"clean-up-multiple-aws-accounts-automatic-resources-deletion-with-iot-button","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/clean-up-multiple-aws-accounts-automatic-resources-deletion-with-iot-button\/","title":{"rendered":"Clean up multiple AWS accounts: automatic resources deletion (with IoT button)"},"content":{"rendered":"\n
More and more companies are choosing the Landing Zone approach<\/strong> to their AWS Accounts management. As a result, our work sometimes requires us to work on dozens or, less often, hundreds of AWS accounts simultaneously for a single project. <\/p>\n\n\n\n Not sure what a Landing Zone is? Check out <\/em>our series<\/em><\/a> on it!<\/em><\/p>\n\n\n\n The most recent example was creating a testing environment in our accounts where we had to perform test deployments before deploying to the customer organization. The organization’s size justified this need: almost 400 AWS accounts<\/strong>, so we could not make any mistakes. To mimic their environment, we created an ad-hoc AWS Organization with a dozen accounts with carefully selected resources deployed.<\/p>\n\n\n\n After the work was done, we had to close those accounts, but closing multiple AWS accounts full of resources<\/strong> can be time-consuming. Of course, it must be automated as much as possible!<\/p>\n\n\n\n Closing an account may appear as easy as pressing the “Close” button, but this action has a variety of caveats. Some depend on the account being a standalone<\/strong> account or a member of an AWS Organization<\/strong>; others are common for both account types.<\/p>\n\n\n\n Here is a little cheat sheet of the most important points of attention:<\/p>\n\n\n\n If the account is a member of an AWS Organization, there are even more points of attention:<\/p>\n\n\n\n So, automating the process of closing an AWS Account is not an easy task. <\/p>\n\n\n\n If the accounts are standalone, it probably means they are few in number, so closing them manually is the best choice; it\u2019s not even worth the time to try to automate it!<\/p>\n\n\n\n Instead, in case they are part of an organization, that’s a different story, but, in this case, it won’t be possible to close more than 10% of them per month. Not so efficient…<\/p>\n\n\n\n The most efficient solution to this problem is probably to reuse the accounts, perhaps changing their alias, for another purpose instead of closing them. These accounts can be cleaned up, placed in a specific organizational unit (OU), and used for development or testing.<\/p>\n\n\n\n Another common caveat between both account types is <\/p>\n\n\n\n “When you close your AWS account, you must terminate all your resources, or you might continue to incur charges.”<\/strong>. <\/p>\n\n\n\n That’s frightening!<\/p>\n\n\n\n Let’s explain this part further: when an AWS account is closed, it’s not really<\/em> closed; it’s in the post-closure period<\/em>, a window of 90 days after closing the account. In this period, a user can still sign in to the account, view past billing, pay for AWS bills, and\u2026incur charges. <\/p>\n\n\n\n When an AWS account is closed, the on-demand billing for the resources stops, but some other cost sources are not stopped (e.g., AWS Marketplace subscriptions). So it’s a best practice to delete all resources before closing the account<\/strong>.<\/p>\n\n\n\n AWS recommends two ways of checking for active resources:<\/p>\n\n\n\n These are both valid solutions for finding active resources, but no solution is offered for terminating them automatically.<\/p>\n\n\n\n To solve this issue, we decided to implement a solution as minimal as possible to delete all the resources in one or more AWS accounts.<\/p>\n\n\n\n Of course, most of the work was already done by aws-nuke<\/a>, developed by rebuy; it is an awesome open-source tool that can nuke<\/em> (as in “delete all resources”) an AWS account. Using a YAML config file it is possible to filter some resources to spare or create a blocklist of production accounts that should never be touched. Unfortunately, though, it’s designed to be run on a single AWS account, but we needed a cross-account solution!<\/p>\n\n\n\n The final solution, summarized in the diagram below, is fairly minimal: a CDK template containing just an Amazon S3 Bucket to store the configuration and CodeBuild as the compute part. During the “build” phase, it will parse the configuration searching for the target accounts and run aws-nuke sequentially in every account.<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n Now, why AWS CodeBuild for the compute part? It was preferred for its minimal needs in resources and its managed nature. Here is a summary of the rejected options:<\/p>\n\n\n\nClosing an AWS Account<\/h2>\n\n\n\n
\n
\n
Automatic resources deletion<\/h2>\n\n\n\n
AWS suggested path<\/h3>\n\n\n\n
\n
beSharp-nuke<\/h3>\n\n\n\n
<\/figure><\/div>\n\n\n
\n
Usage<\/h4>\n\n\n\n