Every Control Tower customer eventually hits this wall: you click “Enable” on a guardrail in the Control Tower console, see a spinning indicator, and then get hit with “Guardrail could not be enabled” or the guardrail shows “Registration failed” on the OU. It’s frustrating because the error message tells you almost nothing. I’ve debugged this enough times to know exactly where to look. In this post, I’ll walk through exactly what causes guardrail enablement to fail and how to fix it.
The Problem
When you try to enable a guardrail on an OU in Control Tower, the platform attempts to either deploy an SCP (for preventive guardrails), create Config rules (for detective guardrails), or register a CloudFormation hook (for proactive guardrails). If any step in this deployment fails, the whole thing rolls back and you’re left with a “Registration failed” status.
| Error Type | Description |
|---|---|
| Registration failed | Pre-condition check failed for accounts in the OU |
| SCP conflict | Existing SCP prevents guardrail from working |
| Config not enabled | AWS Config missing in one or more accounts |
| StackSet operation failed | Concurrent CloudFormation operation blocking |
| Hook registration failed | CloudFormation hook deployment timeout |
Why Does This Happen?
- OU has accounts that don’t meet pre-conditions — Some guardrails have prerequisites. For example, VPC-related guardrails require that accounts have a VPC already created. If one account in the OU is missing this, the guardrail cannot be enabled for any account in the OU.
- Existing SCP conflicts — If another SCP on the OU or parent OU denies the actions that the guardrail needs to perform, the guardrail SCP cannot take effect properly, and Control Tower blocks enablement to avoid governance conflicts.
- AWS Config not enabled — Detective guardrails depend on AWS Config running and compliance evaluation enabled in every account and region. If Config is disabled in even one account, the guardrail cannot be enabled.
- Concurrent StackSet operation in progress — When Control Tower deploys guardrails (especially proactive ones), it uses CloudFormation StackSets. If another StackSet operation (like a Landing Zone update) is already in progress, enablement waits and eventually times out.
- CloudFormation hook deployment timeout — Proactive guardrails use CloudFormation hooks, which must be registered globally. If registration hangs or times out, the guardrail fails.
The Fix
Identify which type of guardrail is failing and apply the corresponding fix.
Check the Guardrail Type
First, understand what the guardrail does. In the Control Tower console:
Control Tower → Guardrails → [Select Guardrail] → Details
Note the guardrail type: Preventive (SCP-based), Detective (Config-based), or Proactive (CloudFormation hook-based).
For Detective Guardrails: Enable AWS Config
Detective guardrails require AWS Config to be enabled in all accounts and all regions. Check Config status:
aws configservice describe-configuration-recorders \
--region us-east-1 \
--output text
If the recorder is stopped, start it:
aws configservice start-configuration-recorder \
--configuration-recorder-name default \
--region us-east-1
Repeat this check in every region where you’re enabling Control Tower. If Config is not deployed, deploy it via the AWS Config service or enable it through Control Tower itself first.
For Preventive Guardrails: Check for SCP Conflicts
Review all SCPs attached to the OU or parent OUs. In the AWS Organizations console:
Organizations → Policies → Service Control Policies → [Select Policy]
If you see SCPs that deny CloudTrail, Config, SNS, or CloudWatch Logs actions, those will conflict. Temporarily detach conflicting policies, enable the guardrail, then reattach them if needed.
For All Guardrails: Check StackSet Operations
Monitor StackSet operations:
aws cloudformation list-stack-set-operations \
--stack-set-name AWSControlTowerBP-BASELINE-CLOUDTRAIL \
--output text
If an operation is in “RUNNING” state, wait for it to complete before enabling a new guardrail.
Re-Enable the Guardrail
Once you’ve addressed the blocker (enabled Config, fixed SCP conflicts, waited for StackSets to complete), return to the Control Tower console and click “Enable” again on the guardrail.
How to Run This
- Go to Control Tower → Guardrails and select the failing guardrail.
- Note the guardrail type (Preventive, Detective, or Proactive).
- If Detective: verify AWS Config is enabled in all accounts in the OU using the command above.
- If Preventive: review parent OU SCPs in AWS Organizations console.
- Check StackSet operations using the provided command.
- Wait for any in-progress operations to complete.
- Return to Control Tower and click “Enable” on the guardrail again.
- Monitor the enablement status — it should now succeed.
Is This Safe?
Yes. Enabling guardrails is safe and reversible. You can disable a guardrail at any time without affecting your workloads. AWS Config will continue to run regardless of guardrail status.
Key Takeaway
Guardrail enablement failures are usually caused by missing AWS Config, SCP conflicts, or in-progress StackSet operations. Verify prerequisites, wait for concurrent operations to finish, and try enabling the guardrail again.
Have questions or ran into a different Control Tower issue? Connect with me on LinkedIn or X.