# Identity management and access control for transitioning to a multi-account architecture
<a name="identity-management"></a>

This first step when transitioning to a multi-account architecture is to set up your new account structure within an organization. Then you can add users and configure their access to the accounts. This section describes approaches for managing human access into multiple AWS accounts.

**Topics**
+ [Set up an organization](set-up-organization.md)
+ [Create a landing zone](create-landing-zone.md)
+ [Add organizational units](add-organizational-units.md)
+ [Add initial users](add-initial-users.md)
+ [Manage member accounts](manage-member-accounts.md)

# Set up an organization
<a name="set-up-organization"></a>

When you have multiple AWS accounts, you can logically manage those accounts through an organization in [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html). An *account* in AWS Organizations is a standard AWS account that contains your AWS resources and the identities that can access those resources. An *organization* is an entity that consolidates your AWS accounts so that you can administer them as a single unit.

When you use an account to create an organization, that account becomes the *management account* (also known as a *payer account* or *root account*) for the organization. An organization can only have one management account. When you add additional AWS accounts to the organization, they become *member accounts*.

**Note**  
Each AWS account also has a single identity called the *root user*. You can sign in as the root user by using the email address and password you used to create the account. However, we strongly recommend that you don't use the root user for everyday tasks, even the administrative ones. For more information, see [AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html).  
We also recommend [centralizing root access for member accounts](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-enable-root-access.html) and removing the root user credentials from member accounts in your organization.

You organize accounts in a hierarchical tree-like structure that consists of the organization root, organizational units (OUs), and member accounts. The *root* is the parent container for all of the accounts in your organization. An *organizational unit* (OU) is a container for [accounts](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#account) within the [root](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#root). An OU can contain other OUs or member accounts. An OU can have only one parent, and each account can be a member of only one OU. For more information, see [Terminology and concepts](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) (AWS Organizations documentation).

A [service control policy (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) specifies the services and actions that users and roles can use. SCPs are similar to AWS Identity and Access Management (IAM) permissions policies except that they don't grant permissions. Instead, SCPs define the maximum permissions. When you attach a policy to one of the nodes in the hierarchy, it applies to all the OUs and accounts within that node. For example, if you apply a policy to the root, it applies to all [OUs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#organizationalunit) and [accounts](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#account) in the organization, and if you apply a policy to an OU, it applies to only the OUs and accounts in the target OU.

A [resource control policy (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) offers central control over the maximum available permissions for resources in your organization. RCPs help you make sure that resources in your account stay within your organization’s access control guidelines.

You can use the AWS Organizations console to centrally view and manage all of your accounts within an organization. One of the benefits of using an organization is that you can receive a consolidated bill that shows all charges associated with the management and member accounts. For more information, see [Consolidated billing](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) (AWS Organizations documentation).

## Best practices
<a name="organization-best-practices"></a>
+ Don't use an existing AWS account to create an organization. Start with a new account, which becomes your management account for the organization. Privileged operations can be performed within an organization’s management account, and SCPs and RCPs do not apply to the management account. That’s why you should limit the cloud resources and data contained in the management account to only those that must be managed in the management account.
+ Limit access to the management account to only those individuals who need to provision new AWS accounts and to administer the organization.
+ Use SCPs to define the maximum permissions for the root, organizational units, and member accounts. SCPs can't be directly applied to the management account.
+ Use RCPs to define the maximum permissions for resources in member accounts. RCPs can’t be directly applied to the management account.
+ Adhere to the [Best practices for AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices.html) (AWS Organizations documentation).

# Create a landing zone
<a name="create-landing-zone"></a>

A *landing zone* is a well-architected, multi-account AWS environment that is a starting point from which you can deploy workloads and applications. It provides a baseline to get started with multi-account architecture, identity and access management, governance, data security, network design, and logging. [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) is a service that simplifies the maintenance and governance of a multi-account environment by providing automated guardrails. Typically, you provision a single AWS Control Tower landing zone that manages your environment across all AWS Regions. AWS Control Tower works by orchestrating other AWS services within your account. For more information, see [What happens when you set up a landing zone](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#how-it-works-setup) (AWS Control Tower documentation).

When you set up a landing zone with AWS Control Tower, you identify three shared accounts: the management account, the log archive account, and the audit account. For more information, see [What are the shared accounts](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#what-shared) (AWS Control Tower documentation). For the management account, you must use an existing account that isn't hosting any workloads to set up the landing zone. For the log archive and audit accounts, you can choose to reuse existing AWS accounts, or AWS Control Tower can create them for you.

For instructions about how to set up your AWS Control Tower landing zone, see [Getting started](https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-with-control-tower.html) (AWS Control Tower documentation).

## Best practices
<a name="landing-zone-best-practices"></a>
+ Adhere to the best practices in [Design principles for your multi-account strategy](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/design-principles-for-your-multi-account-strategy.html) (AWS Whitepaper).
+ Adhere to the [Best practices for AWS Control Tower administrators](https://docs.aws.amazon.com/controltower/latest/userguide/best-practices.html) (AWS Control Tower documentation).
+ Create your landing zone in the AWS Region that hosts the majority of your workloads.
**Important**  
If you decide to change this Region after deploying your landing zone, you need the assistance of AWS Support, and you must decommission the landing zone. This practice isn’t recommended.
+ When determining which Regions AWS Control Tower will govern, select only the Regions in which you expect to immediately deploy workloads. You can change these Regions or add more later. If AWS Control Tower governs a Region, it will deploy its detective guardrails into that Region as [AWS Config Rules](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html).
+ After determining which Regions AWS Control Tower will govern, deny access to all ungoverned Regions. This helps ensure that your workloads and developers can only use approved AWS Regions. This is implemented as a service control policy (SCP) in the organization. For more information, see [Configure the AWS Region deny control](https://docs.aws.amazon.com/controltower/latest/userguide/region-deny.html) (AWS Control Tower documentation).
+ When setting up your landing zone in AWS Control Tower, we recommend you rename the following OUs and accounts:
  + We recommend that you rename the **Security** OU to **Security\$1Prod** to signify that this OU will be used for production security-related AWS accounts.
  + We recommend that you allow AWS Control Tower to create an additional OU and then rename it from **Sandbox** to **Workloads**. In the next section, you create additional OUs within the **Workloads** OU, which you use to organize your AWS accounts.
  + We recommend that you rename the centralized logging AWS account from **Log Archive** to **log-archive-prod**.
  + We recommend that you rename the audit account from **Audit** to **security-tooling-prod**.
+ To help prevent fraud, AWS requires that AWS accounts have a history of use before they can be added to an AWS Control Tower landing zone. If you are using a new AWS account without any usage history, in the new account, you can launch an Amazon Elastic Compute Cloud (Amazon EC2) instance that is not in the AWS Free Tier. Let the instance run for a few minutes and then terminate it.

# Add organizational units
<a name="add-organizational-units"></a>

Establishing the proper organization structure is critical to setting up a multi-account environment. Because you use service control policies (SCPs) to define the maximum permissions for an OU and the accounts within it, your organization structure must be logical from a management, permissions, and financial reporting perspective. For more information about the structure of an organization, including organizational units (OUs), see [Terminology and concepts](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) (AWS Organizations documentation).

In this section, you customize the landing zone by creating nested OUs that help you segment and structure your environments, such as production and non-production. These recommended best practices are designed to segment your landing zone to separate production and non-production resources and separate infrastructure from workloads.

For more information about how to create OUs, see [Managing organizational units](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html) (AWS Organizations documentation).

## Best practices
<a name="ou-best-practices"></a>
+ Within the **Workloads** OU that you created in [Create a landing zone](create-landing-zone.md), create the following nested OUs:
  + **Prod** – Use this OU for AWS accounts that store and access production data, including customer data.
  + **NonProd** – Use this OU for AWS accounts that store non-production data, such as development, staging, or testing environments

Under the organization root, create an **Infrastructure\$1Prod** OU. Use this OU to host a centralized networking account.

# Add initial users
<a name="add-initial-users"></a>

There are two ways to grant people access to AWS accounts:
+ IAM identities, such as users, groups, and roles
+ Identity federation, such as by using AWS IAM Identity Center

In smaller companies and single-account environments, it is common for administrators to create an IAM user when a new person joins the company. The access key and secret key credentials associated to an IAM user are known as *long-term credentials* because they don't expire. However, this isn't a recommended security best practice because if an attacker compromised those credentials, you would have to generate a new set of credentials for the user. Another approach for accessing AWS accounts is through [IAM roles](https://aws.amazon.com/blogs/startups/how-setting-up-iam-users-and-iam-roles-can-help-keep-your-startup-secure/). You can also use [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) (AWS STS) to temporarily request *short-term credentials*, which expire after a configurable amount of time.

You can manage people access into your AWS accounts through [IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html). You can create individual user accounts for each of your employees or contractors, they can manage their own passwords and multi-factor authentication (MFA) solutions, and you can group them to manage access. When configuring MFA, you can use software tokens, such as authenticator applications, or you can use hardware tokens, such as YubiKey devices.

IAM Identity Center also supports federation from external identity providers (IdPs) such as Okta, JumpCloud, and Ping Identity. For more information, see [Supported identity providers](https://docs.aws.amazon.com/singlesignon/latest/userguide/supported-idps.html) (IAM Identity Center documentation). By federating with an external IdP, you can manage user authentication across applications and then use IAM Identity Center to authorize access to specific AWS accounts.

## Best practices
<a name="users-best-practices"></a>
+ Adhere to the [Security best practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) (IAM documentation) for configuring user access.
+ Manage account access by groups instead of by individual users. In IAM Identity Center, create new groups that represent each of your business functions. For example, you might create groups for engineering, finance, sales, and product management.
+ Often, groups are defined by separating those who need access to all AWS accounts (often read-only access) and those who need access to a single AWS account. We recommend that you use the following naming convention for groups so that it is easy to identify the AWS account and permissions associated with the group.

  `<prefix>-<account name>-<permission set>`
+ For example, for the group `AWS-A-dev-nonprod-DeveloperAccess`, `AWS-A` is a prefix that indicates access to a single account, `dev-nonprod` is the name of the account, and `DeveloperAccess` is the permission set assigned to the group. For the group `AWS-O-BillingAccess`, the `AWS-O` prefix indicates access to the entire organization, and `BillingAccess` indicates the permission set for the group. In this example, because the group has access to the entire organization, an account name isn't represented in the group name.
+ If you are using IAM Identity Center with an external SAML-based IdP and want to require MFA, you can use attribute-based access control (ABAC) to pass the authentication method from the IdP to IAM Identity Center. The attributes are sent through the SAML assertions. For more information, see [Enable and configure attributes for access control](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html) (IAM Identity Center documentation).

  Many IdPs, such as Microsoft Azure Active Directory and Okta, can use the Authentication Method Reference (`amr`) claim inside a SAML assertion to pass the user’s MFA status to IAM Identity Center. The claim used to assert MFA status and its format varies by IdP. For more information, see the documentation for your IdP.

  In IAM Identity Center, you can then create permission set policies that determine who can access your AWS resources. When you enable ABAC and specify attributes, IAM Identity Center passes the attribute value of the authenticated user to IAM for use in policy evaluation. For more information, see [Create permission policies for ABAC](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac-policies.html) (IAM Identity Center documentation). As shown in the following example, you use the `aws:PrincipalTag` condition key to create an access control rule for MFA.

  ```
  "Condition": {
    "StringLike": { "aws:PrincipalTag/amr": "mfa" }
  }
  ```

# Manage member accounts
<a name="manage-member-accounts"></a>

In this section, you invite your preexisting account into the organization and you begin to create new accounts within your organization. An important part of this process is defining the criteria you use to determine whether you need to provision a new account.

**Topics**
+ [Invite your preexisting account](#invite-account)
+ [Customize VPC settings in AWS Control Tower](#customize-vpc-settings)
+ [Define scoping criteria](#define-scoping-criteria)

## Invite your preexisting account
<a name="invite-account"></a>

Within AWS Organizations, you can invite your company's preexisting account into your new organization. Only the management account in the organization can invite other accounts to join. When the administrator of the invited account accepts, the account immediately joins the organization, and the organization's management account becomes responsible for all charges accrued by the new member account. For more information, see [Inviting an AWS account to join your organization](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html) and [Accepting or declining an invitation from an organization](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html#orgs_manage_accounts_accept-decline-invite) (AWS Organizations documentation).

**Note**  
You can invite an account to join an organization only if that account isn't a currently in another organization. If the account is a member of an existing organization, you must remove it from the organization. If the account is the management account for a different organization that was created in error, you must delete the organization.

**Important**  
If you need access to any historical cost or usage information from your preexisting account, you can use AWS Cost and Usage Report to export that information to an Amazon Simple Storage Service (Amazon S3) bucket. Do this prior to accepting the invitation to join the organization. When an account joins an organization, you lose access to this historical data for the account. For more information, see [Setting up an Amazon S3 bucket for Cost and Usage Reports](https://docs.aws.amazon.com/cur/latest/userguide/cur-s3.html) (AWS Cost and Usage Report documentation).

*Best practices*
+ We recommend that you add your preexisting account, which likely contains production workloads, to the **Workloads** > **Prod** organizational unit that you created in [Add organizational units](add-organizational-units.md).
+ By default, the organization's management account doesn't have administrative access over member accounts that are invited to the organization. If you want the management account to have administrative control, you must create the **OrganizationAccountAccessRole** IAM role in the member account and grant permission to the management account to assume the role. For more information, see [Creating the OrganizationAccountAccessRole in an invited member account](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html#orgs_manage_accounts_create-cross-account-role) (AWS Organizations documentation).
+ For the preexisting account that you invited to the organization, review [Best practices for member accounts](https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html) (AWS Organizations documentation) and confirm that the account adheres to these recommendations.

## Customize VPC settings in AWS Control Tower
<a name="customize-vpc-settings"></a>

We recommend that you provision new AWS accounts through the [Account Factory](https://docs.aws.amazon.com/controltower/latest/userguide/account-factory.html) in AWS Control Tower. By using Account Factory, you can use the AWS Control Tower integration with Amazon EventBridge to provision resources in new AWS accounts as soon as the account is created.

When you set up a new AWS account, a [default virtual private cloud (VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html) is automatically provisioned. However, when you set up a new account through Account Factory, AWS Control Tower automatically provisions an additional VPC. For more information, see [Overview of AWS Control Tower and VPCs](https://docs.aws.amazon.com/controltower/latest/userguide/vpc-concepts.html) (AWS Control Tower documentation). This means that, by default, AWS Control Tower provisions two default VPCs in every new account.

It is common for companies to want more control over the VPCs within their accounts. Many prefer to use other services, such as AWS CloudFormation, Hashicorp Terraform, or Pulumi, to set up and manage their VPCs. You should customize the Account Factory settings to prevent creation of the additional VPC provisioned by AWS Control Tower. For instructions, see [Configure Amazon VPC settings](https://docs.aws.amazon.com/controltower/latest/userguide/configuring-account-factory-with-VPC-settings.html) (AWS Control Tower documentation), and apply the following settings:

1. Disable the **Internet-accessible subnet** option.

1. In **Maximum number of private subnets**, choose **0**.

1. In **Regions for VPC creation**, clear all Regions.

1. In **Availability Zones**, choose **3**.

*Best practices*
+ Delete the default VPC that is automatically provisioned in every new account. This prevents users from launching public EC2 instances in the account without explicitly creating a dedicated VPC. For more information, see [Delete your default subnets and default VPC](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html#deleting-default-vpc) (Amazon Virtual Private Cloud documentation). You can also configure [AWS Control Tower Account Factory for Terraform](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) (AFT) to automatically delete the default VPC in newly created accounts.
+ Provision a new AWS account called **dev-nonprod** into the **Workloads** > **NonProd** organizational unit. Use this account for your development environment. For instructions, see [Provision Account Factory accounts with AWS Service Catalog](https://docs.aws.amazon.com/controltower/latest/userguide/provision-as-end-user.html) (AWS Control Tower documentation).

## Define scoping criteria
<a name="define-scoping-criteria"></a>

You need to select the criteria your company will use when deciding whether to provision a new AWS account. You might decide to provision accounts for each business unit, or you might decide to provision accounts based on environment, such as production, testing, or QA. Every company has their own requirements for how large or small their AWS accounts should be. Generally, you evaluate the following three factors when deciding how to size your accounts:
+ **Balancing service quotas** – *Service quotas* are the maximum values for the number of resources, actions, and items for each AWS service within an AWS account. If many workloads share the same account and one workload is consuming most or all of a service quota, that might negatively impact another workload in the same account. If so, you might need to separate those workloads into different accounts. For more information, see [AWS service quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) (AWS General Reference).
+ **Cost reporting** - Isolating workloads into separate accounts allows you to see costs at an account level in the cost and usage reports. When you use the same account for multiple workloads, you can use tags to help you manage and identify resources. For more information about tagging, see [Tagging AWS resources](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) (AWS General Reference).
+ **Controlling access** - When workloads share an account, you need to consider how you will configure IAM policies to limit access to the account resources so that users don't have access to the workloads they don't need. As an alternative, you can use multiple accounts and [permission sets](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) in IAM Identity Center to manage access into individual accounts.

*Best practices*
+ Adhere to the best practices in [AWS multi-account strategy for your AWS Control Tower landing zone](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html) (AWS Control Tower documentation).
+ Establish an effective tagging strategy that helps you identify and manage AWS resources. You can use tags to categorize resources by purpose, business unit, environment, or other criteria. For more information, see [Best practices for tagging](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html#tag-best-practices) (AWS General Reference documentation).
+ Don't overload an account with too many workloads. If the demand of the workload exceeds a service quota, this can cause performance issues. You can separate the competing workloads into different AWS accounts or you can request a service quota increase. For more information, see [Requesting a quota increase](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) (Service Quotas documentation).