arrow-down coffee engineering consultancy development remote-management support linkedin twitter youtube email phone gitlab github

AWS Organizations: the good, the bad, the ugly

Submitted by walterheck on July 25, 2018

As part of the AWS setup we run for the few services we have internally (really not more than a handful) I played around with AWS organizations. This post describes the things I encountered.

AWS organizations

These days, anyone who's interested in running a larger AWS setup will look at a multi-account setup as a way of isolating resources and reducing risks. Once you have more than a few accounts (someone I recently met had 500+ accounts) it becomes harder to manage. Things like consolidated billing are a first step, but quite soon you will want to do more. Things like enabling and disabling specific services for groups of accounts, easily creating a new account from your master account, these are all easier with AWS organizations.
 

Creating new accounts

Creating a new account that is automatically hooked up to the consolidated billing of the organization it belongs to is quite nice. No more need to mess with credit cards, communicate between accounts and click confirmation links to get it set up. Simply log into the master account and create a new sub-account. These days it is even possible with the API 

Access Control Policies

It is possible to control access to the types of services the sub-accounts can access with so-called access control policies. We use this to disable access to some of the really expensive and advanced services that a sub-account doesn't need. If the users of a sub-account run into a situation where they do need to use a specific service we can always enable them later by adding a policy to that account.

These policies are not to be confused with IAM policies as they work on a different level. They basically are applied on top of an account before IAM policies are applied. In practice this can get confusing fast so make sure you document this properly and stick to your own defined way of doing things.

Removing an account from an organization

Now this is where things get a tad..well..messy. There's no way to say "I don't need this account anymore, so delete it from existence". Instead, the only thing you can do is to remove the account from the organization (making it a so-called standalone account) and then closing it manually. This gets complicated fast in itself, I needed AWS support in order to figure out which part was missing. Here's the steps:

  1. Log into the account you wish to remove using the AWS management console
  2. Add a valid credit card as a payment method
  3. To complete the requirements of your AWS account please sign up for the services/support plan here: https://aws-portal.amazon.com/gp/aws/developer/registration/index.html
  4. After that go to the organization and try to remove the account, you should get through no problem
  5. Go to the account that is now standalone and close it if you wish.

Keep in mind that the resources in a closed account don't necessarily get destroyed straight away, that might take up to 60 days.

I really wonder how larger organizations deal with this? If you have any insights please tweet me at @walterheck and I'll be happy to understand more.