Generate Production-Ready Terraform AWS Modules

Terraform AWS Modules guides reusable module design, state management and HCL review for AWS infrastructure. It organizes a module into main.tf for resources, variables.tf for inputs, outputs.tf for exposed values and versions.tf for provider constraints. Version constraints for both providers and modules reduce unexpected changes when dependencies are resolved.

The inline VPC example accepts a name, address range and availability-zone list, enables DNS support and hostnames, and exposes the created network identifier. It demonstrates the module's input-resource-output structure. The shown resource does not consume the availability-zone input or create a complete subnet topology, so treat it as a limited module example rather than a finished network deployment.

Use it to create reusable AWS modules, review Terraform configuration, plan team state and workspace strategies, or migrate infrastructure from manual setup or CloudFormation. It is not intended for a non-AWS provider or a task whose required implementation is AWS CDK or CloudFormation.

Review environment-specific behavior before applying a pattern. Formatting and validation are useful checks, but they do not replace an infrastructure plan, security review or verification against the intended account. Missing inputs, permissions or success criteria need clarification before an affected execution step.

Inputs include the target resources, module interface, provider and module versions, environment strategy and backend configuration. Outputs should expose the values callers actually need rather than making consumers depend on internal implementation details. Consistent provider default_tags establish a shared tagging convention across resources.

For resources that require stable identity, use for_each rather than count. Review terraform plan output in the pull request so the proposed infrastructure changes are visible. Inspect the account, backend and saved plan before authorized application, and keep sensitive plan and state material private. State files must not be committed to version control.

The remote-state example uses an encrypted S3 backend and a DynamoDB lock table. Locking must match the actual Terraform version: that DynamoDB configuration is a version-dependent legacy example, not a requirement for every installation. Backend names, region and state path are environment-specific values to review before use.

An exact HCL output example is:

output "vpc_id" { value = aws_vpc.this.id }

Run terraform fmt and terraform validate before committing configuration. When an operation leaves a lock behind, first establish that no other operation is active. The force-unlock recovery path is for a confirmed stale lock; it must never remove another active operation's protection.

This skill suits AWS infrastructure maintainers who can review module interfaces, dependency constraints and state ownership. It supplies concise module and backend patterns, with application and environment verification still required for delivery.