# Govern organizations and accounts with AWS Control Tower
All organizational units (OUs) and accounts that you create in AWS Control Tower are governed automatically by AWS Control Tower. Also, if you have existing OUs and accounts that were created outside of AWS Control Tower, you can bring them into AWS Control Tower governance.
For existing AWS Organizations and AWS accounts, most customers prefer to enroll groups of accounts by registering the entire organizational unit (OU) that contains the accounts. You also can enroll accounts individually. For more information on enrolling individual accounts, see [About enrolling existing accounts](enroll-account.md).
**Terminology**
+ When you bring an existing organization into AWS Control Tower, it's called *registering* the organization, or *extending governance* to the organization.
+ When you bring an AWS account into AWS Control Tower, it's called *enrolling* the account.
**View your OUs and accounts**
On the AWS Control Tower **Organization** page, you can view all the OUs in your AWS Organizations, including OUs that are registered with AWS Control Tower and those that are not registered. You can view nested OUs as part of the hierarchy. An easy way to view your organizational units on the **Organization** page is to select **Organizational units only** from the dropdown at the upper right.
The **Organization** page lists all accounts in your organization, regardless of OU or enrollment status in AWS Control Tower. An easy way to view your accounts on the **Organization** page is to select **Accounts only** from the dropdown at the upper right. You can view, update, and enroll accounts individually within the OUs, if the accounts meet the prerequisites for enrollment.
If you do not select any filtering, the **Organization** page displays your accounts and OUs in a hierarchy. It is a central location for monitoring and taking actions on all of your AWS Control Tower resources. For more information about the **Organization** page, you can view the video walkthrough.
**Note**
When you enable trusted access on the organization that contains your landing zone, AWS Control Tower can create roles, manage resources, and read data for all accounts in the organization. Through trusted access, any account or OU in the organization is available to AWS Control Tower, whether registered and enrolled, or *not* registered and *not* enrolled.
## Video walkthrough
This video (4:01) describes how to work with the **Organization** page in AWS Control Tower. For better viewing, select the icon at the lower right corner of the video to enlarge it to full screen. Captioning is available.
[](http://www.youtube.com/watch?v=FdM6ZyZrHxQ)
## Topics
+ [Register an existing organizational unit with AWS Control Tower](importing-existing.md)
+ [About enrolling existing accounts](enroll-account.md)
+ [Transfer an account to a different organization](account-transfer.md)
# Extend governance to an existing organization
You can add AWS Control Tower governance to an existing organization by setting up a landing zone (LZ) as outlined in the AWS Control Tower User Guide at [Getting Started, Step 2](https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-with-control-tower.html#step-two).
Here's what to expect when you set up your AWS Control Tower landing zone in an existing organization.
+ You can have one landing zone per AWS Organizations organization.
+ AWS Control Tower uses the management account from your existing AWS Organizations organization as its management account. No new management account is needed.
+ AWS Control Tower sets up two new accounts in a registered OU: an audit account and a logging account.
+ Your organization's service limits must allow for the creation of these two additional accounts.
+ After you've launched your landing zone or registered an OU, AWS Control Tower controls apply automatically to all enrolled accounts in that OU.
+ You can **Enroll** additional existing AWS accounts into an OU that's governed by AWS Control Tower, so that controls apply to those accounts.
+ You can add more OUs in AWS Control Tower and you can **Register** existing OUs.
To check other prerequisites for registration and enrollment, see [Getting Started with AWS Control Tower](https://docs.aws.amazon.com//controltower/latest/userguide/getting-started-with-control-tower.html).
Here's more detail about how AWS Control Tower controls **do not** apply to your OUs in AWS organizations that don't have AWS Control Tower landing zones set up:
+ New accounts created outside of AWS Control Tower Account Factory are not bound by the registered OU's controls.
+ New accounts created in OUs that are not registered with AWS Control Tower are not bound by controls, unless you specifically **Enroll** those accounts into AWS Control Tower. See [About enrolling existing accounts](enroll-account.md) for more information about enrolling accounts.
+ Additional existing organizations, existing accounts, and any new OUs or any accounts that you create outside of AWS Control Tower, are not bound by AWS Control Tower controls, unless you separately register the OU or enroll the account.
For more information about how to apply AWS Control Tower to existing OUs and accounts, see [Register an existing organizational unit with AWS Control Tower](importing-existing.md).
For an overview of the process of setting up an AWS Control Tower landing zone in your existing organization, see the video in the next section.
**Note**
During set up, AWS Control Tower performs pre-checks to avoid common issues. However, if you are currently using the AWS Landing Zone solution for AWS Organizations, check with your AWS solutions architect before you try to enable AWS Control Tower in your organization to determine if AWS Control Tower may interfere with your current landing zone deployment. Also, see [If the account does not meet the prerequisites](fulfill-prerequisites.md) for information about moving accounts from one landing zone to another.
## Video: Enable a Landing Zone in existing AWS Organizations
This video (7:48), describes how to set up and enable an AWS Control Tower landing zone in existing AWS Organizations structures. For better viewing, select the icon at the lower right corner of the video to enlarge it to full screen. Captioning is available.
[](http://www.youtube.com/watch?v=CwRy0t8nfgM)
## Considerations for IAM Identity Center and existing organizations
+ If AWS IAM Identity Center (IAM Identity Center) is already set up, the AWS Control Tower home Region must be the same as the IAM Identity Center Region.
+ AWS Control Tower does not delete an existing configuration.
+ If IAM Identity Center is already enabled, and if you are using IAM Identity Center Directory, AWS Control Tower adds resources such as permission sets, groups, and so forth, and proceeds as usual.
+ If another directory (external, AD, Managed AD) is set up, AWS Control Tower does not change the existing configuration. For more details, see [Considerations for AWS IAM Identity Center (IAM Identity Center) customers](getting-started-prereqs.md#sso-considerations).
## Access to other AWS services
After you bring your organization into AWS Control Tower governance, you still have access to any AWS services that are available through AWS Organizations, by means of the AWS Organizations console and APIs. For more information, see [Related AWS services](related-information.md#related-aws-services).
# Nested OUs in AWS Control Tower
This chapter lists the expectations and considerations you'll want to be aware of when working with nested OUs in AWS Control Tower. In most ways, working with nested OUs is the same as working with a flat OU structure. The **Register** and **Re-register** features work with nested OUs, except for the changed behaviors that are noted in this chapter.
## Video Walkthrough
This video (4:46) describes how to manage nested OU deployments in AWS Control Tower. For better viewing, select the icon at the lower right corner of the video to enlarge it to full screen. Captioning is available.
[](http://www.youtube.com/watch?v=zisI5ZNO2kk)
For guidance regarding best practices for nested OUs and your landing zone, see the blog post [Organizing your AWS Control Tower landing zone with nested OUs](https://aws.amazon.com/blogs//mt/organizing-your-aws-control-tower-landing-zone-with-nested-ous/).
## Expand from flat OU structure to nested OU structure
If you created your AWS Control Tower landing zone with a flat OU structure, you can expand it to a nested OU structure.
**This process has four main steps:**
1. Create your desired nested OU structure in AWS Control Tower.
1. Go to the AWS Organizations console and use their bulk move feature to move the accounts from the source OU (flat) into the destination OU (nested). Here’s how:
1. Go to the OU from which you want to move accounts.
1. Select all the accounts in the OU.
1. Choose **Move**.
**Note**
This step must be done in the in AWS Organizations console because AWS Control Tower doesn’t have a **Move** feature.
1. Go to the nested OU in AWS Control Tower and **Register** or **Re-register** it. All of the accounts in the nested OU will be enrolled.
+ If you created the OU in AWS Control Tower, **Re-register** the OU.
+ If you created the OU in AWS Organizations, **Register** the OU for the first time.
1. After your accounts are moved and enrolled, delete the empty top-level OU, either from the AWS Organizations console or from the AWS Control Tower console.
## Nested OU registration pre-checks
To support successful registration of your nested OUs and their member accounts, AWS Control Tower performs a series of pre-checks. These same prechecks are performed when registering any top-level OU or nested OU. For more information, see [Common causes of failure during registration or re-registration](https://docs.aws.amazon.com//controltower/latest/userguide/common-eg-failures.html).
+ If all pre-checks pass, AWS Control Tower begins registering your OU, automatically.
+ If any pre-checks fail, AWS Control Tower stops the registration process and provides you with a list of items that must be fixed before you can register your OU.
## Nested OUs and roles
AWS Control Tower deploys the `AWSControlTowerExecution` role to accounts under the target OU, and to accounts in all OUs nested under the target OU, even when your intention is to register the target OU only. This role gives any user of the management account **Administrator** permissions on any account that has the `AWSControlTowerExecution` role. The role can be used to perform actions that normally would be disallowed by AWS Control Tower controls.
You can delete this role from unenrolled accounts that you don't plan to enroll. If you delete this role, you cannot enroll the account with AWS Control Tower, or register the immediate parent OUs, unless you restore the role to the account. To delete the `AWSControlTowerExecution` role from an account, you must be signed in under the `AWSControlTowerExecution` role, because no other IAM principals are allowed to delete roles managed by AWS Control Tower.
For information about how to restrict role access, see [Optional conditions for your role trust relationships](https://docs.aws.amazon.com/controltower/latest/userguide/conditions-for-role-trust.html).
## What happens during registration and re-registration of nested OUs and accounts
When you register or re-register a nested OU, AWS Control Tower enrolls all unenrolled accounts of the target OU, and it updates all enrolled accounts. Here's what to expect.
**AWS Control Tower performs the following tasks**
+ Adds the `AWSControlTowerExecution` role to all unenrolled accounts under this OU, and to all unenrolled accounts in its nested OUs.
+ Enrolls member accounts that are not enrolled.
+ Re-enrolls enrolled member accounts.
+ Creates an IAM Identity Center login for newly enrolled member accounts.
+ Updates existing enrolled member accounts to reflect your landing zone changes.
+ Updates controls that are configured for this OU and its member accounts.
## Considerations for nested OU registration
+ You cannot register an OU under the core OU (Security OU).
+ Nested OUs must be registered separately.
+ You cannot register an OU unless its parent OU is registered.
+ You cannot register an OU unless all OUs higher in the tree have been registered successfully at some time (some may have been deleted).
+ You can register an OU that is under a drifted higher OU, but the drift is not repaired by that action.
## Nested OU limitations
+ OUs may be nested a maximum of 5 levels deep under the root.
+ Nested OUs under the target OU must be registered or re-registered separately.
+ If the target OU is at Level 2 or below in the hierarchy, that is, if it is not a top-level OU, preventive controls enabled on higher OUs are enforced on this OU and all OUs below it, automatically.
+ OU registration failures do not propagate up the hierarchy tree. You can see details about the states of nested OUs on the parent’s OU details page.
+ OU registration failures do not propagate down the hierarchy tree.
+ AWS Control Tower does not modify your VPC settings for any new or existing accounts.
## Nested OUs and compliance
From the AWS Control Tower console, you can view OUs and accounts that are non-compliant in the **Organization** page, so you can understand compliance at a larger scale.
**Considerations about compliance for nested OUs and accounts**
+ An OU's compliance is not determined based on the compliance of the OUs nested under it.
+ A control's compliance status is computed over all OUs on which the control is enabled, including nested OUs. See [AWS Control Tower compliance status for OUs and accounts](https://docs.aws.amazon.com//controltower/latest/userguide/compliance-statuses.html).
+ An OU is shown as noncompliant only if it has accounts that are noncompliant, regardless of where the OU sits in the OU hierarchy.
+ If a nested OU is noncompliant, its parent OU is not automatically considered to be noncompliant.
+ On the **OU detail** or **Account detail** page, you can view a list of noncompliant resources that may be causing your OUs or accounts to show a non-compliant status.
## Nested OUs and drift
In certain situations, drift can prevent the registration of nested OUs.
**Expectations for drift and nested OUs**
+ You can enable controls on OUs with drifted parents, but not on drifted OUs directly.
+ You are allowed to enable detective controls under a drifted OU, as long as it’s not a top-level drifted OU.
+ Mandatory controls are enabled on top-level OUs only. Mandatory controls are skipped when you register a nested OU.
+ One mandatory control protects AWS Config resources; therefore, that control must be in a non-drifted state to register nested OUs. If drifted, AWS Control Tower blocks registration of nested OUs.
+ If the top-level OU is in drift, the control that protects AWS Config resources may be in drift. In this situation, AWS Control Tower blocks any action that requires creation or update of AWS Config resources, including application of detective controls.
## Nested OUs and controls
When you enable a control on a registered OU, preventive and detective controls have different behaviors. For nested OUs, proactive controls behave similarly to detective controls.
**Preventive controls**
+ Preventive controls are enforced on nested OUs.
+ Mandatory preventive controls are enforced on all accounts under the OU and its nested OUs.
+ Preventive controls affect all accounts and OUs nested under the target OU, even if those accounts and OUs are not registered.
**Detective and proactive controls**
+ Nested OUs do not inherit detective or proactive controls automatically; these must be enabled separately.
+ Detective and proactive controls are deployed only to registered accounts in your landing zone’s operating Regions.
**Enabled control states and inheritance**
You can view inherited controls for each OU, on the **OU details** page.
**Tip**
You can make use of control inheritance to help stay within an OU's SCP quota. For example, you can enable a control at the top-level OU of an OU hierarchy, instead of enabling directly for a nested OU.
**Inherited status**
+ The status **Inherited** indicates that the control is enabled by inheritance only, and it has not been applied directly to the OU.
+ The status **Enabled** means the control is enforced on this OU, regardless of its state on other OUs.
+ The status **Failed** means the control is not enforced on this OU, regardless of its state on other OUs.
**Note**
The status **Inherited** indicates that the control was applied to an OU higher in the tree, and it is enforced on this OU, but it was not added directly to this OU.
**If your landing zone is not the current version**
Each row in the **Enabled controls** table represents one enabled control on one, individual OU.
## Nested OUs and the root
The root is not an OU, and it cannot be registered or re-registered. You also can’t create accounts directly in the root. The root cannot be noncompliant or have a lifecycle state, such as *registered* or *in drift*.
However, the root is the top-level container for all accounts and OUs. In the context of nested OUs, it is the node under which all other OUs are nested.
# Register an existing organizational unit with AWS Control Tower
An efficient way to bring multiple, existing AWS accounts into AWS Control Tower is to *extend governance* by AWS Control Tower to an entire organizational unit (OU).
To enable AWS Control Tower governance over an existing OU that was created with AWS Organizations, and its accounts, *register* the OU with your AWS Control Tower landing zone. You can register OUs that contain up to 1000 accounts. If an OU contains more than 1000 accounts, you cannot register it in AWS Control Tower.
When you register an OU, its member accounts are enrolled into the AWS Control Tower landing zone. They are governed by the controls that apply to their OU.
Starting with Landing Zone version 4.0, you can directly enable controls on an OU. Detective controls require AWS Config recording which can be activated by registering the OU or enabling AWS Config recording on the OU. Register OU will enable `AWSControlTowerBaseline`. Enable AWS Config recording will enable `ConfigBaseline`. For more information, see [Types of baselines](types-of-baselines.md) and [**The AWS Control Tower Controls Reference Guide**](link-to-new-guide.md)
**Note**
If you don't already have an AWS Control Tower landing zone, start by setting up a landing zone, either in a new organization created by AWS Control Tower, or in an existing AWS Organizations organization. For more details about how to set up a landing zone, see [Getting started with AWS Control Tower](getting-started-with-control-tower.md).
**What happens to my accounts when I register my OU?**
AWS Control Tower requires permission to establish trusted access between AWS CloudFormation and AWS Organizations on your behalf, so that AWS CloudFormation can deploy your stack to the accounts in your organization automatically.
+ The `AWSControlTowerExecution` role is added to all accounts with status **Not enrolled**.
+ Mandatory controls are enabled by default to your OU and all its accounts when you register your OU.
**Partial enrollment of accounts after an OU is registered**
It's possible to register an OU successfully, yet certain accounts may remain unenrolled. If so, these accounts do not meet some of the prerequisites for enrollment. If an account enrollment as part of the **Register OU** process does not succeed, the account status on the accounts page shows **Enrollment failed**. You may also see account information on your OU page such as **4 of 5**, in the accounts field.
For example, if you see **4 of 5**, it means that your OU has 5 accounts in total, and 4 of them enrolled successfully, but one account failed to enroll during the **Register OU** process. You can choose **Re-Register OU** to bring accounts into enrollment, after you make sure the accounts meet the enrollment prerequisites.
**IAM user prerequisites for registering an OU**
Your AWS Identity and Access Management (IAM) identity (user or role) or IAM Identity Center user identity must be included on the appropriate Account Factory portfolio when you perform the **Register OU** operation, even if you already have `Admin` permissions. Otherwise, the creation of the provisioned products will fail during registration. Failure occurs because AWS Control Tower relies upon the credentials of the IAM user or IAM Identity Center user identity when registering an OU.
The relevant portfolio is one created by AWS Control Tower, called **AWS Control Tower Account Factory Portfolio**. Navigate to it by choosing **Service Catalog > Account Factory > AWS Control Tower Account Factory Portfolio**. Then select the tab called **Groups, roles, and users** to view your IAM or IAM Identity Center identity. For more information on how to grant access, see [the documentation for AWS Service Catalog.](https://docs.aws.amazon.com//servicecatalog/latest/adminguide/catalogs_portfolios_users.html)
# Register an existing OU
In the AWS Control Tower console, on the **Organization** page, you can view all of of your organization's OUs and accounts in a hierarchy, including OUs that are registered with AWS Control Tower, and those that are not registered.
In general, unregistered OUs were created in AWS Organizations, and they are not governed by any other landing zone. You can register existing OUs that contain up to 1000 accounts. If an OU contains more than 1000 accounts, you cannot register it in AWS Control Tower.
**To register an existing OU from the console**
1. Sign in to the AWS Control Tower console at [https://console.aws.amazon.com/controltower](https://console.aws.amazon.com/controltower).
1. In the left-pane navigation menu, choose **Organization**.
1. On the **Organization** page, select the radio button next to the OU you want to register, then select **Register organizational unit** from the **Actions** dropdown menu at the upper right, or alternatively, select the name of the OU so you can view the **OU details** page for that OU.
1. On the **OU details** page, at the upper right you can select **Register OU** from the **Actions** dropdown menu.
The registration process takes a minimum of 10 minutes to extend governance to the OU, and up to 2 additional minutes for each additional account.
** To register an existing OU with APIs**
To register an existing OU with the AWS Control Tower APIs, you can call the `EnableBaseline` API with the `AWSControlTowerBaseline` in the `baselineIdentifier` field. For more information, see [Register an AWS Control Tower OU with APIs only](https://docs.aws.amazon.com//controltower/latest/userguide/walkthrough-baseline-steps.html).
**Results of registering an existing OU**
After you register an existing OU, the `AWSControlTowerExecution` role allows AWS Control Tower to extend governance to its individual accounts. Guardrails are enforced, and information about account activities is reported to your audit and logging accounts.
Other results include the following:
+ `AWSControlTowerExecution` allows auditing by the AWS Control Tower audit account.
+ `AWSControlTowerExecution` helps you configure your organization’s logging, so that all the logs for every account are sent to the logging account.
+ `AWSControlTowerExecution` ensures that your selected AWS Control Tower controls apply automatically to every individual account in your OUs, as well as to every new account you create in AWS Control Tower.
For a registered OU, you can provide compliance and security reports based on the auditing and logging features embodied by AWS Control Tower controls. Your security and compliance teams can verify that all requirements are met, and that no organizational drift has occurred. For more information about drift, see [Detect and resolve drift in AWS Control Tower](drift.md).
**Note**
One unusual situation can occur when AWS Control Tower displays OUs and their accounts. If you have created an account in a registered OU and then you subsequently move that enrolled account into another OU that’s not registered, particularly if you use AWS Organizations to move the account, you can see a result “1 of 0” accounts in your OU details page. Furthermore, you may have created another unenrolled account in that unregistered OU. If there’s an unregistered account, the console may read “1 of 1” for the OU. It will seem that the single (newly created) account is enrolled, but in fact it is not. You must enroll the new account.
# Create a new OU
Here's how to create an OU or a nested OU in AWS Control Tower.
**To create a new OU in AWS Control Tower**
1. Navigate to the **Organization** page.
1. Select **Create organizational unit** from the **Create resources** dropdown menu in the upper right.
1. Specify a name in the **OU name** field.
1. In the **Parent OU** dropdown, you can see the hierarchy of registered OUs. Select a parent OU for the new OU you’re creating.
1. Choose **Add**.
**Tip**
To add a nested OU in fewer steps, select the name of the parent OU shown in the table on the **Organization** page, view the **OU** page for that parent OU, and then choose **Add an OU** from the **Actions** dropdown menu in the upper right. The new OU is created as a nested OU under your selected OU, automatically.
**Note**
If your landing zone is not up to date, you will see a flat list instead of a hierarchy in the dropdown menu. Even if your landing zone includes nested OUs, you will not see L5 OU’s in the dropdown, because you cannot create a new OU beneath a L5 OU. For more information about nested OUs in AWS Control Tower, see [Nested OUs in AWS Control Tower](nested-ous.md).
# Remove an OU
AWS Control Tower supports separate console actions to *deregister* an OU and to *delete* an OU.
Deleting an OU is final. It cannot be undone.
**Considerations**
+ The OU must be empty of accounts for **Delete** and **Deregister** operations to succeed.
+ All optional controls must be removed from the OU.
+ You must deregister the OU before you delete it.
+ You can remove an OU from AWS Control Tower by deregistering it, without deleting it.
**To remove an OU from AWS Control Tower**
1. Sign in to the AWS Control Tower console at [https://console.aws.amazon.com/controltower](https://console.aws.amazon.com/controltower).
1. Navigate to the **Organization** page.
1. Select the name of the OU to view the **OU details** page, and be sure that all accounts are removed from the OU.
1. Also on the **OU details** page, be sure that all optional controls are removed from the OU.
1. Return to the **Organization** page and select the radio button next to the OU.
1. Select **Deregister organizational unit** from the **Actions** dropdown menu in the upper right.
1. **Stop here** if you do not wish to delete the OU entirely, only to deregister it from AWS Control Tower. To delete the OU completely, continue to the next step.
1. To continue, select **Delete** from the **Actions** dropdown menu in the upper right.
You must wait until the deregistration process is complete before you can deregister another OU.
**Note**
To remove accounts managed by AWS Control Tower, you can navigate to **Account factory** from the left navigation pane in the AWS Control Tower console. To remove accounts in the OU that are not managed by AWS Control Tower, go to the AWS Organizations console.
To deregister an OU programmatically, call the [`DisableBaseline` API](https://docs.aws.amazon.com//controltower/latest/APIReference/API_DisableBaseline.html).
# Common causes of failure during registration or re-registration
In general, when you register or re-register an OU, all accounts within that OU are enrolled in AWS Control Tower. However, it is possible that some accounts may fail to enroll, even if the OU as a whole is registered successfully. In these cases, you must resolve the pre-check failure related to the account and then try re-enrolling that account or OU.
If registration (or re-registration) of an OU or any of its member accounts fails, AWS Control Tower returns error messages for the member accounts that are affected. You can view the error messages on the **OU details** page, where a table aggregates the prechecks and account error messages. If a **Register OU ** operation fails, the table shows all of the error messages for all of the accounts under the OU. If needed, you also can view the error messages on the **Account details** page for each account.
Optionally, you can download a file containing a detailed report that shows which pre-checks did not pass, for offline analysis. You can complete the download by choosing the **Download** button, which appears at the upper right of the registration area.
This section lists the types of errors you may receive if pre-checks fail, and how to correct the errors.
**Landing Zone error**
+ **Landing zone not ready**
Reset your current landing zone, or update it to the latest version.
**OU errors**
+ **Exceeds maximum number of SCPs**
You may be over the limit for service control policies (SCPs) per OU, or you may have reached another quota. A limit of 5 SCPs per OU applies to all OUs in your AWS Control Tower landing zone. If you have more SCPs than the quota allows, you must delete or combine the SCPs.
+ **Conflicting SCPs**
Existing SCPs may be applied to the OU or account, which prevent AWS Control Tower from enrolling the account. Check the applied SCPs for any policy that may prevent AWS Control Tower from working. Be sure to check the SCPs that are inherited from OUs higher in the hierarchy.
+ **Exceeds stack set quota**
The stack set quota may have been exceeded. If you have more instances than the quota allows, you must delete some stack instances. For more information, see [AWS CloudFormation quotas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cloudformation-limits.html) in the *AWS CloudFormation User Guide*.
+ **Exceeds account limit**
AWS Control Tower limits each OU to 1000 accounts during registration.
**Account errors**
+ **Pre-checks prevented on accounts**
An existing SCP on the OU prevents AWS Control Tower from conducting pre-checks on your OU member accounts. To resolve this pre-check failure, update or remove the SCP from the OU.
+ **Email address error**
The email address you specified for the account does not conform to the naming standards. Here is the regular expression (regex) that specifies which characters are allowed: `[A-Z0-9a-z._%+-]+@[A-Za-z0-9.-]+[.]+[A-Za-z]+`
+ **Config recorder or delivery channel enabled**
The account may have an existing AWS Config configuration recorder or delivery channel. These must be deleted or modified through the AWS CLI in all AWS Regions where the AWS Control Tower management account has governed resources, before you can enroll an account.
+ **STS disabled**
AWS Security Token Service (AWS STS) may be disabled in the account. AWS STS endpoints must be activated in the accounts for all Regions supported by AWS Control Tower.
+ **IAM Identity Center conflict**
The AWS Control Tower home Region is not the same as the AWS IAM Identity Center (IAM Identity Center) Region. If IAM Identity Center is already set up, the AWS Control Tower home region must be the same as the IAM Identity Center Region.
+ **Conflicting SNS topic**
The account has an Amazon Simple Notification Service (Amazon SNS) topic name that AWS Control Tower needs to use. AWS Control Tower creates resources (such as SNS topics) with specific names. If these names are already taken, AWS Control Tower setup fails. This situation could occur if you are reusing an account previously enrolled in AWS Control Tower.
+ **Suspended account detected**
This account has been suspended. It cannot be enrolled into AWS Control Tower. Remove the account from this OU, and try again.
+ **IAM user not in portfolio**
Add the AWS Identity and Access Management (IAM) user to the Service Catalog portfolio before registering your OU. This error pertains to the management account only.
+ **Account does not meet prerequisites**
The account doesn’t meet prerequisites for account enrollment. For example, the account may be missing roles and permissions required to enroll it in AWS Control Tower. Instructions for adding a role are available in [Manually add the required IAM role to an existing AWS account and enroll it](enroll-manually.md).
As a reminder, AWS CloudTrail is auto-enabled on all of your AWS accounts when you enroll them in AWS Control Tower. If CloudTrail is enabled on an account previous to enrollment, you could experience double-billing unless you deactivate CloudTrail before you begin the enrollment process.
# Update organizations
The quickest way to update an organizational unit (OU) or to update multiple accounts within an OU is to perform one of the following actions:
+ Re-register the OU if `AWSControlTowerBaseline` is enabled.
+ Reset enabled baselines or reset enabled controls if `AWSControlTowerBaseline` is not enabled.
# When to update AWS Control Tower OUs and accounts
When you perform a landing zone update, you must update your enrolled accounts to apply new controls to those accounts.
+ You can perform an update to all accounts under an OU using the Re-Register or Reset option.
+ If you have more than one registered OU in your landing zone, re-register or reset all of your OUs to update all of your accounts.
+ To update a single account, you can update from the AWS Control Tower console, or you can select the **Update provisioned product** option in AWS Service Catalog if AWSControlTowerBaseline is enabled on the account. See [Update the account in the console](updating-account-factory-accounts.md#update-account-in-console).
# Update multiple accounts in the same OU
Repeat these steps for each OU in your AWS Control Tower organization, if you need to update all of your accounts and OUs.
**To update multiple accounts in one OU, with one action**
1. Sign in to the AWS Control Tower console at [https://console.aws.amazon.com/controltower](https://console.aws.amazon.com/controltower).
1. In the left-pane navigation menu, choose **Organization **.
1. On the **Organization** page, choose any OU to view the **OU details** page.
1. If AWSControlTowerBaseline is enabled on the OU, select **Re-Register OU** under **Actions**. If AWSControlTowerBaseline is not enabled on the OU, select **Reset AWS Config baseline** under **Actions** to reset enabled baseline and select enabled controls and **Reset control** under "Enabled controls" section to reset enabled controls.
Alternatively, you can select any account that shows a status of **Update available** and then choose **Update account**, for as many accounts as needed.
## What happens during re-registration
**When you re-register an OU:**
+ The **State** field indicates whether the account currently is enrolled with AWS Control Tower (**Enrolled**), whether the account has never been enrolled (**Not enrolled**), or whether enrollment failed previously (**Enrollment failed**).
+ When you re-register the OU, the `AWSControlTowerExecution` role is added to all accounts with status **Not enrolled** or **Enrollment failed**.
+ AWS Control Tower creates a single sign-on (IAM Identity Center) login for those new enrolled accounts.
+ **Enrolled** accounts are re-enrolled into AWS Control Tower.
+ Drift on any preventive controls applied to the OU is fixed, because the SCPs are returned to their default definitions.
+ All accounts are updated to reflect the latest landing zone changes.
For more information, see [About enrolling existing accounts](enroll-account.md).
**Tip**
When you re-register an OU, or when you're updating your landing zone version and multiple member accounts, you may see a failure message mentioning the **StackSet-AWSControlTowerExecutionRole**. This StackSet in the management account can fail because the **AWSControlTowerExecution** IAM role already exists in all enrolled member accounts. This error message is expected behavior, and it can be disregarded.
# Update a single account
**Note**
Single account provision, update and customization must target an organizational unit (OU) with AWSControlTowerBaseline enabled. If an OU does not have the AWSControlTowerBaseline enabled, you can activate account auto-enrollment or use ResetEnabledBaseline and ResetEnabledControl APIs on EnabledBaselines and EnabledControls on that OU to enroll accounts. For details of AWSControlTowerBaseline, see: [Baseline types that apply at the OU level](types-of-baselines.md#ou-baseline-types).
You can update individual AWS Control Tower accounts in the AWS Control Tower console, or in the Service Catalog console.
To update a single account in the AWS Control Tower console, see [Update the account in the console](updating-account-factory-accounts.md#update-account-in-console).
**To update a single account in AWS Service Catalog**
1. Go to AWS Service Catalog.
1. In the left-pane navigation menu, choose **Provisioned products**.
1. On the **Provisioned products** page, select the radio button next to the provisioned product you want to update.
1. In the upper right, choose the **Actions** dropdown to **Update**.
To learn more about updating in AWS Service Catalog, see [Update the provisioned product in Service Catalog](update-provisioned-product.md) and [Updating products](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/productmgmt-update.html) in the *Service Catalog Administrator Guide*.
# Transfer an account to a different organization
You can transfer a member account that is enrolled in AWS Control Tower to a different AWS Organizations organization.
## Prerequisites
+ The account must be enrolled in AWS Control Tower in the source organization. That is, the account has baselines, proactive controls, or detective controls applied to it.
+ The account must have been created at least 4 days before the transfer.
+ You must have access to the management account of both the source and destination organizations.
## Step 1: Unenroll the account from AWS Control Tower
Before you transfer the account, you must disable all AWS Control Tower resources directly applied to it. The account can continue to inherit preventive controls.
**If you use Auto Enroll**
Move the account to one of the following locations:
+ The root of the organization
+ An unmanaged OU
+ With Landing Zone 4.0 or later, an OU that has only preventive controls enabled
**If you don't use Auto Enroll**
The methods below are also available if you use Auto Enroll.
+ For accounts with the AWS Control Tower and Backup baseline, choose **Unmanage** from the AWS Control Tower console. You can also terminate the provisioned product with the AWS Service Catalog APIs or console.
+ For accounts with the AWS Config baseline, disable the AWS Config baseline on the OU, or move the account to root and use the `DisableBaseline` API.
## Step 2: Transfer the account to the destination organization
After all AWS Control Tower baselines and controls applied to the account other than preventive controls are disabled, complete the transfer.
1. From the management account of the destination organization, send an invitation to the member account.
1. Accept the invitation from the member account.
1. From the management account of the destination organization, move the account to the desired OU.
For instructions on the migration process, see [Migrating AWS accounts to a different organization](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_account_migration.html) in the *AWS Organizations User Guide*.
## Step 3: Enroll the account in the destination organization
After the account is in the destination organization, enroll it in AWS Control Tower.
+ If Auto Enroll is enabled in the AWS Control Tower landing zone that governs the destination organization, AWS Control Tower automatically applies baselines and controls to the account.
+ If you don't use Auto Enroll in the destination organization, manually enroll the account in AWS Control Tower. For more information, see [About enrolling existing accounts](enroll-account.md).
## Additional considerations
Wait period
Accounts created through AWS Organizations or Account Factory must be at least 4 days old before you can transfer them or remove them from an organization. For more information, see [Removing a member account from an organization](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_remove.html) in the *AWS Organizations User Guide*.
AWS Config aggregator limits
When you transfer multiple accounts, you might reach the AWS Config limit for the maximum number of accounts added or deleted per week for all aggregators (1,000). To request a limit increase, see [AWS Config service limits](https://docs.aws.amazon.com/config/latest/developerguide/configlimits.html). You can also upgrade to landing zone version 4.0, which uses a service-linked Config aggregator. For more details, see [AWS Config updates in landing zone version 4.0](https://docs.aws.amazon.com/controltower/latest/userguide/config-updates-v4.html).
Member account access
Unenrolled accounts don't have an `AWSControlTowerExecution` role. When you disable the Config or AWS Control Tower baseline, AWS Control Tower deletes its execution role and adds the `OrganizationsAccountAccessRole`. You can use this role to accept an invitation for the destination organization.
When the account is enrolled in the destination organization, the `AWSControlTowerExecution` role is created. This role replaces the `OrganizationsAccountAccessRole` and trusts the new management account.
AWS Service Catalog and Auto Enroll
Auto Enroll doesn't act on resources in AWS Service Catalog. Any Account Factory provisioned products remain in the management account even if the underlying accounts are unenrolled. To terminate these provisioned products in the management account, see [Deleting provisioned products](https://docs.aws.amazon.com/servicecatalog/latest/userguide/enduser-delete.html) in the *AWS Service Catalog User Guide*. Any Account Factory Customization (AFC) blueprints remain in the account.