Generate Production-Ready Terraform AWS Modules
Reusable Terraform AWS module design: remote state with DynamoDB locking, for_each patterns, and version pinning.
Why it matters
Leverage expert Terraform knowledge for AWS to create reusable, production-grade modules. Ensure best practices in HCL, state management, and resource tagging for robust infrastructure as code.
Outcomes
What it gets done
Structure Terraform modules with standard files (variables.tf, outputs.tf, main.tf, versions.tf).
Implement remote state management using S3 and DynamoDB for team collaboration.
Apply consistent resource tagging and adhere to version pinning for stability.
Review and validate Terraform code for best practices, security, and maintainability.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-terraform-aws-modules | bash Overview
modules/vpc/variables.tf
Covers reusable Terraform AWS module design: standard file structure, S3+DynamoDB remote state with locking, provider version pinning, for_each vs count, consistent tagging, and stuck-lock troubleshooting. Use when building or reviewing Terraform modules for AWS, setting up remote state, or migrating from CloudFormation/manual setup; not for CDK, CloudFormation, or non-AWS providers.
What it does
This skill covers designing reusable Terraform modules for AWS with production-grade HCL patterns: structuring modules with clear variables.tf, outputs.tf, main.tf, and versions.tf; pinning provider and module versions to avoid breaking changes; setting up remote state with S3 and DynamoDB locking for team environments; running terraform fmt/terraform validate before commits; preferring for_each over count for resources needing stable identity; and applying consistent resource tagging via a default_tags block in the provider configuration.
It includes two worked examples - a reusable VPC module (variables.tf with name/cidr/azs inputs, main.tf creating an aws_vpc resource with DNS support enabled, outputs.tf exposing the VPC ID) and an S3+DynamoDB remote state backend configuration with encryption enabled - plus a troubleshooting entry for a stuck state lock after a failed apply, resolved with terraform force-unlock <LOCK_ID> once no other operations are confirmed running.
When to use - and when NOT to
Use this skill when creating reusable Terraform modules for AWS resources, reviewing existing Terraform code for best practices and security, designing a remote state and workspace strategy, or migrating infrastructure from CloudFormation or manual console setup to Terraform.
Do not use it when the target is AWS CDK or CloudFormation rather than Terraform, or when the infrastructure runs on a non-AWS cloud provider - the module patterns and examples here are AWS-specific and don't generalize to other providers' resource models.
Inputs and outputs
Input is an AWS infrastructure requirement (a VPC, a remote state setup, an existing Terraform codebase to review) or a specific Terraform problem, such as a stuck state lock. Output is structured HCL following the four-file module convention, a pinned-version configuration, or a concrete fix - like the force-unlock command - for the reported problem.
terraform force-unlock <LOCK_ID>
Integrations
Targets AWS as the cloud provider and Terraform's own tooling (terraform fmt, terraform validate, terraform plan), using S3 for state storage and DynamoDB for state locking as the standard team-scale backend, with encryption enabled on the state bucket.
Who it's for
Infrastructure and platform engineers writing or reviewing Terraform for AWS who need consistent module structure, safe remote state practices, and version-pinning discipline, rather than one-off unmanaged terraform apply scripts run without state coordination.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.