Terraform & OpenTofu Reusable Module Architecture¶
Purpose & Scope¶
This skill provides procedural standards and safety guardrails for authoring Terraform and OpenTofu infrastructure modules across AWS, Azure, and Google Cloud.
Module Structure Standards¶
Every module must maintain a strict, minimal root layout:
module-name/
├── main.tf # Core resource declarations and local variables
├── variables.tf # Explicitly typed input variables with descriptions & validation
├── outputs.tf # Explicitly documented output values
├── versions.tf # Required terraform version and provider constraints
└── README.md # Generated via terraform-docs with inputs/outputs/examples
Core Engineering Rules¶
- Explicit Types & Validations:
- Never declare a variable without a
typeconstraint anddescription. - Use custom
validationblocks for constrained parameters (e.g. environment names, IP CIDR ranges, naming patterns). - Provider Pinning:
- Never hardcode provider configuration blocks (
provider "aws" {}) inside a reusable module; providers must be passed from the root calling module. - Specify minimum and pessimistic provider versions in
versions.tfusing~>. - No Hardcoded Secrets or Identifiers:
- Never embed AWS Account IDs, subscription IDs, VPC IDs, or passwords.
- Use dynamic data sources or input variables.
Step-by-Step Workflow¶
- [ ] 1. Define required providers and minimum terraform version in
versions.tf. - [ ] 2. Declare input variables in
variables.tfwith default values where sensible and custom validation blocks. - [ ] 3. Implement target infrastructure in
main.tfusing consistent resource naming (thisfor singleton primary resources). - [ ] 4. Expose critical attributes (IDs, ARNs, endpoints) in
outputs.tfwith clear descriptions. - [ ] 5. Run static verification:
- [ ] 6. Generate module documentation via
terraform-docs markdown table . > README.md.