Why Enterprises Choose Compliance.tf Over terraform-aws-modules

Compare the hidden costs of building compliance yourself on terraform-aws-modules with the built-in controls and managed maintenance that compliance.tf provides.

Anton Babenko

Your SOC 2 audit is in three months. Your Terraform codebase uses terraform-aws-modules. Now someone asks: "How do we prove these modules are compliant?" That question starts a project that can run for weeks.

terraform-aws-modules is well-maintained and widely used. But the modules are general-purpose by design — they support any valid AWS configuration, compliant or not. Closing that gap is your team's job.

Compliance.tf is a private Terraform registry that adds compliance controls directly inside terraform-aws-modules, so non-compliant configurations are blocked by the module itself. This article explains what that changes for enterprise teams and where the trade-offs are.

Terraform and OpenTofu

Compliance.tf works with both Terraform and OpenTofu. This article uses "Terraform" for brevity, but all examples and concepts apply equally to OpenTofu users.

What terraform-aws-modules Gives You

terraform-aws-modules provides flexible, general-purpose building blocks for AWS infrastructure. The modules are open source, free, and backed by a large community. They are designed to support any valid AWS configuration — compliant or not.

This flexibility is a feature. It is also the root of the compliance challenge: every configuration is allowed, and distinguishing compliant from non-compliant is left to you.

The Hidden Costs of Building Compliance Yourself

When your team layers compliance on top of terraform-aws-modules, the work tends to grow in ways that are not obvious upfront.

  • Wrapper modules and policy rules. Most teams build internal wrapper modules or write OPA/Sentinel policies that mirror what the modules should enforce. These rules need to cover every variable, every default, and every edge case for each module you use.

  • Maintenance across upstream releases. When terraform-aws-modules publishes a new major version, your wrapper modules and policy rules may break. You need to update both in sync, test the combination, and roll it out across teams.

  • Policy-framework drift. Compliance frameworks update their requirements over time. Keeping your custom policies aligned with the latest SOC 2 or CIS guidance is an ongoing effort that compounds with each framework you support.

  • Knowledge concentration. The engineers who understand both Terraform internals and compliance requirements are rarely the same people. The compliance layer becomes a bottleneck that depends on a few specialists.

These costs are real and recurring. They do not show up in a module download count, but they show up in sprint capacity.

What Compliance.tf Actually Changes

The core change is a source URL swap:

terraform
# Before: Using the public Terraform registrymodule "s3_bucket" {  source  = "terraform-aws-modules/s3-bucket/aws"  version = "5.9.0"  bucket  = "my-data"} # After: Using compliance.tf with SOC 2 controlsmodule "s3_bucket" {  source  = "soc2.compliance.tf/terraform-aws-modules/s3-bucket/aws"  version = "5.9.0"  bucket  = "my-data"}

Everything else stays the same — same module interface, same variables and outputs, same CI pipeline. When stricter validation rules require new inputs, Terraform will fail with a clear error message describing exactly what to add. Your existing IaC scanners like Checkov and Trivy continue to work alongside compliance.tf — they are complementary, not replaced.

What is new: the module now enforces compliance controls internally through safe defaults, validation rules, and restricted configuration surfaces. If a developer tries to pass a non-compliant value, Terraform fails at plan time with a clear error:

text
Control 's3_bucket_logging_enabled': `logging.target_bucket` must be set to enable S3 bucket access logging.
Read more: https://compliance.tf/docs/controls/aws/s3_bucket_logging_enabled
Frameworks: SOC 2, CIS AWS v1.4.0 (3.6), PCI DSS v4.0 (10.2.1)

Controls can be enabled or disabled per module when you need exceptions — the goal is compliant defaults with explicit, auditable opt-outs.

If a module is not yet available in compliance.tf, requests are proxied to the original HashiCorp Terraform Registry. Your existing workflow does not break — you get compliance controls where they exist and fall back to the original modules where they do not.

Note: when a module is proxied to the original registry, compliance controls do not apply to it. You keep workflow continuity; the compliance guarantee applies only to modules with compliance.tf versions.

For a deeper look at how controls work inside the modules, see Make Non-Compliant Terraform Impossible With Compliance.tf. For verification and audit evidence, see Verifying Compliance.tf Modules: From Guardrails to Audit Evidence.

Enterprise Readiness Beyond Compliance Controls

Beyond the compliance layer, compliance.tf manages compatibility between module versions and compliance controls. When terraform-aws-modules publishes a breaking change, compliance.tf tests and updates the compliance constraints so your team does not have to.

Commercial support is available for enterprise customers, unlike the community-only support model of open-source modules.

Honest Comparison

Both terraform-aws-modules and compliance.tf serve different needs. This table shows where each has genuine advantages:

Aspectterraform-aws-modulescompliance.tf
CostFree, open sourceCommercial (paid)
Configuration flexibilityAny configuration allowedConstrained to compliant values (with opt-out)
Community governanceFully open, community-drivenBuilds on upstream; compliance layer is proprietary
Compliance controlsNone built in — add your ownBuilt in, mapped to 30+ frameworks
Compliance maintenanceYou manage wrappers and policiesManaged by compliance.tf
Module breadthAll modules in the namespaceSubset with compliance controls; rest proxied to original
Breaking change managementYour responsibilityManaged by compliance.tf
SupportCommunity (GitHub issues)Commercial support available

terraform-aws-modules wins on cost, flexibility, community transparency, and module breadth. Compliance.tf wins on built-in compliance, managed maintenance, and support. The right choice depends on whether your team's time is better spent building compliance infrastructure or shipping product features.

What Compliance.tf Does Not Cover

Compliance.tf enforces infrastructure-level controls inside Terraform modules. It does not cover:

  • Organizational controls. Access reviews, HR policies, incident response procedures, and other non-infrastructure requirements are outside scope. SOC 2, for example, includes organizational controls that no IaC tool can address.
  • Every AWS service. Compliance.tf covers a specific set of modules. Services outside that list use the original terraform-aws-modules via the proxy fallback.
  • Post-deployment drift. Resources modified outside Terraform (via console, CLI, or other tools) are not detected by compliance.tf. Use infrastructure scanners like Prowler or AWS Config for runtime verification.
  • Replacing your scanning pipeline. Compliance.tf works alongside IaC scanners, not instead of them. See how verification works for the full picture.

Getting Started

The fastest way to evaluate compliance.tf is to try one module. Change a single source URL, run terraform plan, and review the controls it enforces. You can switch back with the same change if it does not fit.

Browse the module catalog, review the controls they enforce, and see the Technical Usage guide for setup instructions.

Start the free trial

Found this useful?

Share it with your team or post it on LinkedIn, X, or your favorite community.

Next Step

See which modules are covered

Browse the compliance.tf module catalog to check if your AWS modules are available with built-in controls.
Browse the module catalog