# Detect and resolve drift in AWS Control Tower
Identifying and resolving drift is a regular operations task for AWS Control Tower management account administrators. Resolving drift helps to ensure your compliance with governance requirements.
When you create your landing zone, the landing zone and all the organizational units (OUs), accounts, and resources are compliant with the governance rules enforced by your chosen controls. As you and your organization members use the landing zone, changes in this compliance status may occur. Some changes may be accidental, and some may be made intentionally to respond to time-sensitive operational events.
Drift detection assists you in identifying resources that need changes or configuration updates to resolve the drift.
## Detecting drift
AWS Control Tower detects drift automatically. To detect drift, the `AWSControlTowerAdmin` role requires persistent access to your management account so AWS Control Tower can make read-only API calls to AWS Organizations. These API calls show up as AWS CloudTrail events.
Drift for a member account is surfaced in the Amazon Simple Notification Service (Amazon SNS) notifications that are aggregated in the audit account. Notifications in each member account send alerts to a local Amazon SNS topic, and to a Lambda function.
**Note**
When the auto-enroll capability for accounts is enabled in **Settings**, these SNS notifications are not available.
For controls that are part of the AWS Security Hub CSPM **Service-Managed Standard: AWS Control Tower**, drift is shown on the **Account** and **Account details** pages in the AWS Control Tower console, as well as by means of an Amazon SNS notification.
Member account administrators can (and as a best practice, they should) subscribe to the SNS drift notifications for specific accounts. For example, the `aws-controltower-AggregateSecurityNotifications` SNS topic provides drift notifications. The AWS Control Tower console indicates to management account administrators when drift has occurred. For more information about SNS topics for drift detection and notification, see [Drift prevention and notification](https://docs.aws.amazon.com//controltower/latest/userguide/prevention-and-notification.html).
**Drift notification de-duplication**
If the same type of drift occurs on the same set of resources multiple times, AWS Control Tower sends an SNS notification only for the initial instance of drift. If AWS Control Tower detects that this instance of drift has been remediated, it sends another notification only if drift re-occurs for those identical resources.
**Example: SCP drift is handled in the following manner**
+ If you modify the same managed SCP multiple times, you receive a notification for the first time you modify it.
+ If you modify a managed SCP, then remediate drift, then modify it again, you'll receive two notifications.
**Types of account drift**
+ Account moved between OUs (see *[Inheritance drift on enabled baselines](governance-drift.md#drift-enabled-baseline)* and [Inheritance drift on enabled controls](governance-drift.md#drift-enabled-controls))
+ Account removed from organization
**Note**
When you move an account from one OU to another, the controls from the previous OU are not removed. If you enable any new hook-based control on the destination OU, the old
hook-based control is removed from the account, and the new control replaces it. Controls implemented with SCPs and AWS Config rules always must be removed manually when an account changes OUs.
**Examples of policy drift**
+ SCP updated
+ SCP detached from OU
For more information, see [Types of Governance Drift](https://docs.aws.amazon.com/controltower/latest/userguide/governance-drift.html).
# Viewing drift
You can view the drift status for your accounts and OUs through the console or APIs, and identify when account and OU configurations are *drifted*, or out of sync. Drift status also is communicated with SNS messages. For more information about receiving these SNS messages, see [Guidance on subscribing to SNS Topics](https://docs.aws.amazon.com//controltower/latest/userguide/sns-guidance.html).
To view OU and account drift status in the console, navigate to the **Organization** page, and then select the OUs or accounts that you wish to inspect.
To view drift status for OUs and accounts programmatically, call the [https://docs.aws.amazon.com//controltower/latest/APIReference/API_ListEnabledBaselines.html](https://docs.aws.amazon.com//controltower/latest/APIReference/API_ListEnabledBaselines.html) API to view statuses for your enabled baselines. To view statuses for individual accounts programmatically with the `ListEnabledBaselines` API, use the `includeChildren` flag. You can filter by these statuses, and see only the accounts and OUs that require your attention.
**Note**
AWS Control Tower generates a [lifecycle event](https://docs.aws.amazon.com//controltower/latest/userguide/lifecycle-events.html) when each drift remediation operation is completed.
# Resolving drift
Although detection is automatic, the steps to resolve drift must be done manually through the console, or with the APIs. (Except in certain cases when auto-enroll is enabled for accounts that are moved.)
For example, you can resolve policy drift for controls programmatically, by calling the [https://docs.aws.amazon.com//controltower/latest/APIReference/API_ResetEnabledControl.html](https://docs.aws.amazon.com//controltower/latest/APIReference/API_ResetEnabledControl.html) API.
To resolve *configuration baseline drift* for an OU, you can choose **Re-register OU** in the console. If the drift is caused by a single account, you can choose **Update account** in the console. To resolve baseline drift with the APIs, you can call the [https://docs.aws.amazon.com//controltower/latest/APIReference/API_ResetEnabledBaseline.html](https://docs.aws.amazon.com//controltower/latest/APIReference/API_ResetEnabledBaseline.html) API on the OU.
**Summary**
+ Many types of drift can be resolved through the **Landing zone settings** page. You can choose the **Reset** button in the **Versions** section to resolve these types of drift.
+ If your OU has fewer than 1000 accounts, you can resolve drift in Account Factory provisioned accounts, or SCP drift, by selecting **Re-register OU** on the **Organization** page or the **OU details** page.
+ You may be able to resolve account drift, such as [Moved member account](governance-drift.md#drift-account-moved), by updating an individual account. For more information, see [Update the account in the console](updating-account-factory-accounts.md#update-account-in-console).
+ For controls, many types of drift can be resolved by calling the [`ResetEnabledControl` API.](https://docs.aws.amazon.com//controltower/latest/APIReference/API_ResetEnabledControl.html)
+ Baseline drift on OUs and accounts can be resolved by calling the [https://docs.aws.amazon.com//controltower/latest/APIReference/API_ResetEnabledBaseline.html](https://docs.aws.amazon.com//controltower/latest/APIReference/API_ResetEnabledBaseline.html) API, or by choosing **Re-register OU** or **Update account** in the AWS Control Tower console.
+ To resolve *inheritance drift* that occurs when accounts are moved between OUs, you can enable the auto-enrollment feature. When auto-enrollment is enabled, AWS Control Tower automatically remediates inheritance drift by applying the baseline resources and control configurations from the destination OU to the moved account. You can enable auto-enrollment on the landing zone **Settings** page in the console, or by calling the [https://docs.aws.amazon.com//controltower/latest/APIReference/API_UpdateLandingZone.html](https://docs.aws.amazon.com//controltower/latest/APIReference/API_UpdateLandingZone.html) API with the `RemediationType` parameter set to **Inheritance Drift**. For more information, see [Move and enroll accounts with auto-enrollment](account-auto-enrollment.md).
**When you take action to resolve drift on a landing zone version, the behavior depends on your current version.**
If you are on landing zone version 3.1 or above, you can choose **Update** to change your landing zone configuration without upgrading versions, or choose **Reset** to reapply your saved configurations to your drifted landing zone resources. Drift is resolved as part of the update process.
If you are on a landing zone version earlier than 3.1, you cannot choose **Reset**. You must choose **Update** and upgrade your landing zone to at least version 3.1.
## Considerations about drift and policy scans
AWS Control Tower scans your managed SCPs, RCPs, and Declarative policies daily to verify that the corresponding controls are applied correctly and that they have not drifted. To retrieve these resources and run checks on them, AWS Control Tower calls AWS Organizations on your behalf, using a role in your management account.
If an AWS Control Tower scan discovers drift, you'll receive a notification. AWS Control Tower sends only one notification per drift issue, so if your landing zone already is in a state of drift, you won't receive additional notifications unless a new drift item is found.
AWS Organizations limits how often each of its APIs can be called. This limit is expressed in transactions per second (TPS), and known as the *TPS limit*, *throttling rate*, or *API request rate*. When AWS Control Tower audits your SCPs, RCPs, and Declarative policies by calling AWS Organizations, the API calls that AWS Control Tower makes are counted towards your TPS limit, because AWS Control Tower uses the management account to make the calls.
In rare situations, this limit can be reached when you call the same APIs repeatedly, whether through a third-party solution or a custom script you wrote. For example, if you and AWS Control Tower call the same AWS Organizations APIs at the same moment in time (within 1 second), and the TPS limits are reached, subsequent calls are throttled. That is, these calls return an error such as `Rate exceeded`.
**If an API request rate is exceeded**
+ If AWS Control Tower hits the limit and is throttled, we pause the execution of the audit and resume it at a later time.
+ If your workload hits the limit and is throttled, the result can range from slight latency all the way to a fatal error in the workload, depending on how the workload is configured. This edge case is something to be aware of.
**A daily SCP scan consists of**
1. Retrieving your recently active OUs.
1. For each registered OU, retrieving all SCPs managed by AWS Control Tower that are attached to the OU. Managed SCPs have identifiers that begin with `aws-guardrails`.
1. For each preventive control enabled on the OU, verifying that the control's policy statement is present in the OU's managed SCPs.
An OU may have one or more managed SCPs.
## Types of drift to resolve right away
Most types of drift can be resolved by administrators. A few types of drift must be resolved immediately, including deletion of an organizational unit that the AWS Control Tower landing zone requires. Here are some examples of major drift that you may wish to avoid:
+ *Don't delete the Security OU:* The organizational unit originally named **Security** during landing zone setup by AWS Control Tower should not be deleted. If you delete it, you'll see an error message instructing you to reset the landing zone immediately. You won't be able to take any other actions in AWS Control Tower until the reset is complete.
+ *Don't delete required roles:* AWS Control Tower checks certain AWS Identity and Access Management (IAM) roles when you log into the console for *IAM role drift*. If these roles are missing or inaccessible, you'll see an error page instructing you to reset your landing zone. These roles are `AWSControlTowerAdmin` `AWSControlTowerCloudTrailRole` `AWSControlTowerStackSetRole`.
For more information about these roles, see [Permissions Required to use the AWS Control Tower console](additional-console-required-permissions.md).
+ *Don't delete all Additional OUs:* At least one Additional OU is required for AWS Control Tower to operate, but it doesn’t have to be the **Sandbox** OU.
+ *Don't remove shared accounts:* If you remove shared accounts from Foundational OUs with the AWS Organizations console or APIs, such as removing the logging account from the Security OU. Moving these accounts creates a type of **Move Account **drift that must be remediated. To remediate this type of drift, you must update the landing zone.
**Note**
As a best practice, do not move these shared accounts out of the Foundational OU.
## Repairable changes to resources
Here's a list of changes to AWS Control Tower resources that are permitted, although they create *resolvable drift*. Results of these permitted operations are viewable in the AWS Control Tower console, although a refresh may be required.
For more information about how to resolve the resulting drift, see [Managing Resources Outside of AWS Control Tower](https://docs.aws.amazon.com//controltower/latest/userguide/external-resources.html).
**Changes permitted outside the AWS Control Tower console**
+ Change the name of a registered OU.
+ Change the name of the Security OU.
+ Change the name of member accounts in non-Foundational OUs.
+ Change the name of AWS Control Tower shared accounts in the Security OU.
+ Delete a non-Foundational OU.
+ Delete an enrolled account from a non-Foundational OU.
+ Change the email address of a shared account in the Security OU.
+ Change the email address of a member account in a registered OU.
**Note**
Moving accounts between OUs is considered drift, and it must be resolved.
## Drift and new account provisioning
If your landing zone is in a state of drift, the **Enroll account** feature in AWS Control Tower will not work. In that case, you must provision new accounts through AWS Service Catalog. For instructions, see [Provision accounts in the Service Catalog console, with Account Factory](provision-as-end-user.md).
In particular, if you've made certain changes to your accounts by means of Service Catalog, such as changing the name of your portfolio, the **Enroll account** feature will not work.
# Types of governance drift
Governance drift, also called *organizational drift* occurs when OUs, SCPs, and member accounts are changed or updated. The types of governance drift that can be detected in AWS Control Tower are as follows:
+ Account and OU governance drift
+ Landing zone drift
+ Control drift for non-SCP controls
+ Inheritance drift for baselines and controls
The next sections provide detail about these types of drift that AWS Control Tower reports, and how to resolve them.
**Note**
AWS Control Tower will stop sending drift notifications to SNS topic for LZ4.0\$1 customers and will start sending drift notifications to EventBridge in the management account instead. To see sample events and guidance on how to receive drift notifications through EventBridge please see the section below on **EventBridge creation**.
**Account and OU governance drift**
+ [Moved member account](#drift-account-moved)
+ [Removed member account](#drift-account-removed)
+ [Unplanned update to managed SCP](#drift-scp-update)
+ [SCP detached from managed OU](#drift-scp-detached-ou)
**Landing zone drift**
Another type of drift is *landing zone drift*, which may be found through the management account. Landing zone drift consists of IAM role drift, or any type of organizational drift that specifically affects Foundational OUs and shared accounts.
+ [Deleted Foundational OU](#drift-ou-deleted)
+ [Trusted access disabled](#drift-disable-trust)
A special case of landing zone drift is *role drift*, which is detected when a required role is not available. If this type of drift occurs, the console displays a warning page and some instructions on how to restore the role. Your landing zone is unavailable until the role drift is resolved. For more information about role drift, see *Don't delete required roles* in the section called [Types of drift to resolve right away](drift.md#types-of-drift).
**Control drift for non-SCP controls**
AWS Control Tower reports *control drift* regarding controls implemented with resource control policies (RCPs), declarative policies and controls that are part of the **AWS Security Hub CSPM Service-managed Standard: AWS Control Tower**.
+ [Security Hub CSPM control drift](#sh-control-drift)
+ [Control policy drift](#control-policy-drift)
**Inheritance drift for baselines and controls**
+ **Enabled baseline drift**
When baseline configurations on a member account are different than those applied to the parent OU, AWS Control Tower reports inheritance drift for enabled baselines (resource configurations) on those OUs and accounts. For more information about baselines, see [Types of baselines](https://docs.aws.amazon.com//controltower/latest/userguide/types-of-baselines.html).
+ [Inheritance drift on enabled baselines](#drift-enabled-baseline)
+ **Enabled control drift**
When enabled control configurations on a member account are different than those applied to the parent OU, AWS Control Tower reports inheritance drift for enabled controls on those OUs and accounts.
+ [Inheritance drift on enabled controls](#drift-enabled-controls)
**Drift that is not reported**
AWS Control Tower does not look for drift regarding other services that work with the management account, including AWS CloudTrail, Amazon CloudWatch, IAM Identity Center, CloudFormation, AWS Config, and so forth.
AWS Control Tower does not detect resource drift or other kinds of drift that may happen if you modify the resources contained in a baseline.
## Moved member account
**Note**
For customers on LZ 4.0\$1, AWS Control Tower will not send move account drift notifications for Account Factory accounts without AWSControlTowerBaseline.
This type of drift occurs on the account rather than the OU. This type of drift can occur when an AWS Control Tower member account, the audit account, or the log archive account is moved from a registered AWS Control Tower OU to any other OU. In many cases, you can avoid this type of drift if you activate the auto-enrollment feature for accounts, on the **Settings** page. For more details, see [Move and enroll accounts with auto-enrollment](account-auto-enrollment.md).
The following is an example of the drift notification when this type of drift is detected.
```
{
"Message" : "AWS Control Tower has detected that your member account 'account-email@amazon.com (012345678909)' has been moved from organizational unit 'Sandbox (ou-0123-eEXAMPLE)' to 'Security (ou-3210-1EXAMPLE)'. For more information, including steps to resolve this issue, see 'https://docs.aws.amazon.com/console/controltower/move-account'",
"ManagementAccountId" : "012345678912",
"OrganizationId" : "o-123EXAMPLE",
"DriftType" : "ACCOUNT_MOVED_BETWEEN_OUS",
"RemediationStep" : "Re-register this organizational unit (OU), or if the OU has more than 1000 accounts, you must update the provisioned product in Account Factory.",
"AccountId" : "012345678909",
"SourceId" : "012345678909",
"DestinationId" : "ou-3210-1EXAMPLE"
}
```
### Resolutions
When this type of drift occurs for an Account Factory provisioned account in an OU with up to 1000 accounts, you can resolve it by:
+ Navigating to the **Organization** page in the AWS Control Tower console, selecting the account, and choosing **Update account** at the upper right (fastest option for individual accounts).
+ Navigating to the **Organization** page in the AWS Control Tower console, then choosing **Re-register** for the OU that contains the account (fastest option for multiple accounts). For more information, see [Register an existing organizational unit with AWS Control Tower](importing-existing.md).
+ Updating the provisioned product in Account Factory. For more information, see [Update and move accounts with AWS Control Tower](updating-account-factory-accounts.md).
**Note**
If you have several individual accounts to update, also see this method for making updates with a script: [Provision and update accounts using automation](update-accounts-by-script.md).
+ When this type of drift occurs in an OU with more than 1000 accounts, the drift resolution may depend on which type of account has been moved, as explained in the next paragraphs. For more information, see [Update your landing zone](update-controltower.md).
+ **If an Account Factory provisioned account is moved** – In an OU with fewer than 1000 accounts, you can resolve the account drift by updating the provisioned product in Account Factory, by re-registering the OU, or by updating your landing zone.
In an OU with more than 1000 accounts, you *must* resolve the drift by making an update to each moved account, either through the AWS Control Tower console or the provisioned product, because **Re-register OU** will not perform the update. For more information, see [Update and move accounts with AWS Control Tower](updating-account-factory-accounts.md).
+ **If a shared account is moved** – You can resolve the drift from moving the audit or log archive account by updating your landing zone. For more information, see [Update your landing zone](update-controltower.md).
**Deprecated field name**
The field name `MasterAccountID` has been changed to `ManagementAccountID` to comply with AWS guidelines. The old name is **deprecated**. Since 2022, scripts that contain the deprecated field name no longer work.
## Removed member account
This type of drift can occur when a member account is removed from a registered AWS Control Tower organizational unit. The following example shows the drift notification when this type of drift is detected.
```
{
"Message" : "AWS Control Tower has detected that the member account 012345678909 has been removed from organization o-123EXAMPLE. For more information, including steps to resolve this issue, see 'https://docs.aws.amazon.com/console/controltower/remove-account'",
"ManagementAccountId" : "012345678912",
"OrganizationId" : "o-123EXAMPLE",
"DriftType" : "ACCOUNT_REMOVED_FROM_ORGANIZATION",
"RemediationStep" : "Add account to Organization and update Account Factory provisioned product",
"AccountId" : "012345678909"
}
```
### Resolution
+ When this type of drift occurs in a member account, you can resolve the drift by updating the account in the AWS Control Tower console, or in Account Factory. For example, you can add the account to another registered OU from the Account Factory update wizard. For more information, see [Update and move accounts with AWS Control Tower](updating-account-factory-accounts.md).
+ If a shared account is removed from a Foundational OU, you must resolve the drift by resetting your landing zone. Until this drift is resolved, you will not be able to use the AWS Control Tower console.
+ For more information about resolving drift for accounts and OUs, see [If you manage resources outside of AWS Control Tower](external-resources.md).
**Note**
In Service Catalog, the Account Factory provisioned product that represents the account is not updated to remove the account. Instead, the provisioned product is displayed as `TAINTED` and in an error state. To clean up, go to the Service Catalog, choose the provisioned product, and then choose **Terminate**.
## Unplanned update to managed SCP
This type of drift can occur when an SCP for a control is updated in the AWS Organizations console or programmatically using the AWS CLI or one of the AWS SDKs. The following is an example of the drift notification when this type of drift is detected.
```
{
"Message" : "AWS Control Tower has detected that the managed service control policy 'aws-guardrails-012345 (p-tEXAMPLE)', attached to the registered organizational unit 'Security (ou-0123-1EXAMPLE)', has been modified. For more information, including steps to resolve this issue, see 'https://docs.aws.amazon.com/console/controltower/update-scp'",
"ManagementAccountId" : "012345678912",
"OrganizationId" : "o-123EXAMPLE",
"DriftType" : "SCP_UPDATED",
"RemediationStep" : "Update Control Tower Setup",
"OrganizationalUnitId" : "ou-0123-1EXAMPLE",
"PolicyId" : "p-tEXAMPLE"
}
```
### Resolution
When this type of drift occurs in an OU with up to 1000 accounts, you can resolve it by:
+ Navigating to the **Organization** page in the AWS Control Tower console to re-register the OU (fastest option). For more information, see [Register an existing organizational unit with AWS Control Tower](importing-existing.md).
+ Updating your landing zone (slower option). For more information, see [Update your landing zone](update-controltower.md).
When this type of drift occurs in an OU with more than 1000 accounts, resolve it by updating your landing zone. For more information, see [Update your landing zone](update-controltower.md).
## SCP detached from managed OU
This type of drift can occur when an SCP for a control has been detached from an OU that's managed by AWS Control Tower. This occurrence is especially common when you're working from outside of the AWS Control Tower console. The following is an example of the drift notification when this type of drift is detected.
```
{
"Message" : "AWS Control Tower has detected that the managed service control policy 'aws-guardrails-012345 (p-tEXAMPLE)' has been detached from the registered organizational unit 'Sandbox (ou-0123-1EXAMPLE)'. For more information, including steps to resolve this issue, see 'https://docs.aws.amazon.com/console/controltower/scp-detached'",
"ManagementAccountId" : "012345678912",
"OrganizationId" : "o-123EXAMPLE",
"DriftType" : "SCP_DETACHED_FROM_OU",
"RemediationStep" : "Update Control Tower Setup",
"OrganizationalUnitId" : "ou-0123-1EXAMPLE",
"PolicyId" : "p-tEXAMPLE"
}
```
### Resolution
When this type of drift occurs in an OU with up to 1000 accounts, you can resolve it by:
+ Navigating to the OU in the AWS Control Tower console to re-register the OU (fastest option). For more information, see [Register an existing organizational unit with AWS Control Tower](importing-existing.md).
+ Updating your landing zone (slower option). If the drift is affecting a mandatory control, the update process creates a new service control policy (SCP) and attaches it to the OU to resolve the drift. For more information about how to update your landing zone, see [Update your landing zone](update-controltower.md).
When this type of drift occurs in an OU with more than 1000 accounts, resolve it by updating your landing zone. If the drift is affecting a mandatory control, the update process creates a new service control policy (SCP) and attaches it to the OU to resolve the drift. For more information about how to update your landing zone, see [Update your landing zone](update-controltower.md).
## Deleted Foundational OU
This type of drift applies only to AWS Control Tower Foundational OUs, such as the Security OU. It can occur if a Foundational OU is deleted outside of the AWS Control Tower console. Foundational OUs cannot be moved without creating this type of drift, because moving an OU is the same as deleting it and then adding it someplace else. When you resolve the drift by updating your landing zone, AWS Control Tower replaces the Foundational OU in the original location. The following example shows a drift notification you may receive when this type of drift is detected.
```
{
"Message" : "AWS Control Tower has detected that the registered organizational unit 'Security (ou-0123-1EXAMPLE)' has been deleted. For more information, including steps to resolve this issue, see 'https://docs.aws.amazon.com/console/controltower/delete-ou'",
"ManagementAccountId" : "012345678912",
"OrganizationId" : "o-123EXAMPLE",
"DriftType" : "ORGANIZATIONAL_UNIT_DELETED",
"RemediationStep" : "Delete organizational unit in Control Tower",
"OrganizationalUnitId" : "ou-0123-1EXAMPLE"
}
```
### Resolution
Because this drift occurs for Foundational OUs only, the resolution is to update the landing zone. When other types of OUs are deleted, AWS Control Tower is updated automatically.
For more information about resolving drift for accounts and OUs, see [If you manage resources outside of AWS Control Tower](external-resources.md).
## Security Hub CSPM control drift
This type of drift occurs when a control that's part of the **AWS Security Hub CSPM Service-Managed Standard: AWS Control Tower** reports a state of drift. The AWS Security Hub CSPM service itself does not report a state of drift for these controls. Instead, the service sends its findings to AWS Control Tower.
Security Hub CSPM control drift also can be detected if AWS Control Tower has not received a status update from Security Hub CSPM in more than 24 hours. If those findings are not received as expected, AWS Control Tower verifies that the control is in drift. The following example shows a drift notification you may receive when this type of drift is detected.
```
{
"Message" : "AWS Control Tower has detected that an AWS Security Hub control was removed in your account example-account@amazon.com . The artifact deployed on the target OU and accounts does not match the expected template and configuration for the control. This mismatch indicates that configuration changes were made outside of AWS Control Tower. For more information, view Security Hub standard",
"MasterAccountId" : "123456789XXX",
"ManagementAccountId" : "123456789XXX",
"OrganizationId" : "o-123EXAMPLE",
"DriftType" : "SECURITY_HUB_CONTROL_DISABLED",
"RemediationStep" : "To remediate the issue, Re-register the OU, or remove the control and enable it again. If the problem persists, contact AWS support.",
"AccountId" : "7876543219XXX",
"ControlId" : "SH.XXXXXXX.1",
"ControlName" : "EBS snapshots should not be publicly restorable",
"ApiControlIdentifier" : "arn:aws:controltower:us-east-1::control/PYBETSAGNUZB",
"EnabledControlIdentifier": "arn:aws:controltower:us-east-1::enabledcontrol/".
"Region" : "us-east-1"
}
```
### Resolution
For OUs with fewer than 1000 accounts, the recommended resolution is to call the **ResetEnabledControl** API for the drifted control. In the console, you can select **Re-register** for the OU, which resets the control to the original state. Alternatively, for any OU, you can remove and re-enable the control through the console or the AWS Control Tower APIs, which also resets the control.
For more information about resolving drift for accounts and OUs, see [If you manage resources outside of AWS Control Tower](external-resources.md).
## Control policy drift
This type of drift occurs when a control that's implemented with *resource control policies* (RCPs) or *declarative policies* reports a state of drift. It returns a state of `CONTROL_INEFFECTIVE`, which you can view in the AWS Control Tower console and in the drift message. The drift message for this type of drift also includes the `EnabledControlIdentifier` for the affected control.
This type of drift is not reported for SCP-based controls.
The following example shows a drift notification you may receive when this type of drift is detected.
```
{
"Message": "AWS Control Tower detects that a policy it owns was updated unexpectedly. This mismatch indicates that configuration changes were made outside of AWS Control Tower.",
"MasterAccountId": "123456789XXX",
"ManagementAccountId": "123456789XXX",
"OrganizationId": "o-123EXAMPLE",
"DriftType": "CONTROL_INEFFECTIVE",
"RemediationStep": "To remediate the issue, Reset the DRIFTED enabled control if permitted or Re-register the OU. If the problem persists, contact AWS support.",
"TargetIdentifier": "arn:aws:::organizations/o-123456/ou-1234-4567",
"ControlId": "CT.XXXXXXX.PV.1",
"ControlName": "EBS snapshots should not be publicly restorable",
"ApiControlIdentifier": "arn:aws:controlcatalog:::control/",
"EnabledControlIdentifier": "arn:aws:controltower:us-east-1::enabledcontrol/"
}
```
### Resolution
The easiest resolution for control policy drift on RCP controls, declarative policy controls, and Security Hub CSPM controls enabled in AWS Control Tower is to call the `ResetEnabledControl` API.
For OUs with fewer than 1000 accounts, another resolution from the console or API is to **Re-register** the OU, which resets the control to the original state.
For any individual OU, you can remove and re-enable the control through the console or the AWS Control Tower APIs, which also resets the control.
For more information about resolving drift for accounts and OUs, see [If you manage resources outside of AWS Control Tower](external-resources.md).
## Trusted access disabled
This type of drift applies to AWS Control Tower landing zones. It occurs when you disable trusted access to AWS Control Tower in AWS Organizations after you set up your AWS Control Tower landing zone.
When trusted access is disabled, AWS Control Tower no longer receives change events from AWS Organizations. AWS Control Tower relies on these change events to stay synchronized with AWS Organizations. As a result, AWS Control Tower may miss organizational changes in accounts and OUs. That is why it is important to re-register each OU, each time you update your landing zone.
**Example: drift notification**
The following is an example of the drift notification that you receive when this type of drift occurs.
```
{
"Message" : "AWS Control Tower has detected that trusted access has been disabled in AWS Organizations. For more information, including steps to resolve this issue, see https://docs.aws.amazon.com/controltower/latest/userguide/drift.html#drift-trusted-access-disabled",
"ManagementAccountId" : "012345678912",
"OrganizationId" : "o-123EXAMPLE",
"DriftType" : "TRUSTED_ACCESS_DISABLED",
"RemediationStep" : "Reset Control Tower landing zone."
}
```
### Resolution
AWS Control Tower notifies you when this type of drift occurs in the AWS Control Tower console. The resolution is to reset your AWS Control Tower landing zone. For more information, see [Resolving drift](https://docs.aws.amazon.com/controltower/latest/userguide/drift.html#resolving-drift).
## Inheritance drift on enabled baselines
This type of drift can occur to AWS Control Tower OUs and accounts.
### Resolution
AWS Control Tower notifies you when this type of drift occurs. For almost all cases of inheritance drift, you will receive a drift notification for *Moved member account* drift. That's because this type of drift typically occurs when an account has been moved, or an account fails enrollment.
**View and resolve drift in the console**
In the AWS Control Tower console, you can view this inherited drift status in the **Baseline state** column on the **Organizations** page. The resolution from the console is to **Re-register** your OU or **Update** your account.
**View and resolve drift programmatically**
To view drift status programmatically, you can call the [https://docs.aws.amazon.com//controltower/latest/APIReference/API_ListEnabledBaselines.html](https://docs.aws.amazon.com//controltower/latest/APIReference/API_ListEnabledBaselines.html) API to view statuses for the enabled baselines on your OUs. To view statuses for individual accounts programmatically with the `ListEnabledBaselines` API, use the `includeChildren` flag.
You can resolve this type of drift programmatically, by calling the [https://docs.aws.amazon.com//controltower/latest/APIReference/API_ResetEnabledBaseline.html](https://docs.aws.amazon.com//controltower/latest/APIReference/API_ResetEnabledBaseline.html) API.
## Inheritance drift on enabled controls
This type of drift can occur to AWS Control Tower OUs and accounts.
### Resolution
AWS Control Tower notifies you when this type of drift occurs. For almost all cases of inheritance drift, you will receive a drift notification for *Moved member account* drift. That's because this type of drift typically occurs when an account has been moved, or an account fails enrollment.
**View and resolve drift in the console**
In the AWS Control Tower console, you can view this inherited drift status in the **Organizations** page, the **Enabled controls** page, and the **Account details** page. The resolution from the console is to **Re-register** your OU or **Update** your account.
**View and resolve drift programmatically**
To view inherited drift status for enabled controls programmatically, you can call the [https://docs.aws.amazon.com//controltower/latest/APIReference/API_ListEnabledControls.html](https://docs.aws.amazon.com//controltower/latest/APIReference/API_ListEnabledControls.html) API to view statuses for the enabled controls on your OUs. To view statuses for individual accounts programmatically with the `ListEnabledControls` API, use the `includeChildren` flag.
You can resolve this type of inheritance drift programmatically, by calling the [https://docs.aws.amazon.com//controltower/latest/APIReference/API_ResetEnabledControl.html](https://docs.aws.amazon.com//controltower/latest/APIReference/API_ResetEnabledControl.html) API.
## EventBridge creation
**Note**
EventBridge is enabled for LZ4.0\$1 customers only.
Example EventBridge format for AWS Control Tower
```
{
"version": "0",
"id": "cd4d811e-ab12-322b-8255-872ce65b1bc8",
"detail-type": "Drift Detected",
"source": "aws.controltower",
"account": "111122223333",
"time": "2018-03-22T00:38:11Z",
"region": "us-east-1",
"resources": [],
"detail": {
"message" : "AWS Control Tower has detected that your member account 'account-email@amazon.com (012345678909)' has been moved from organizational unit 'Sandbox (ou-0123-eEXAMPLE)' to 'Security (ou-3210-1EXAMPLE)'. For more information, including steps to resolve this issue, see 'https://docs.aws.amazon.com/console/controltower/move-account'",
"managementAccountId" : "012345678912",
"organizationId" : "o-123EXAMPLE",
"driftType" : "ACCOUNT_MOVED_BETWEEN_OUS",
"remediationStep" : "Re-register this organizational unit (OU), or if the OU has more than 1000 accounts, you must update the provisioned product in Account Factory.",
"accountId" : "012345678909",
"sourceId" : "012345678909",
"destinationId" : "ou-3210-1EXAMPLE"
}
}
```
Guidance to create EventBridge rule to receive drift notifications:
**To create an EventBridge rule for drift notifications**
1. Open the **Amazon EventBridge Console**:
1. In the navigation pane, choose **Rules**.
1. Choose **Create rule**.
1. Enter a name and description for the rule.
1. For **Rule type**, choose **Rule with an event pattern**.
1. **Define the Event Source**:
+ For "Event source", select **AWS services** as the event source.
+ For "AWS service name", select **AWS Control Tower**.
+ For "Event type", select **Drift Detected**
1. **Select the Target**:
+ For **Target types**, choose **AWS service**, and for **Select a target**, choose a target such as an drift notification topic or Lambda function. The target is triggered when an event is received that matches the event pattern defined in the rule.
+ Depending on the target you selected, provide the necessary configuration details, such as the Lambda function name or the drift notification topic ARN.
1. **Review and Create the Rule**:
+ Review the details of your rule and make any necessary changes.
+ Once you're satisfied, click on **Create rule** to save the new EventBridge rule.
After creating the rule, it will start monitoring for the specified AWS Control Tower events and trigger the selected target action when drift events occur.
# If you manage resources outside of AWS Control Tower
AWS Control Tower sets up accounts, organizational units, and other resources on your behalf, but you are the owner of these resources. You can change these resources within AWS Control Tower or outside it. The most common place to change resources outside of AWS Control Tower is the AWS Organizations console. This topic describes how to reconcile changes to AWS Control Tower resources when you make the changes outside of AWS Control Tower.
Renaming, deleting, and moving resources outside of the AWS Control Tower console causes the console to become out of sync. Many changes can be reconciled automatically. Certain changes require a reset to your landing zone, to update the information that's displayed in the AWS Control Tower console.
In general, changes that you make outside the AWS Control Tower console to AWS Control Tower resources create a state of *resolvable drift* in your landing zone. For more information about these changes, see [Repairable changes to resources](drift.md#repairable-changes-to-resources).
****Tasks that require landing zone reset****
+ Deleting the Security OU *(A special case, not to be done lightly.)*
+ Removing a shared account from the Security OU *(Not recommended.)*
+ Updating, attaching, or detaching an SCP associated with the Security OU.
****Changes that are updated automatically by AWS Control Tower****
+ Changing the email address of an enrolled account
+ Renaming an enrolled account
+ Creating a new top-level organizational unit (OU)
+ Renaming a registered OU
+ Deleting a registered OU *(Except the Security OU, which requires an update.)*
+ Deleting an enrolled account *(Except a shared account in the Security OU.)*
**Note**
AWS Service Catalog handles changes differently than AWS Control Tower. AWS Service Catalog may create a change in governance posture when it reconciles your changes. For more information about updating a provisioned product, see [Updating Provisioned Products](https://docs.aws.amazon.com//servicecatalog/latest/userguide/enduser-update.html) in the AWS Service Catalog documentation.
## Referring to resources outside of AWS Control Tower
When you create new OUs and accounts outside of AWS Control Tower, they are not governed by AWS Control Tower, even though they may be displayed.
**Creating an OU**
Organizational Units (OUs) created outside of AWS Control Tower are referred to as *Unregistered*. They are displayed in the **Organization** page, but they are not governed by AWS Control Tower controls.
**Creating an account**
Accounts created outside of AWS Control Tower are referred to as *Unenrolled*. Enrolled and unenrolled accounts that belong to an OU that’s registered with AWS Control Tower are displayed in the **Organization** page. Accounts that do not belong to a registered OU can be invited by using the AWS Organizations console. This invitation to join does not enroll the account in AWS Control Tower or extend AWS Control Tower governance to the account. To extend governance by enrolling the account, go to the **Organization** page or the **Account detail** page in AWS Control Tower and choose **Enroll account**.
## Externally changing AWS Control Tower resource names
You can change the names of your organizational units (OUs) and accounts outside of the AWS Control Tower console, and the console updates automatically to reflect those changes.
**Renaming an OU**
In AWS Organizations, you can change the name of an OU by using either the AWS Organizations API or the console. When you change an OU name outside of AWS Control Tower, the AWS Control Tower console automatically reflects the name change. However, if you provision your accounts using AWS Service Catalog, you also must reset your landing zone to ensure that AWS Control Tower stays consistent with AWS Organizations. The **Reset** workflow ensures consistency across services for the Foundational and Additional OUs. You can resolve this type of drift from the **Landing zone settings** page. See the section called "Resolving Drift" in [Detect and resolve drift in AWS Control Tower](drift.md).
AWS Control Tower displays the names of OUs on the **Organization** page in the AWS Control Tower dashboard. You can see when your landing zone reset operation has succeeded.
**Renaming an enrolled account**
Each AWS account has a display name that can be changed by the account's root user in the AWS Billing and Cost Management console. When you rename an account that's enrolled in AWS Control Tower, the name change is automatically reflected in AWS Control Tower. For more information about changing an account's name, see [Managing an AWS account](https://docs.aws.amazon.com//awsaccountbilling/latest/aboutv2/manage-account-payment.html#manage-account-payment-edit-user-name) in the *AWS Billing User Guide*.
## Deleting the Security OU
This type of drift is a special case. If you delete the **Security** OU, you will see an error message page, prompting you to reset your landing zone. You must reset your landing zone before you can take any other actions in AWS Control Tower.
+ You will not be able to perform any actions in the AWS Control Tower console and you will not be able to create any new accounts in AWS Service Catalog until the reset is done.
+ You won't be able to view the **Landing zone settings** page to see the **Reset** button there.
In this situation, the landing zone reset process creates a new Security OU and moves the two shared accounts into the new Security OU. AWS Control Tower marks the Log Archive and Audit accounts as drifted. The same process resolves the drift in these accounts.
**If you determine that you must delete the **Security** OU, here's what you need to know:**
Before you can delete the **Security** OU, you must make sure it contains no accounts. Specifically, you must remove the Log Archive and Audit accounts from the OU. We recommend that you move these accounts to another OU.
**Note**
The action of deleting your Security OU is not to be performed without due consideration. The action could create compliance concerns if logging is suspended temporarily, and because some controls might not be enforced.
For general information about drift, see "Resolving Drift" in [Detect and resolve drift in AWS Control Tower](drift.md).
## Removing an account from the Security OU
We do not recommend that you remove any of the shared accounts from your organization or move them out of the **Security** OU. If you have removed a shared account accidentally, you can follow the remediation steps in this section to restore the account.
+ **From within the AWS Control Tower console: **To start the remediation process, follow the semi-manual remediation steps. Ensure the user or role you use to access the AWS Control Tower console has permissions to run `organizations:InviteAccountToOrganization`. If you don't have such permissions, follow the manual remediation steps, which use both the AWS Control Tower console and the AWS Organizations console.
+ **Starting from the AWS Organizations console:** This remediation process is a slightly longer, fully manual procedure. When following the manual remediation steps, you'll switch between the AWS Organizations console and the AWS Control Tower console. When working in AWS Organizations, you'll need a user or role with the `AWSOrganizationsFullAccess` managed policy or equivalent. When working in the AWS Control Tower console, you'll need a user or role with the `AWSControlTowerServiceRolePolicy` managed policy or equivalent, and permission to run all AWS Control Tower actions (controltower:\$1).
+ If the remediation steps don't restore the account, contact AWS Support.
**The results of removing a shared account through AWS Organizations:**
+ The account is no longer protected by AWS Control Tower mandatory controls with service control policies (SCPs). **Result:** *The resources created by AWS Control Tower in the account may be modified or deleted.*
+ The account is no longer under the AWS Organizations management account. **Result:** *The administrator of the AWS Organizations management account no longer has visibility into the account's spending.*
+ The account is no longer guaranteed to be monitored by AWS Config. **Result:** *The administrator of the AWS Organizations management account may not be able to detect resource changes.*
+ The account is no longer in the organization. **Result:** *AWS Control Tower updates and reset will fail.*
**To restore a shared account using the AWS Control Tower console (semi-manual procedure)**
1. Sign in to the AWS Control Tower console at [https://console.aws.amazon.com/controltower](https://console.aws.amazon.com/controltower). You must sign in as an IAM user, user in IAM Identity Center, or role with permissions to run `organizations:InviteAccountToOrganization`. If you don't have such permissions, use the manual remediation procedure described later in this topic.
1. On the **Landing zone drift detected** page, choose **Re-Invite** to remediate shared account removal by re-inviting the shared account into the organization. An automatically-generated email is sent to the email address for the account.
1. Accept the invitation to bring the shared account back into the organization. Do one of the following:
+ Sign in to the shared account that was removed, then go to [https://console.aws.amazon.com/organizations/home\$1/invites](https://console.aws.amazon.com/organizations/home#/invites)
+ If you have access to the email message sent when you re-invited the account, sign in to the removed account, then click the link in the message to navigate directly to the account invitation.
+ If the shared account that was removed is not in another organization, sign into the account, open the AWS Organizations console and navigate to **Invitations**.
1. Sign in to the management account again, or reload the AWS Control Tower console if it's already open. You'll see the **Landing zone drift** page. Choose **Reset** to repair the landing zone.
1. Wait for the reset process to complete.
If remediation is successful, the shared account appears in a normal state and compliance.
If the remediation steps don't restore the account, contact AWS Support.
**To restore a shared account using the AWS Control Tower and AWS Organizations consoles (Manual remediation)**
1. Sign in to the AWS Organizations console at [https://console.aws.amazon.com/organizations/](https://console.aws.amazon.com/organizations/). You must sign in as an IAM user, user in IAM Identity Center, or role with the `AWSOrganizationsFullAccess` managed policy or equivalent.
1. Invite the shared account back to the organization. For information on the requirements, prerequisites, and procedure for inviting an account to AWS Organizations, see [Inviting an AWS account to your organization ](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html) in the *AWS Organizations User Guide*.
1. Sign in to the shared account that was removed, then go to [https://console.aws.amazon.com/organizations/home\$1/invites](https://console.aws.amazon.com/organizations/home#/invites) to accept the invitation.
1. Sign in to the management account again.
1. Sign in to the AWS Control Tower console as a user or role with the `AWSControlTowerServiceRolePolicy` managed policy or equivalent, and permissions to run all AWS Control Tower actions (controltower:\$1).
1. You'll see the **Landing zone drift** page with an option to reset the landing zone. Choose **Reset** to repair the landing zone.
1. Wait for the reset process to complete.
If remediation is successful, the shared account appears in a normal state and compliance.
If the remediation steps don't restore the account, contact AWS Support.
## External changes that are updated automatically
Changes that you make to your account email addresses are updated by AWS Control Tower automatically, but Account Factory does not update them automatically.
**Changing the email address of a governed account**
AWS Control Tower retrieves and displays email addresses as required by the console experience. Therefore, shared and other account email addresses are updated and shown consistently in AWS Control Tower after you change them.
**Note**
In AWS Service Catalog, the Account Factory displays the parameters that were specified in the console when you created a provisioned product. However, the original account email address is not updated automatically when the account email address changes. That’s because the account is conceptually contained within the provisioned product; it is not the same as the provisioned product. To update this value, you must update the provisioned product, which may cause a change in governance posture.
**Applying external AWS Config rules**
AWS Control Tower displays the compliance status of all AWS Config rules deployed into organizational units registered with AWS Control Tower, including rules that were activated outside of the AWS Control Tower console.
### Deleting AWS Control Tower resources outside AWS Control Tower
You can delete OUs and accounts in AWS Control Tower and you don't need to take any further action to see the updates. Account Factory is updated automatically when you delete an OU, but not when you delete an account.
**Deleting a registered OU (except the Security OU)**
Within AWS Organizations, you can remove empty organizational units (OUs) by using the API or the console. OUs that contain accounts cannot be deleted.
AWS Control Tower receives a notification from AWS Organizations when an OU is deleted. It updates the OU list in the Account Factory, so that the list of registered OUs remains consistent.
**Note**
In AWS Service Catalog, the Account Factory is updated to remove the deleted OU from the list of available OUs into which you can provision an account.
**Deleting an enrolled account from an OU**
When you delete an enrolled account, AWS Control Tower receives a notification and makes updates, so that the information remains consistent.
**Note**
In AWS Service Catalog, the Account Factory provisioned product that represents the governed account is not updated to delete the account. Instead, the provisioned product is displayed as `TAINTED` and in an error state. To clean up, go to AWS Service Catalog, choose the provisioned product, and then choose **Terminate**.