terraform-infrastructure

Terraform Infrastructure Skill

Always use terraform-risk-playbook first when this skill is active. That skill is authoritative for the response contract, risk classification, runtime/version assumptions, validation commands, and rollback notes.

Authoritative precedence: when this skill and other Terraform skills are both active, this skill is authoritative for repo and stack layout, backend topology, CI composition, and multi-region deployment structure.

Step 1 — Module Structure

Organise Terraform code into reusable modules:

infra/
  modules/
    vpc/
      main.tf
      variables.tf
      outputs.tf
    rds/
      main.tf
      variables.tf
      outputs.tf
    ecs-service/
      main.tf
      variables.tf
      outputs.tf
  environments/
    staging/
      main.tf          ← calls modules, sets env-specific vars
      terraform.tfvars ← non-secret values only
      backend.tf       ← remote state config
    production/
      main.tf
      terraform.tfvars
      backend.tf

Rules:

• Every module has exactly three files: main.tf, variables.tf, outputs.tf.
• Modules accept inputs via variables.tf and expose results via outputs.tf.
• Never put environment-specific config inside a module.

Step 2 — Remote State

Use S3 remote state for AWS. Prefer native S3 lock files on Terraform 1.10+ and fall back to DynamoDB locking only for older runtime compatibility:

# environments/staging/backend.tf
terraform {
  backend "s3" {
    bucket         = "acme-terraform-state"
    key            = "staging/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    use_lockfile   = true
  }
}

State bucket requirements:

• Versioning enabled.
• Server-side encryption enabled (SSE-S3 or SSE-KMS).
• Block all public access.
• Access restricted to CI role and infrastructure team.

If the runtime is older than Terraform 1.10, replace use_lockfile = true with dynamodb_table = "acme-terraform-locks" and state that compatibility choice explicitly.