compliance.tf vs Custom Wrapper Modules

What each tool solves

compliance.tf provides compliance-ready Terraform modules that wrap terraform-aws-modules with enforced controls. The modules are maintained by the compliance.tf team, version-tracked against upstream releases, and mapped to compliance frameworks.

Custom wrapper modules are in-house Terraform modules that your platform or infrastructure team writes and maintains. They typically wrap terraform-aws-modules (or raw AWS resources) with organization-specific defaults, input validations, and policy enforcement. They encode your team's decisions about how infrastructure should be configured.

Where compliance.tf is stronger

When upstream terraform-aws-modules releases a new version, compliance.tf tracks and tests compatibility. With custom wrappers, your team must review every upstream release, update the wrapper, test for breaking changes, and release a new version internally.

Controls are mapped to SOC 2, PCI DSS v4.0, HIPAA, NIST 800-53, and 30+ other frameworks. Building and maintaining these mappings in-house requires deep compliance knowledge and ongoing research as framework requirements evolve.

• Custom wrappers depend on the engineer(s) who built them. If they leave, the compliance logic becomes legacy code that no one fully understands. Compliance.tf moves that maintenance to a dedicated team, though this introduces a vendor dependency (see below).
• Version-tracked control changes. When compliance requirements change, compliance.tf modules are updated in versioned releases with changelogs. Custom wrappers require someone to notice the requirement change, interpret it correctly, and update the module.

Where custom wrapper modules are stronger

Custom wrappers encode institutional knowledge that compliance.tf does not cover: your company's naming patterns, tagging schemas, network topology decisions, and deployment conventions. You decide which variables to expose, which to hide, what defaults to set, and how the module behaves for your teams.

• No external dependency. No registry availability concern, no subscription cost, no vendor relationship to manage. Your wrappers work even if a third-party service is down.
• Custom wrappers are not limited to the compliance.tf catalog. You can wrap any Terraform module, any provider resource, or any combination of resources.
• Faster iteration on changes. When your organization's requirements change, you push a new version of your wrapper immediately. With compliance.tf, you depend on the vendor's release cycle for changes to compliance controls.
• Custom wrappers cost engineering time (which is not free), but the cost is already part of your infrastructure team's budget. There is no additional SaaS subscription.

When to use both together

Use compliance.tf modules as the compliance-enforced base layer. Wrap them in a thin organizational module that adds your company-specific defaults: naming conventions, required tags, internal network configuration, and any business logic specific to your organization.

This separates concerns. Compliance.tf handles compliance (encryption, public access blocking, backup retention, and TLS configuration). Your thin wrapper handles business logic (naming, tagging, network topology, environment-specific configuration). When compliance requirements change, compliance.tf updates the controls. When your organizational requirements change, you update your thin wrapper.

The internal wrapper becomes much simpler — it handles only business logic, not compliance logic. And you are not maintaining compliance framework mappings in-house.

flowchart TD
    Wrapper["<b>Your thin organizational wrapper</b><br/>naming · tags · network config<br/>environment-specific defaults"]
    CTF["<b>compliance.tf module</b><br/>encryption · logging · access controls<br/>framework compliance"]
    Upstream["<b>terraform-aws-modules</b> (upstream)<br/>core AWS resource configuration"]

    Wrapper --> CTF --> Upstream

Summary

Need to make the case to your team? Internal advocacy guide.