How To Set Up AWS Organizations For Success

How To Set Up AWS Organizations For Success

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

Table of Contents

1. Why AWS Organizations? AWS Multi-Account Strategy
2. AWS Multi-Account Security Strategy
3. Migrating and Setting Up Your AWS Organization Step By Step
4. Setting Up OUs In Your AWS Organization
5. Conclusion

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, 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:

• Organize your AWS Accounts into OUs where you can apply Service Control Policies to multiple AWS Accounts
• Take advantage of the “Delegate Administrator” feature available in the growing list of AWS Security Services that are Organizations compatible such as AWS GuardDuty and IAM Access Analyzer
• Automatically enable security tooling for all new AWS Accounts, such as with an organizational trail or GuardDuty’s auto-enable feature.

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 a 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 logs’ integrity is 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, which is fine.

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 as CloudMapper, ScoutSuite, and other Open Source Tools (check out 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 another 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 publish; in that case, you would do that 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 that 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 a server gets hacked, fewer applications will get affected
• 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 ask, “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, only admins should have direct access to production, although no one really should since 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 than 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.
2. Create the account OUTSIDE your existing organization
3. 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
4. Setup billing as appropriate
5. Create an AWS Organization and enable full features. Note the new organization id
6. Audit your AWS Accounts, bucket policies, cloud formation, terraform, and boto scripts for any hardcoded values of your organization id. Update any variables to include both the old and new organizations’ id
7. Update the billing info for each AWS Account. You will not be able to detach from the organization otherwise.
8. Detach existing AWS Accounts from the organization
9. Read this in its entirety
10. I suggest starting with test or dev accounts
11. Invite detached AWS Accounts to you your new organization
12. Read this in its entirety
13. Verify that all your member accounts have been migrated
14. Once verified, in the old master/root account, you can delete the organization. This will make the AWS Account a standalone account
15. Invite the remaining AWS Account (old master) into the new AWS organization
16. Viola! You have now successfully migrated to a proper AWS organization.

Setting Up OUs In Your AWS Organization

The next step is to logically separate your AWS Accounts into Organizational Units. Creating OUs 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 OUs as needed. SCPs applied at any level will be applied in any sub-OUs.

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-OUs 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 the security authority/responsibility of the account, so you are not in a position to apply SCPs to them.

This where this OU comes in: it’s a way to organize the AWS Accounts so they’re not under root nor 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 safely and effectively.

If this article was helpful to you, consider subscribing to my weekly newsletter, where I share my latest commentary as a vCISO for high growth startups.

Check out how we help startups accelerate and level up their security programs through vCISO (CISO As A Service).

‍