How compliance.tf Relates to Other Tools
Compliance.tf enforces compliance controls inside Terraform modules. Scanning tools verify configurations after code is written. Policy engines evaluate plans before apply. Account-level guardrails restrict what AWS APIs allow. These are different layers, and they work together.
If you are evaluating compliance.tf, you are probably already using one or more of these tools. Each page below explains what the tool does, where compliance.tf is stronger, where the alternative is stronger, and how to use them together.
For managers and non-technical stakeholders
Compliance.tf is a private Terraform registry. Your engineers change a URL in their module configuration, and the modules they download enforce compliance controls automatically — encryption is on, logging is enabled, public access is blocked. This happens at terraform plan time, before anything is deployed.
Scanning tools (Checkov, Trivy) check code after it is written. Policy engines (OPA, Sentinel) evaluate deployment plans. AWS Control Tower restricts what accounts can do. These all catch different problems at different stages.
| Tool | When it acts | What it covers | Keep or combine? |
|---|---|---|---|
| compliance.tf modules | terraform plan time, enforced in the module source | The 51 modules in the catalog | The compliance-enforced base layer for the resources it covers |
| Checkov / Trivy | CI/CD scan time | All Terraform resources, plus CloudFormation, Kubernetes, and Docker | Keep and combine — run it in CI against the full Terraform plan; preventive layer plus detective layer is defense in depth |
| OPA / Sentinel | Plan evaluation, before terraform apply | The entire Terraform plan (any resource, any provider), checked against organizational policies | Keep for organizational rules — naming, tags, approved regions, costs. compliance.tf sets the defaults; OPA or Sentinel governs everything else |
| AWS Control Tower | Account and organizational-unit level (preventive SCPs, detective Config rules, proactive CloudFormation hooks) | AWS accounts and OUs, including console, CLI, SDK, and CloudFormation actions | Keep — different layer. Control Tower governs what accounts can do; compliance.tf governs how resources within those accounts are configured |
Preventive enforcement vs IaC scanning — how the layers combine
Secure defaults vs policy gating — when to use each
Managed compliance modules vs in-house wrapper maintenance
Resource-level controls vs account-level governance
Reversibility and vendor dependency
Compliance.tf is a paid SaaS. Your Terraform configuration depends on the compliance.tf registry to download modules. This is a real dependency, and you should evaluate it as one.
If you stop using compliance.tf, you change your module source URLs back to terraform-aws-modules on the public Terraform Registry. Your Terraform code continues to work — the module interface is the same. However, you lose the compliance controls that were enforced by the compliance.tf modules, and you would need to replace them with another enforcement mechanism (scanning, policy engines, or custom wrappers).
This reversibility is straightforward but not zero-effort. Factor it into your evaluation.
Need to make the case to your team? Internal advocacy guide.