AWS Organizations Best Practices

Brett Gillett

Two years ago, I wrote down some thoughts about a strategy for AWS Accounts - it’s been a while and I figured it was time for an update on the topic.

In the original article, I talked about how many of our customers were starting with a single AWS account strategy - all resources, regardless of use in a single AWS account. While this strategy may seem sound at the time, it does have the potential to back you into what I like to call an ‘architectural corner’.

My position remains the same; even if you don’t require multiple accounts right now, I highly recommend starting with a multi-account strategy.

Here’s why.

AWS Organizations

AWS Organizations is a free service meant to help manage multiple AWS accounts. When all features are enabled, it provides you with consolidated billing, organizational structure for your AWS accounts, and the ability to centrally manage certain AWS services from within the Organizations solution.

Even if you don’t envision needing all those features right now, I highly suggest when deploying the service you enable all features - it’s much simpler to turn on all features on day one, rather than having to modify your configuration later.

While AWS Organizations can be managed via the AWS Management Console, its real power lies in the AWS API. Using the API you can automate tasks like account creation, tagging, and deletion to name just a few.


Assuming you enabled all features, you also have the ability to leverage Service Control Policies (SCPs), Tagging Policies, and Backup Policies.

These are JSON documents that allow you to set ‘guard rails’ for all AWS accounts within the organizations or a subset of accounts using Organizational Units (OU).

SCPs act as an ‘extension’ of IAM Policies and allow you to control even the root user - something you can’t do at the account level.

Future Proof

Currently, Organizations supports nineteen AWS services directly. This means once deployed you’re able to centrally manage services like Amazon GuardDuty, AWS CloudTrail, and AWS Config. This simplifies the deployment and on-going management of essential AWS services you should be using across all your AWS accounts.

Over time I suspect you’ll continue to see additional services supported by Organizations.

One note to make here - I suggest holding off using Organizational deployments for services that don’t support ‘delegated administration.’ This feature means you can assign an account within the organization as the administrative account for a specific service.

If ‘delegated administration’ is not supported then the administration happens within the payer account, which may not be what you want.

Reference Architecture

With the benefits of Organizations covered, I’ll share with you a reference architecture we use as part of our JetPack service.

This deployment enables all features in the AWS Organizations service, it also leverages both Service Control Policies (SCPs) and tagging policies to help enforce ‘guard rails’ across your entire deployment.

AWS Organizations - Reference Architecture

NOTE: in the image above I’ve purposed removed SCPs and Tagging policies to make the image easier to read [[ CTA ]]

Brett Gillett


Like what you read? Why not subscribe to the weekly Orbit newsletter and get content before everyone else?