Organizing your AWS Control Tower landing zone with nested OUs

AWS Control Tower provides the easiest way for you to set up and govern your AWS environment, or landing zone, following prescriptive AWS best practices managed on your behalf. AWS Control Tower orchestrates multiple AWS services (AWS Organizations, AWS CloudFormation StackSets, Amazon S3, AWS Single Sign-On, AWS Config, AWS CloudTrail) to build a landing zone in under 30 minutes, and sets preventive and detective controls (guardrails) that ensure best practices. The release of nested organizational unit (OU) support in AWS Control Tower means you can now follow the “Best practices for Organizational Units with AWS Organizations” and optimize for efficient workload management.

The nested OU feature allows you to group your accounts based on workloads, teams, or products and apply common policies. In this post, we will provide guidance on how to use the new nested OU feature to structure your organization in AWS Control Tower to align with AWS best practices and reduce operational overhead.

Accounts provide a natural method of resource isolation. Placing accounts in OUs and applying guardrails to those OUs provides both a mechanism for grouping accounts into logical units or sub units and provides the opportunity to apply different guardrails to accounts based upon the OU where they reside. The “Organizing AWS Environments Whitepaper” shows several patterns for organizing: by related workloads in an OU, for example, by distinct policy requirements, or by business units. It further recommends that nested OUs reflect the software development lifecycle stages (SDLC), separating pre-production (pre-prod) accounts from production accounts (prod). AWS Control Tower nested OU support now makes it possible to organize your landing zone to align with these best practices and your business’ needs.

When using AWS Control Tower, we recommend that you add an additional nested OU for those OUs that grow into hundreds of accounts. AWS Control Tower operates on OUs as the target for most actions: enabling guardrails, bulk registering accounts, remediating drift, and repairing the landing zone. By controlling OU capacity, you can maintain balance between operational risk tolerance (impacted accounts) versus operational overhead (keeping OUs and accounts up-to-date). We provide more details about this capability in the following sections.

Preparing for Growth

We recommend the basic organization or advanced organization if you are just starting your journey with AWS Control Tower. AWS Control Tower creates the basic organization when you first set up your landing zone, with the “Security” foundational OU and “Sandbox” OU for experimentation. If you are extending AWS Control Tower into an existing organization, register OUs to align with best practices and migrate accounts into your landing zone. Once you’ve set up your basic structure, you can then consider how your organization will grow.

Organizing your Accounts

Now, determine your plan for a particular OU’s account growth: do you create accounts based on workloads, products, or experimentation? Use this and your product and feature roadmap to project the number of accounts you’ll create per OU.

If you project the number of accounts per nested OU to be in the hundreds-to-thousands, then you should use partition OUs to balance your operational risk and operational overhead. AWS Control Tower operates on OUs for governance gestures, but the execution of those gestures results in resources being deployed in individual accounts. The number of accounts in the OU translates into longer registration and repair times for an OU.

We recommend partitioning OUs where you expect hundreds of accounts, like the “Workload” and “Sandbox” OUs. These OUs host services, applications, and individual team test accounts, all of which scale over time as your teams and applications grow. We found that establishing a fixed OU size provides your organization with a predictable registration and update duration, which helps you balance security and operational overhead. The following graphic demonstrates this, with the “Workload” OU containing OUs “Partition_1”, “Partition_2”, “Partition_3”, each containing up to 100 accounts. As each partition fills you would create a new partition to contain the next set of Workload accounts. Using additional nested OUs allows you to apply AWS Control Tower changes across your environment in a uniform manner with lower latency.

Applying policy to your organization

AWS Control Tower provides two types of guardrails to express policy intent: preventive and detective. Enabling preventive guardrails ensures compliance, because they disallow violating actions by using AWS Organizations service control policies (SCPs). Preventive guardrails are inherited down the OU hierarchy, meaning policies apply to children of the OU with the enabled guardrail. Administrators of the landing zone use detective guardrails, deployed as AWS Config rules, to report on adherence to a governance rule, for example detecting whether S3 public access is enabled. Unlike preventive guardrails, these do not inherit down the OU hierarchy.

You should enable preventive guardrails at the top-most OU possible, while enabling detective guardrails on every OU you wish to monitor. Placing the preventive guardrails at the top-most possible OU gives you more room in the nested OUs for more nuanced SCP attachments. You can learn more about SCP inheritance in the AWS Organizations documentation. In contrast, detective guardrails are not inherited. You must enable detective guardrails on every OU you wish to monitor.

Conclusion

The release of nested organizational unit (OU) support in AWS Control Tower means that you can now follow AWS best practices for organizing your accounts. In this post, we also described recommendations for balancing the operational risk and overhead in AWS Control Tower landing zones with an additional nested OU, the partition OU. The recommendations for enabling preventive guardrails at high levels in the OU hierarchy frees SCP attachments for additional nuanced policies. On the other hand, detective guardrails must be enabled on every desired OU. This guidance will help you organize and expand your landing zone, while remaining confident that users of those accounts adhere to your policy requirements.

About the authors