Compare approaches
Read this if you are deciding where compliance.tf fits next to the tools you already run. Each tool acts on a different layer, and most teams keep theirs. Compliance.tf serves Terraform modules that arrive with the controls of the framework you picked, checks hand-written aws_* resources through its provider before Terraform calls AWS, applies your organization's operational rules at download time, and records who promoted which posture to which environment. Scanners check code after it is written, policy engines gate plans, and account-level controls restrict what AWS APIs allow.
| Tool | When it acts | What it covers | Keep or combine? |
|---|---|---|---|
| Compliance.tf | terraform init (modules arrive with controls) and terraform plan (module validations, provider checks) | Modules in the compliance.tf catalog; hand-written aws_* resources through the provider; org operational rules; posture per environment with an audit trail | The enforced base layer for the resources it covers |
| Checkov / Trivy | CI scan time | All Terraform resources, plus CloudFormation, Kubernetes, Dockerfiles and more | Keep and combine. Scan the full plan in CI: preventive layer plus detective layer |
| OPA / Sentinel | Plan evaluation, before terraform apply | The entire plan, any resource, any provider, against policies you write | Keep for organization-specific policy such as tags, team approvals and other providers |
| AWS Control Tower | On the AWS API call, at CloudFormation provisioning, and after a change | 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 Terraform configures resources inside them |
Preventive enforcement and IaC scanning, and how the layers combine
Secure defaults and policy gating, and when to use each
Managed compliance modules and in-house wrapper maintenance
Resource-level controls and account-level governance
Reversibility and vendor dependency
Compliance.tf is a paid SaaS, and your terraform init depends on its registry to download modules. Evaluate that as a real dependency.
To leave, change the module source lines back to terraform-aws-modules on the public Terraform Registry. The module interface is the same, so your code keeps working and no state migration is needed. What you lose is the enforcement: the controls those modules carried have to come from somewhere else (scanning, a policy engine or your own wrappers). The provider is adopted by changing the provider source and running one terraform state replace-provider; leaving is the same change in reverse.
Leaving means editing every source line and finding another home for the controls you relied on. Module code and state stay as they are.
Related
- Make the case: build the internal argument for adopting it
- How compliance.tf works
- Platform overview