Compatibility with terraform-aws-modules
For a platform lead checking whether a source-line change to compliance.tf is safe for existing code. This page is the reference for what stays the same, what changes, and where compliance.tf stops; the Migration kit has the steps.
- Same inputs, same outputs, same resource addresses as the upstream terraform-aws-modules release it is built from.
- What changes: the plan can fail, by control name, where the configuration breaks a control.
- A
terraform-aws-modules/*module compliance.tf does not serve passes through from the public registry without compliance.tf controls. Other namespaces are not served at all. - Version numbers mirror upstream, so existing version constraints keep working.
What stays the same
- Module inputs and outputs. The same variable names, types and outputs as upstream. Your
.tfvarsfiles work unchanged. - State. Terraform stores each resource address in state, and the source of the module that created it is not part of the address. Changing the source does not move or recreate resources, and needs no
terraform state mv. - Provider configuration. No new provider and no provider version change. Provider requirements come from the upstream module and are listed on each module page.
- Workflow. The same
init,planandapply. No extra CLI, sidecar or policy engine. - Version numbers. Compliance.tf publishes the upstream version numbers, so
version = "5.0.0"means the same upstream release. Module pages may also list build-pinned versions such as5.1.0-98ddc498fa. Which upstream majors each module supports is on Version compatibility.
What changes
- The source line.
terraform-aws-modules/s3-bucket/awsbecomessoc2.compliance.tf/terraform-aws-modules/s3-bucket/aws, or the host for your framework from Registry endpoints. - The plan can fail. Controls are validation blocks in the module HCL. A config that breaks one fails
terraform plan. The error names the control and links its page. Nothing reaches AWS. For example, an S3 bucket withoutlogging.target_bucketfails under SOC 2. - Some fixes need a rebuild. A few controls set values AWS cannot change on an existing resource, such as RDS storage encryption. The Migration kit lists them.
Modules compliance.tf does not serve
A request for a terraform-aws-modules/* module that is not in the module catalog is proxied to the public Terraform Registry. Your source line and workflow keep working, but the module arrives without compliance.tf controls: it behaves as if you had sourced it from terraform-aws-modules/... directly. If your organization has operational rules, they are applied to the proxied module as well; see Rules overview.
The same holds for submodules: a //modules/... path under a parent that is not in the catalog is proxied with its parent, without controls. Widely used modules such as terraform-aws-notify-slack and terraform-aws-atlantis are not in the catalog today.
Requests for any other namespace, such as cloudposse/* or hashicorp/*, return 404.
To make sure only modules with controls are used, check each source against the catalog before you count it as covered. The optional module source check for GitHub Actions flags plain terraform-aws-modules/ sources only. A compliance.tf source for a module outside the catalog passes it, so comparing module names with the catalog is a separate step.
Terraform and OpenTofu versions
The registry works with Terraform 1.0 or later and OpenTofu 1.6 or later, with the same source line.
The version a module needs is set by its own required_version, which follows the upstream release it is built from and is often higher than 1.0. For example, upstream s3-bucket 5.0.0 and ec2-instance 6.0.0 declare Terraform 1.10 or later, and rds 7.0.0 declares 1.11 or later. After init, the exact constraint is in .terraform/modules/<module name>/versions.tf. A stack of several modules needs the highest of their minimums.
The compliance.tf provider for AWS has its own minimum: Terraform 1.5 or OpenTofu.
New upstream releases
Compliance.tf follows upstream terraform-aws-modules releases. A pipeline picks up a new upstream version, applies the controls and publishes it. You upgrade as with any module: change the version and run terraform init, or terraform init -upgrade to move to the newest version your constraint allows.
Rollback
Point the source back at terraform-aws-modules/..., keeping the version constraint, and run terraform init. The plan shows no resource changes, and resource addresses stay where they were. The settings you added to satisfy controls stay on your resources; compliance.tf no longer checks them.