SEO Summary: Stuck in AWS Control Tower enrollment hell with brownfield accounts? Discover why the pre-checks fail and get three battle-tested solutions to clear the blockers and get your Landing Zone back in green.

Control Tower “Brownfield” Updates Are a Trap. Here’s How to Fix Them.

Look, I get it. You were sold the dream of a “Single Pane of Glass.” You clicked the button to enroll that dusty old legacy-prod-01 account into your shiny new Control Tower setup, expecting a smooth transition. Instead, you got a spinning wheel and a vague error message about a “Pre-Check Failure” or a drifted resource.

I’ve been there. Last Tuesday, I was trying to pull our data-warehouse-legacy account into our main Organization unit. It was supposed to be a five-minute job before my second coffee. Three hours later, I was deep in CloudFormation stack events, reading error logs that looked like they were written by a robot having a panic attack. The account had a manual AWS Config setup from 2019, and Control Tower absolutely refused to touch it.

If you feel like throwing your monitor out the window, don’t. This is a rite of passage for every Cloud Architect at TechResolve. Here is why it’s happening, and how we fix it.

The “Why”: Control Tower is a Control Freak

The root cause is simple: Control Tower hates competition.

When you try to enroll a “Brownfield” account (an account that existed before Control Tower), the automation attempts to deploy specific baselines—primarily CloudTrail trails, AWS Config recorders, and IAM roles. Control Tower is designed to be the “source of truth.” If it detects that a Config Recorder or a Delivery Channel already exists in a region it wants to govern, it aborts the mission to prevent overwriting your data.

It’s a safety mechanism, but it feels like a bug. It doesn’t ask, “Hey Darian, want me to adopt this?” It just says, “failed,” and rolls back, leaving your account in a zombie state of “Tainted” or “Enrollment Failed.”

Solution 1: The “Surgeon” (Delete the Config Recorder)

This is the most common fix. If your error logs mention AWSConfigRemediation or state that a Configuration Recorder already exists, you have to manually delete the legacy recorder. Control Tower cannot overwrite it; the space must be empty.

Pro Tip: Before you do this, check if that legacy Config is piping data somewhere critical. Usually, it’s just old noise, but check first.

You can’t always do this easily in the Console UI because the old interface is… well, let’s just use the CLI. It’s cleaner. Assume a role in the target account (e.g., legacy-prod-01) and run this:

# 1. Get the name of the existing recorder
aws configservice describe-configuration-recorders

# 2. Delete the recorder (replace 'default' with the name found above)
aws configservice delete-configuration-recorder --configuration-recorder-name default

# 3. You also MUST delete the delivery channel
aws configservice delete-delivery-channel --delivery-channel-name default

Once the path is clear, hit the “Re-Register” or “Update” button in the Control Tower console. It should slide right in.

Solution 2: The “Back Door” (Service Catalog Repair)

Sometimes the Control Tower console itself is the problem. It caches status states like “Enrolled” even when the underlying stack failed. If the “Update” button is greyed out or doing nothing, we need to go to the engine room: AWS Service Catalog.

Control Tower is really just a trench coat with three kids (Service Catalog, CloudFormation, and SSO) inside it. You can bypass the fancy dashboard and force a provisioned product update directly.

1. Log into your Management (Root) account.
2. Go to Service Catalog > Provisioned products.
3. Find the product named AWS Control Tower Account Factory.
4. Select the failed account from the list (look for the physical ID that matches your account).
5. Click Actions > Update.

This forces the underlying CloudFormation stack to try again. I’ve saved dozens of “stuck” accounts this way when the main dashboard was useless.

Solution 3: The “Nuclear” Option (Role Nuke & Re-Bootstrap)

If the account is truly borked—maybe someone manually deleted the AWSControlTowerExecution role or modified the trust policy—you need to perform a hostile takeover. Control Tower can’t assume a role that doesn’t exist or doesn’t trust it.

This is hacky, but it works. We are going to manually recreate the execution role so the automation can get back in the door.

Create a file named trust-policy.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::[YOUR_MANAGEMENT_ACCOUNT_ID]:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Then, push the role back into the broken account:

# Create the role again
aws iam create-role --role-name AWSControlTowerExecution --assume-role-policy-document file://trust-policy.json

# Attach the AdministratorAccess policy (This is temporary!)
aws iam attach-role-policy --role-name AWSControlTowerExecution --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

Once this role exists, Control Tower can “Assume” into the account again. Go back to the dashboard and trigger the update. Once the enrollment succeeds, Control Tower will actually overwrite this role with the correct least-privilege policies managed by the stack, cleaning up your mess for you.

Summary of Fixes

Good luck out there. And remember: never trust a “One-Click Update” on a Friday.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions