AWS Control Tower Guardrails
ActiveCommon framework
Best for: Organizations running multi-account AWS environments managed through AWS Control Tower. This applies to enterprises and mid-size companies using AWS Organizations with landing zones, particularly those needing centralized governance across multiple AWS accounts. If your cloud team provisions accounts through Control Tower's Account Factory, these controls define your baseline compliance posture. Common in financial services, healthcare, and SaaS companies scaling their AWS footprint.
| Mandatory? | Voluntary — enforced within AWS Control Tower environments |
|---|---|
| Who validates? | AWS automated enforcement; no external audit |
| Renewal | Continuous enforcement by AWS Control Tower |
| Scope | Multi-account AWS environments managed by Control Tower |
| Governing body | Amazon Web Services (AWS), AWS Control Tower Guardrails. Official source |
Get started
Point the module source at the AWS Control Tower Guardrails endpoint and pin a version range you reviewed:
module "..." {
source = "awscontroltower.compliance.tf/terraform-aws-modules/<module>/aws"
version = "<version>"
}awscontroltower.compliance.tf lists every AWS Control Tower Guardrails module with its versions, inputs and outputs.
What compliance.tf covers and what you handle
| Area | Compliance.tf automates | You handle |
|---|---|---|
| Encryption at Rest | Runs controls checking EBS volume encryption (ebs_attached_volume_encryption_enabled, ebs_encryption_by_default_enabled, ebs_volume_encryption_at_rest_enabled) and RDS instance encryption (rds_db_instance_encryption_at_rest_enabled). Validates encryption is configured at the resource level using AWS API and AWS Config-backed evaluations surfaced through Powerpipe/Steampipe. | KMS key management policy, key rotation schedules, cross-account key sharing governance, and documenting your organization's encryption standards. |
| Encryption in Transit | Checks RDS connection encryption controls: rds_db_instance_connections_encryption_enabled, rds_db_instance_mariadb_encryption_in_transit_enabled, and rds_db_instance_sql_server_encryption_in_transit_enabled. Validates the parameter group settings that enforce SSL/TLS at the engine level. | Certificate management for custom SSL certificates, application-level TLS configuration, and confirming that client applications actually connect over encrypted channels. |
| MFA Enforcement | Evaluates the IAM MFA controls covering root user, standard IAM users, and users with administrator access. Detects accounts and users without MFA configured via IAM credential report analysis. | Distributing and inventorying hardware MFA tokens, enforcing MFA in federated identity providers (Okta, Azure AD), and handling recovery procedures for locked-out users. |
| Public Access Prevention | Identifies resources with public exposure flags or public subnet placement with these controls: docdb_cluster_snapshot_restrict_public_access, rds_db_instance_no_public_subnet, rds_db_instance_prohibit_public_access, and rds_db_snapshot_prohibit_public_access. | Your network architecture design is out of scope here. VPC peering, Transit Gateway configurations, and the preventive SCPs that block public access grants at the org level all require separate implementation and review. |
| Resource Lifecycle Management | Checks ebs_volume_snapshot_exists, ebs_volume_unused, and ec2_instance_ebs_optimized. Flags orphaned EBS volumes and instances not configured for EBS optimization. | Snapshot retention policies, automated cleanup workflows for unattached volumes, and cost allocation tagging to track resource ownership. These controls flag drift; remediation workflows are yours to own. |
Controls by category
11 of 14 mapped controls are Enforced by compliance.tf modules at terraform plan. The other 3 are Mapped only: AWS Control Tower Guardrails lists them, no compliance.tf module checks them.
Data Encryption
The most common findings here are EBS volumes created before the account-level default encryption setting was enabled, and RDS instances missing SSL/TLS enforcement at the parameter group level. Expect requests for AWS Config evaluation results, the EBS encryption-by-default account setting per region, and RDS parameter group configurations showing rds.force_ssl or require_secure_transport.
| Control | Status |
|---|---|
| Attached EBS volumes should have encryption enabled | Enforced |
| RDS DB instance encryption at rest should be enabled | Enforced |
Public Access Restrictions
The most common violation is an RDS instance sitting in a public subnet with PubliclyAccessible set to true. DocumentDB snapshot sharing set to 'all' is rarer but high-severity. Assessors will ask for VPC subnet route table analysis, RDS instance configurations, and snapshot attribute queries to confirm public exposure is blocked.
| Control | Status |
|---|---|
| RDS DB instances should not use public subnet | Enforced |
| RDS DB instances should prohibit public access | Enforced |
Resource Configuration and Lifecycle
These controls cover operational hygiene: EBS volumes should have recent backup snapshots, unattached volumes should be flagged for cleanup, and EC2 instances should use EBS-optimized throughput where supported. Orphaned volumes are the primary finding, since they accumulate cost and may hold sensitive data without active oversight. Snapshot coverage is verified against your defined backup windows.
| Control | Status |
|---|---|
| EC2 instances should have EBS optimization enabled | Enforced |
Additional controls (9)
Amazon S3 (7)
Related frameworks
| Framework | Control overlap | Note |
|---|---|---|
| NIST Cybersecurity Framework v2.0 | High 91% | |
| PCI DSS v4.0 | High 85% | |
| ISO/IEC 27001:2022 | High 82% |
Frequently asked questions
Does this apply to me if I use AWS but not AWS Control Tower?
The guardrails themselves are specific to AWS Control Tower landing zones. That said, the underlying checks (EBS encryption, RDS public access, IAM MFA) apply to any AWS account. You can run these controls in Powerpipe against accounts that don't have Control Tower enabled. Where Control Tower adds value is centralized enforcement across dozens or hundreds of accounts.
What is the difference between preventive and detective guardrails?
Preventive guardrails use Service Control Policies (SCPs) to block non-compliant API calls before they execute. Detective guardrails use AWS Config rules to identify existing resources that violate policy. The controls in compliance.tf are detective guardrails: they evaluate current resource state rather than blocking provisioning.
Can I customize which guardrails are active in my Control Tower environment?
Yes. Control Tower categorizes guardrails as mandatory, strongly recommended, or elective. Mandatory guardrails cannot be disabled. Strongly recommended and elective guardrails can be enabled or disabled per organizational unit (OU). Align your active guardrails with your risk profile and any upstream compliance requirements like SOC 2 or HIPAA.
How do the controls mapped here relate to the full set of Control Tower guardrails?
AWS Control Tower provides hundreds of controls, and the count changes with service updates. The controls mapped here are detective checks around encryption, MFA, and public access. Preventive (SCP-based) and proactive (CloudFormation hooks) guardrails are not included, since both operate at provisioning time rather than evaluating existing resource state.
How often should I review Control Tower guardrail compliance?
Detective guardrails evaluate continuously via AWS Config, so drift shows up quickly. Check the compliance dashboard at least weekly, and immediately after account provisioning or OU restructuring. For audit evidence, export guardrail compliance status monthly and retain it.