Skip to content

AWS Control Tower Guardrails

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
RenewalContinuous enforcement by AWS Control Tower
ScopeMulti-account AWS environments managed by Control Tower

🏛 Amazon Web Services (AWS) · AWS Control Tower Guardrails Official source →

Get Started

module "..." {
  source  = "awscontroltower.compliance.tf/terraform-aws-modules/<module>/aws"
  version = "<version>"
}

What Compliance.tf Covers vs. What You Handle

  • What Compliance.tf automates

    • 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.
    • 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.
    • MFA Enforcement: Evaluates all six 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.
    • Public Access Prevention: Identifies resources with public exposure flags or public subnet placement across four 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.
    • 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.

  • What you handle

    • Encryption at Rest: KMS key management policy, key rotation schedules, cross-account key sharing governance, and documenting your organization's encryption standards.
    • Encryption in Transit: Certificate management for custom SSL certificates, application-level TLS configuration, and confirming that client applications actually connect over encrypted channels.
    • MFA Enforcement: 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: 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: 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

Data Encryption (3 controls)

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.

Attached EBS volumes should have encryption enabled compliance.tf module EBS volume encryption at rest should be enabled compliance.tf module RDS DB instance encryption at rest should be enabled compliance.tf module

Public Access Restrictions (2 controls)

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.

RDS DB instances should not use public subnet compliance.tf module RDS DB instances should prohibit public access compliance.tf module

Resource Configuration and Lifecycle (1 control)

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.

EC2 instance should have EBS optimization enabled compliance.tf module
Additional Controls (7)

Amazon S3 (7)

S3 bucket MFA delete should be enabled compliance.tf module S3 bucket ACLs should not be accessible to all authenticated user compliance.tf module S3 bucket policy should prohibit public access compliance.tf module S3 buckets should prohibit public read access compliance.tf module S3 buckets should prohibit public write access compliance.tf module S3 bucket versioning should be enabled compliance.tf module S3 public access should be blocked at account level compliance.tf module

  • CIS AWS Benchmark v3.0.0 — 🟡 Medium overlap (45%)

    CIS AWS Foundations Benchmark covers many of the same IAM MFA requirements and encryption checks. Control Tower guardrails are narrower in scope, focusing on multi-account governance rather than the full breadth of CIS sections on logging, monitoring, and networking.

  • AWS Well-Architected Framework — 🟡 Medium overlap (30%)

    The Security Pillar of the Well-Architected Framework shares some requirements with Control Tower on encryption and access control. Control Tower guardrails implement a subset of Well-Architected recommendations as enforceable rules, but Well-Architected covers operational excellence, cost optimization, and other pillars outside Control Tower's scope.

  • NIST 800-53 Rev 5 — ⚪ Low overlap (20%)

    Control Tower guardrails map loosely to NIST 800-53 control families SC (System and Communications Protection) for encryption and IA (Identification and Authentication) for MFA. NIST 800-53 is far broader, covering physical security, personnel security, and incident response that Control Tower does not address.

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 these 33 controls relate to the full set of Control Tower guardrails?

AWS Control Tower provides hundreds of controls, and the count changes with service updates. The 33 controls mapped here are the most common 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.