Design principles for your multi-account strategy

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.

Topics

• Organize based on security and operational needs
• Apply security guardrails to OUs rather than accounts
• Avoid deep OU hierarchies
• Start small and expand as needed
• Avoid deploying workloads to the organization’s management account
• Separate production from non-production workloads
• Assign a single or small set of related workloads to each production account
• Use federated access to help simplify managing human access to accounts
• Use automation to support agility and scale
• Use multi-factor authentication
• Break glass access

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 instead of 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, refer to 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 accounts, 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, refer to Organizing workload-oriented OUs.

Assign a single or small set of related workloads to each production account

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 by using either IAM Identity Center 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 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 users in your AWS accounts for humans. Instead, use of users can be limited to those exceptional cases such as third-party applications that do not support the use of roles.

For more information about managing identities, refer to 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.

Use multi-factor authentication

Multi-factor authentication (MFA) should be used by your root and all AWS users in your accounts regardless of privilege level or access mechanism. You can follow our current recommendation for MFA best practices for your AWS accounts (management account or member accounts) to set up MFA across your AWS environment.