AWS Account Creation Automation & Security

It’s been a busy couple of years so, as is usual, my blog was left to languish. That doesn’t mean I’ve not done interesting and challenging things in the interim. Things worth blogging about. So here we are. This is an expansion on one of the topics I briefly covered at my AWS London Summit talk earlier this year.

In my last role, I administered something north of 110 AWS accounts for the company. That was, more or less, one account per product environment. All products had at least two accounts, dev and prod, and some had as many as fifteen.

As you might imagine, consistency was the key to administering them, and one of my biggest non-customer-facing projects for the company was to apply that consistency to the initially haphazard pile of accounts that we had at the beginning of the project.

Consistency starts from the ground up, so to prevent more randomness creeping into the new accounts we created during and after the project, my team and I created a simple set of bash scripts using the aws-cli tools and CloudFormation to create and instantiate our accounts prior to handing them over to the dev teams.

Sample scripts are available on my GitHub:

They leverage the AWS Organizations API via the aws-cli tool to create, configure and initialise the new account based on a neat trick: when you create an AWS account via the Organizations tools, behind the scenes an invisible IAM admin role is created in your new account that only IAM users with the appropriate permissions in the parent account can assume. This allows, without needing to create new IAM roles or users, the script to assume the admin role in the created account in order to perform the initial configuration needed.

So for example if, as is sensible, you do not use static IAM credentials to access your accounts, but use an SSO service or some other centrally managed user configuration tool, you can create the required roles, stacks, Lambdas, CloudWatch metrics etc for the user access tool without needing to login to the console of the new account at all.

It also allows you to enable any Organizations Service Control Policies that you routinely apply to your accounts, e.g. preventing Cloudtrail disablement or access to certain services.

The automation is flexible and extensible enough to allow you to set up other default configuration for consistency purposes: centralised logging for Cloudtrail, Cloudwatch or your own services, GuardDuty for security purposes, IAM password policies and instance roles, standard VPCs & subnets, Route 53 zones, S3 buckets etc etc. All of which will aid in your consistency efforts.