AWS Control Tower guardrails
Explains the two classification axes of AWS Control Tower guardrails: functional type (preventive vs detective) and enforcement level (mandatory, strongly recommended, elective).
What this file does
Explains the two classification axes of AWS Control Tower guardrails: functional type (preventive vs detective) and enforcement level (mandatory, strongly recommended, elective).
When to use it
- Learning how Control Tower enforces governance in a multi-account setup
- Choosing which guardrails to enable for your landing zone
- Understanding the difference between SCP-based and AWS Config-based guardrails
- Deciding whether a guardrail can be disabled on a specific OU
Assumes this stack
AWS Control Tower guardrails
AWS Control Tower implements guardrails using two primary mechanisms, resulting in different types based on their function and enforcement behavior.
Here are the different types of guardrails in AWS Control Tower:
1. Based on Function (How they work):
-
Preventive Guardrails:
- Purpose: To prevent actions that would lead to policy violations. They enforce policies before resources are created or modified.
- Mechanism: Implemented using AWS Organizations Service Control Policies (SCPs). SCPs act like allow/deny lists for AWS API actions for principals (users/roles) within affected accounts or Organizational Units (OUs).
- Effect: If a user tries to perform an action forbidden by a preventive guardrail (SCP), the action simply fails with an access denied error.
- Example: A guardrail preventing users from disabling AWS CloudTrail logging, deleting Control Tower essential resources, or launching resources outside of approved regions.
-
Detective Guardrails:
- Purpose: To detect non-compliance of resources after they have been created or modified. They monitor the state of your resources and alert you to policy violations.
- Mechanism: Implemented using AWS Config Rules. These rules continuously evaluate the configuration of your AWS resources against desired settings.
- Effect: When a resource is found to be non-compliant (e.g., an S3 bucket is publicly accessible when it shouldn't be), the AWS Config rule flags it as non-compliant, and this status is visible in Control Tower and AWS Config dashboards. It doesn't stop the resource from being created, but it raises an alert for remediation.
- Example: A guardrail detecting if MFA is enabled for the root user, checking if S3 buckets have public read/write access disabled, verifying if EBS volumes are encrypted.
2. Based on Enforcement Behavior (How strongly they are applied):
-
Mandatory Guardrails:
- Purpose: Essential for establishing and maintaining the baseline security and governance provided by Control Tower. They enforce AWS best practices critical for managing a multi-account environment.
- Application: Automatically enabled and enforced by Control Tower on the relevant OUs (e.g., the Security OU).
- Can you disable them? No, these cannot be disabled by customers.
- Implementation: Can be either Preventive (using SCPs) or Detective (using Config Rules).
- Example: Preventing modification of Control Tower core accounts/roles/resources, ensuring baseline logging configurations.
-
Strongly Recommended Guardrails:
- Purpose: Based on common AWS best practices for securing workloads and operating efficiently. They significantly improve security posture.
- Application: Enabled by default when you set up or update your landing zone, but you can choose to disable them (though generally not advised unless you have a specific reason and understand the risks).
- Can you disable them? Yes, these can be disabled on specific OUs if needed.
- Implementation: Can be either Preventive (using SCPs) or Detective (using Config Rules).
- Example: Disallowing public read access for S3 buckets (Detective), requiring MFA for the root user (Detective), notifying if encryption is not enabled on EBS volumes (Detective).
-
Elective Guardrails:
- Purpose: Optional controls that you can choose to enable to manage specific compliance requirements or address risks beyond the mandatory/strongly recommended sets.
- Application: Disabled by default. You must explicitly enable them on the OUs where you want them applied.
- Can you disable them? Yes, they are disabled by default and can be enabled/disabled as needed.
- Implementation: Can be either Preventive (using SCPs) or Detective (using Config Rules).
- Example: Checking for specific resource tags, enforcing encryption on specific database types, restricting specific instance types.
In Summary:
| Guardrail Type | Function | Mechanism | Enforcement | Default State | Can Disable? |
|---|---|---|---|---|---|
| Preventive | Prevents | SCPs | Varies | Varies | Varies |
| Detective | Detects | AWS Config Rules | Varies | Varies | Varies |
| Mandatory | Varies | SCPs / Config | Mandatory | Enabled | No |
| Strongly Recommended | Varies | SCPs / Config | Recommended | Enabled | Yes |
| Elective | Varies | SCPs / Config | Optional | Disabled | Yes |
Control Tower uses this combination of functional types (Preventive/Detective) and enforcement levels (Mandatory/Strongly Recommended/Elective) to provide a flexible yet robust governance framework for your multi-account AWS environment.
What's inside
Two main classification sections with sub-bullets, a summary table, and examples for each guardrail type.
Where it goes
Load as policy context for the agent, or keep beside the code enforcing the rules.
Worth borrowing
- Categorising controls by both mechanism and enforcement level gives a clear decision framework
- Using a summary table to contrast multiple dimensions (function, mechanism, enforcement, default state, disable-ability)
Related Documents
DeepSeek R1: Case Study in Failed Extrinsic Alignment
Compiles public security research and independent findings to argue that extrinsic alignment methods are insufficient for AI safety, using DeepSeek R1 as a case study.
Guardrails, Safety & Content Filtering
Implements a layered guardrail system with input validation, output validation, and content filtering to protect LLM applications from prompt injection, jailbreaks, and data leaks.
My Hyprland Rice Setup - Context for Claude Code
Documents a Hyprland rice setup with system specs, aesthetic preferences, workflow safety practices, and a list of current issues to solve.
AI Safety & Guardrails for Voice Assistants
Defines a multi-layer safety architecture for voice assistants, covering input filtering, deterministic FAQ routing, RAG-grounded AI responses, and output guardrails.