Design principles for organizing your AWS accounts - Organizing Your AWS Environment Using Multiple Accounts

Design principles for organizing your AWS accounts

The following design principles helped develop the best practices described in this paper. You can also use these principles to help guide your initial account design and evolve it over time.

These design principles complement the Benefits of using multiple accounts and Benefits of using OUs.

Organize based on security and operational needs

We recommend that you organize accounts using OUs based on function, compliance requirements, or a common set of controls rather than mirroring your organization’s reporting structure.

Apply security guardrails to OUs rather than accounts

Where feasible, we recommend that you apply security guardrails, for example SCPs, to OUs rather than accounts so that you can more efficiently manage the distribution of guardrails across accounts that have the same or similar requirements.

For more information about managing security guardrails, see Permissions Management in the AWS Well-Architected Security Pillar.

Avoid deep OU hierarchies

Overly complicated structures can be difficult to understand and maintain. Although AWS Organizations supports a depth of five levels of OUs, the recommended structure strives to use OUs only when there is sufficient benefit.

When you consider the addition of new OU levels, you should review the Benefits of using OUs and these principles to decide whether the additional complexity adds sufficient value.

Start small and expand as needed

We recommend that you review the example Patterns for organizing your AWS accounts, start with a subset of the Recommended OUs, and expand the structure of your AWS accounts when your needs call for the creation of new OUs.

You shouldn’t need to invest a lot of time at the beginning of your adoption journey designing what you expect your AWS account structure will look like in several years.

We provide examples of successive degrees of building out an AWS account structure in Patterns for organizing your AWS accounts.

Avoid deploying workloads to the organization’s management account

Since privileged operations can be performed within an organization’s management account and SCPs do not apply to the management account, we recommend that you limit access to an organization’s management account. You should also limit the cloud resources and data contained in the management account to only those that must be managed in the management account.

Separate production from non-production workloads

We recommend that you separate production workloads from non-production workloads. For overall recommendations on designing this separation, see Organizing workload-oriented OUs.

In support of your production workloads, we recommend that you either assign a single workload to each production account or assign a small set of closely related workloads to each production account.

Consider separating workloads that have different owners into their own production accounts to simplify access management, streamline change approval processes, and limit the scope of impact for misconfigurations.

Use federated access to help simplify managing human access to accounts

We recommend that you use AWS identity federation capabilities via either AWS Single Sign-on (AWS SSO) or IAM integration with a third-party identity provider. These capabilities enable you to use a common identity provider and your existing processes for controlling human user access to your AWS accounts.

By using federated access and a common identity provider, you avoid the need to manage individual IAM users in each account. Instead, your human users can use their existing credentials to access authorized accounts. You also gain the benefit of keeping personally identifiable information (PII) out of IAM.

With federated access, your human users use temporary credentials instead of long term access keys for programmatic access to their AWS environments.

Use of federated access avoids the creation and management of IAM users in your AWS accounts for humans. Instead, use of IAM users can be limited to those exceptional cases such as third-party applications that do not support the use of IAM roles.

For more information about managing identities, see Identity Management in the AWS Well-Architected Security Pillar and Identity federation in AWS.

Use automation to support agility and scale

It is important to design and manage your accounts so that you can rapidly respond to business needs without the need for a corresponding linear increase in headcount. When you consider moving beyond managing just a few accounts, you must consider the work to establish processes and automation that will enable you to do so in an efficient manner.

For example, if you implement an account design in which new business initiatives call for the creation of new accounts, then you will benefit from having automation in place so that you can rapidly and reliably provision environments based on your standard configurations. Automation can also help you monitor compliance and apply updates to your baseline configurations over time.