Control Tower drift is one of the most common issues I see in production environments, and it’s also one of the most misunderstood. You’re scrolling through the Control Tower dashboard, you see “DRIFTED” next to an account or OU, and you’re not sure what it means or whether it’s a problem. The answer is: it depends. Drift is Control Tower’s way of telling you that something has changed since the landing zone baseline was applied. In this post, I’ll explain what drift is, why it happens, and how to remediate it safely.

The Problem

Drift means that a Control Tower-managed resource (CloudTrail, Config, SCP, IAM role, SNS topic, etc.) has changed from its expected state. The drift detection scan runs daily and compares the current state to what Control Tower expects. If there’s a mismatch, the account or OU is marked DRIFTED.

Drift Type Description
Resource deleted CloudTrail trail, Config recorder, or SNS topic was deleted
Resource modified Settings were changed (e.g., CloudTrail stopped recording)
Stack mismatch CloudFormation stack was manually edited
Account moved Account moved between OUs without Control Tower
Policy modified SCP was edited outside of Control Tower

Why Does This Happen?

  • Manual changes to Control Tower-managed resources — If you modify CloudTrail trail settings, delete a Config recorder, or edit an SCP in AWS Organizations console instead of through Control Tower, drift is triggered. These resources are managed by Control Tower and shouldn’t be touched directly.
  • CloudFormation stack manually deleted or modified — Control Tower uses CloudFormation stacks (StackSets) to deploy baselines. If you delete or modify a stack manually instead of through Control Tower, the account drifts.
  • Account moved between OUs outside of Control Tower — If you move an account in AWS Organizations console directly, the account drifts because Control Tower didn’t orchestrate the move. Control Tower uses Account Factory to move accounts so it can re-baseline them.
  • Control Tower Landing Zone updated but StackSets not yet propagated — When you update the Landing Zone, StackSets are deployed to all accounts. If you check for drift before all deployments complete, you might see temporary drift.
  • SCPs modified via Organizations console instead of Control Tower — If you edit an SCP that’s attached to an OU managed by Control Tower, the OU drifts. Control Tower manages its SCPs (like preventive guardrails), and they should not be modified directly.

The Fix

Remediate drift in the right way. Don’t just click “Repair” — understand what drifted first.

Step 1: Run a Drift Detection Scan

In the Control Tower console:

Control Tower → Landing Zone → Check for drift

The scan runs in the background and checks all accounts and OUs. This takes 5–15 minutes depending on the size of your organization.

Step 2: Review Drift Details

Once the scan completes, go to:

Control Tower → Organization → [Select account or OU]

Click View drift details to see exactly which resources have drifted and how.

Step 3: Decide: Repair or Accept Drift

For each drifted resource, decide whether to repair it or accept the drift.

Repair if:

  • The drift was accidental (e.g., someone deleted a CloudTrail trail by mistake)
  • The resource is Control Tower-managed (prefixed aws-controltower-*)
  • You need to restore governance

Accept the drift if:

  • You intentionally made the change (e.g., you manually created a custom SCP and attached it to the OU)
  • You understand the governance implications
  • You plan to manage the resource separately from Control Tower

Step 4: Repair Drifted Resources

To repair, select the drifted account or OU and click Repair:

Control Tower → Organization → [Select account/OU] → Repair

Control Tower re-applies the baseline configuration from the StackSet. This re-deploys CloudTrail, Config, SNS topics, and other baseline resources. Repair is safe — it only restores what should be there, idempotently.

Step 5: Automate Drift Detection

For ongoing compliance, set up automated drift detection with EventBridge. Create a rule that triggers on drift events:

EventBridge → Rules → Create Rule
Event Source: AWS Events
Event Pattern:
{
  "source": ["aws.controltower"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["controltower.amazonaws.com"]
  }
}

Set the target to an SNS topic or Lambda to notify your team of drift.

How to Run This

  1. Open the Control Tower console.
  2. Go to Landing Zone → Check for drift and wait for the scan to complete (5–15 minutes).
  3. Once complete, go to Control Tower → Organization.
  4. Select each drifted account or OU and click View drift details.
  5. For each drifted resource, decide whether to repair or accept the drift.
  6. For resources you want to repair: select the account/OU and click Repair.
  7. Wait for the repair to complete (monitor in CloudFormation console for StackSet operations).
  8. Run the drift scan again to confirm drift is resolved.
  9. Optional: Set up EventBridge rule to automate future drift detection and notification.

Is This Safe?

Yes. Repairing drift is safe and repeatable. Control Tower uses CloudFormation StackSets, which are idempotent — running them multiple times produces the same result. If you repair a resource you actually intended to change, you can simply re-make the change afterward.

Key Takeaway

Drift means a Control Tower-managed resource has changed from its expected state. Always understand what drifted before repairing. Repair accidental changes, but accept intentional drift if you’re managing the resource separately. Use drift detection scans regularly to maintain governance compliance.

Have questions or ran into a different Control Tower issue? Connect with me on LinkedIn or X.