compliance.tf vs AWS Control Tower
What each tool solves
compliance.tf enforces compliance controls on individual Terraform resources — S3 buckets, RDS instances, ECS clusters, Lambda functions — at the module level. It works with any Terraform workflow, any AWS account, and does not require AWS Organizations.
AWS Control Tower provides account-level governance for AWS Organizations. It manages account provisioning, applies Service Control Policies (SCPs), and enforces guardrails at the AWS API level. Guardrails are preventive (SCPs that block API calls), detective (AWS Config rules that report violations), or proactive (CloudFormation Guard rules that check resource configurations before provisioning).
Where compliance.tf is stronger
compliance.tf enforces controls on specific resource attributes: S3 encryption algorithm, RDS parameter group settings, ECS task definition configurations. Control Tower operates at the account or organizational unit (OU) level — it can block entire API calls but does not set resource-level defaults.
Each control maps to specific compliance framework IDs: SOC 2 CC6.1, PCI DSS v4.0 Requirement 3.5.1, HIPAA 164.312(a)(2)(iv). Control Tower's guardrails are defined by AWS, grouped by AWS-defined categories, not mapped to third-party compliance framework control IDs.
- compliance.tf works with any AWS account. You do not need a landing zone, a management account, or an organizational structure. Control Tower requires AWS Organizations and a multi-account setup.
- IaC-native workflow. Developers see compliance errors at
terraform plantime in their terminal. Control Tower guardrails operate at the AWS API layer, and violations surface differently depending on guardrail type (SCP denials, Config rule findings).
Where AWS Control Tower is stronger
SCPs can prevent entire categories of API calls: "no one can disable CloudTrail in any account," "no one can create resources outside approved regions." These account-level restrictions are impossible to enforce at the Terraform module level. And Control Tower guardrails apply to console clicks, AWS CLI commands, SDK calls, CloudFormation stacks, and CDK deployments. Compliance.tf only covers infrastructure deployed through Terraform.
- AWS-managed and AWS-supported. Control Tower is a first-party AWS service. No third-party dependency, no vendor relationship, no subscription beyond your AWS bill.
- Control Tower manages the account factory: provisioning new accounts, applying baseline configurations, and enrolling accounts into the organizational structure. Compliance.tf has no account-level management capability.
- Built-in integration with AWS services. Control Tower integrates with AWS IAM Identity Center (SSO), AWS Config, CloudTrail, and AWS Security Hub. These integrations are maintained by AWS.
- Control Tower itself has no additional cost beyond the underlying AWS services (Config rules, CloudTrail). Compliance.tf is a paid subscription.
- Detective guardrails catch drift. AWS Config rules detect when resources drift from their expected configuration after deployment, even if the change was made outside Terraform. Compliance.tf only operates at
terraform plantime and has no visibility into post-deployment drift.
When to use both together
Use Control Tower to manage account-level governance: SCPs restricting allowed regions, preventing CloudTrail from being disabled, enforcing tag policies at the organizational level, and provisioning new accounts with baselines.
Use compliance.tf to manage resource-level compliance within each account: S3 encryption and logging, RDS encryption and backup configuration, ECS task hardening, VPC flow logging, and other resource-specific controls mapped to compliance frameworks.
Example: Control Tower prevents anyone from creating resources in unapproved regions (SCP) and detects if CloudTrail is disabled (detective guardrail). Compliance.tf ensures every S3 bucket deployed via Terraform has encryption enabled, access logging configured, and public access blocked (SOC 2 controls). Control Tower cannot set S3 encryption defaults. Compliance.tf cannot block console-based region misuse.
The two layers don't overlap. Control Tower governs what accounts can do. Compliance.tf governs how resources within those accounts are configured.
flowchart TD
CT["<b>AWS Organizations / Control Tower</b><br/>Account-level guardrails<br/>SCPs: approved regions · no CloudTrail disable · no root account usage<br/>Detective: Config rules for drift detection"]
CTF["<b>compliance.tf modules</b><br/>Resource-level compliance<br/>S3: encryption · logging · public access block<br/>RDS: encryption · backup · parameter hardening<br/>ECS: task definition security · logging"]
Deploy["terraform plan → terraform apply<br/>compliant resources in governed accounts"]
CT -->|"within each account"| CTF
CTF --> DeploySummary
| Dimension | compliance.tf | AWS Control Tower |
|---|---|---|
| Enforcement level | Individual Terraform resources | AWS accounts and organizational units |
| Covers non-Terraform actions (console, CLI, SDK) | No | Yes |
| Requires AWS Organizations | No | Yes |
| Framework mapping (SOC 2, PCI DSS, HIPAA) | Yes — 36 frameworks with control IDs | AWS-defined guardrail categories |
| Resource-level configuration control | Yes (per-attribute enforcement) | Limited (account-level SCPs) |
| Cost | Paid subscription (includes framework mapping, same-day upstream tracking, support) | Free (included with AWS) |
| Drift detection | No (IaC authoring time only) | Yes (detective guardrails via AWS Config) |
| Deployment model | Change Terraform module source URL | AWS console/API landing zone setup |
Need to make the case to your team? Internal advocacy guide.