In a previous posting, I went over the importance of setting up AWS Service Control Policies. However, there is a lot of pre-work involved before doing so, and that’s namely with how your AWS Organization is set up. This article is a HOW-TO for how to setup your AWS Organization properly allowing you to deploy services and controls across your AWS Accounts.

Why AWS Organizations? AWS Multi-Account Strategy

If you think your company will never grow past one AWS Account, think again. In fact, if you have only one account account, you are lucky! Nine times out of ten, when I walk into a new AWS environment, there are already tens of accounts yet AWS Organizations is not being taken advantage of.

AWS Organizations allows you the following benefits:

AWS Multi-Account Security Strategy

As mentioned earlier, you will more than likely require multiple AWS Accounts as your company grows, so best to start now. In any case, creating a new account will not add any additional cost, and once you have consolidated billing setup, it should be quite easy.

Below is a summary of AWS Accounts needed for a sound security strategy:

AWS Master Account (required)

This will be the root of your AWS Organization. It’s an account that must be empty of resources. Nine times out of ten the existing master account is the first AWS Account your company created where all your production resources are. Take the time to create a new AWS Account and migrate your billing to that account. See step by step below.

AWS Logging Account

This is an essential account, even before the security account. This is where all your logs will be stored, including your organization trail (CloudTrail enabled at the organization level). This account should have extra security controls and minimal access to ensure the integrity of the logs are maintained. In the future, other system logs may end up here thus the need for a dedicated logging account. Other teams and tools may request access to these logs as well, which is fine, but easier to manage with a dedicated logging account.

AWS Security Account

This is also an essential account. This AWS Account is where your security tooling will be run from. Your AWS security toolset will consist of both AWS Security Tooling, such as GuardDuty, IAM Access Analyzer, AWS Firewall Manager, AWS Security Hub, AWS Macie, and Open Source tooling as well such as CloudMapper, ScoutSuite, and other Open Source Tools (here and here).

AWS Shared Services

I may not know much about your product offerings or workflow, but I can guarantee you that you will more than likely have at least one service that is shared by multiple development teams. It may be your CI/CD tooling, container repository, automation, image building or other tooling that may not be a SaaS based service. For example, you may have golden AMIs for other teams to use in which case you would publish them from this account. Or maybe you have a Service Catalog that you want to publish, you would do it from this account as a delegated administrator account.

Prod / Staging / Dev Accounts

Here is where it gets a little tough, and I will forgive you if you don’t do this right away, but I recommend you have separate AWS Accounts per environment, per application. There are multiple reasons why, but here are a few:

  • Reduce the “blast radius” should something go wrong like accidentally removing an internet gateway, modifying a security group, or if your servers get hacked
  • Having exact configurations for Prod and Staging and using variables such as Terraform Workspaces to ensure a like for like environment
  • Deploying role-based access and utilizing the principle of least privilege, a fundamental concept in securing your accounts.

Now you may say, can’t I just do this all in one account with multiple VPCs – one per environment? My answer: YES! However, in order to ensure the right permissions and segmentation you will likely need to use IAM permissions boundaries to ensure that certain groups don’t have access to certain resources. For example, developers should not have direct access to production, except for admins. In fact, no one really should and all access should be deployed programmatically via Terraform/Github or another means.

Migrating and Setting Up Your AWS Organization Step By Step

This guide assumes you have production resources in your existing Master account and that “emptying” this account will be a large undertaking. Embarking on the steps below will be less work 99% of the time compared to the work involved in actually migrating resources out of an existing Master account.

  1. Create a new AWS Account. This will be your new Master/Root account.
    1. Create the account OUTSIDE your existing organization
    2. If you have an Enterprise account rep, let them know the new account number. You may need to sign a new contract with AWS as well
    3. Setup billing as appropriate
  2. Create an AWS Organization and enable full features. Note the new organization id.
  3. Audit your AWS Accounts, bucket policies, cloudformation, terraform, and boto scripts for any hardcoded values of your organization id. Update any variables to include both the old and new organizations id.
  4. Update the billing info for each AWS Account. You will not be able to detach from the organization otherwise.
  5. Detach existing AWS Accounts from the organization
    1. Read this in its entirety
    2. I suggest starting with test or dev accounts
  6. Invite detached AWS Accounts to you your new organization
    1. Read this in its entirety
  7. Verify that all your member accounts have been migrated
  8. Once verified, in the old master/root account, you can delete the organization. This will make the AWS Account a standalone account.
  9. Invite the remaining AWS Account (old master) into the new AWS organization
  10. Viola! You have now successfully migrated to a proper AWS organization.

Setting Up OU’s In Your AWS Organization

The next step is to logically separate your AWS Accounts into Organizational Units.Creating and OU’s and moving AWS Accounts into them will have no impact at all assuming you have not created any SCPs yet of course. You also have the option of nesting OU’s as needed. SCP’s applied at any level will be applied in any sub-OU’s.

Sample OU Structures

Here are multiple OU layouts to choose from. Choose the one that best suits your environment and work style:

Root

  • Prod OU
  • Staging OU
  • Dev OU

Root

  • Prod OU
  • Non-Prod OU
  • Other OU
  • Test OU

Root

  • Prod OU
    • Shared Services OU
  • Staging OU
  • Dev OU
  • Partner OU

Root

  • Prod OU
  • Staging OU
  • Dev OU
  • Shared Services OU
  • Other OU

OU Definitions In An AWS Organization

Prod OU

This organizational unit is for production AWS Accounts. Any account that has production services belongs here. The strictest security will generally be applied here.

Staging OU

This organizational unit is for staging AWS Accounts. These are typically environments that mimic production in 1:1 fashion, except for staged pushes.

Dev OU

This organizational unit is for staging AWS Accounts. More relaxed AWS Accounts where developers have a lot of creative freedom to test, experiment, and well… develop!

Non-Prod OU

This organizational unit is typically for companies that don’t have a mature multi-staging workflow and so everything is either Prod or Non-Prod. “Non-Prod” may or may not have a clean staging environment, and the dev environment is usually a mess. Feel free here to create sub-OU’s here as needed.

Other/Test OU

This organizational unit is for testing or maybe triaging AWS Accounts into the organization. SCPs may not be applied here or, or maybe a lighter complement of SCPs. The reason is to verify any impact SCPs may have on an AWS Account as they are applied instantly if they exist.

Partner OU

This organizational unit can be for subsidiaries in your organization that you might not have full control over. For example, you might be a large international company and so you have a consolidated billing account to get the biggest discount. This also means that all your AWS Accounts are in your AWS Organization as well. However you might not have direct access to the account or even security authority/responsibility of the account, so you are not in a position to apply SCPs to them. This where this OU comes in. A way to organize the AWS Accounts, so they’re not under root, but otherwise not manage them outside of billing. This is common in large companies with a federated model towards security.

Conclusion

If you followed the above, you now have a clean AWS organization. This will save you lots of time and effort as your company grows. It’s one of the first things I recommend for any company to do and it really applies to companies of all sizes, whether you have one AWS Account or one-hundred! Having a well organized AWS Organization with no resources running in the root AWS Account is essential for applying Service Control Policies in a safe and effective manner.

Did you find this article helpful? Please share or like it if you did. Have a suggestion or comment? Would love to hear from you. Need help figuring our your Cloud Security or getting your team onboard? Let’s talk.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: