Terraform State Management

Remote backend with S3 for state storage and DynamoDB for locking — teams can run terraform apply safely without overwriting each other's work.

Why remote state

Local terraform.tfstate files do not scale for teams. Remote state in S3 is durable, versioned, and shared. DynamoDB provides a lock so two applies cannot run against the same state at once.

Backend configuration

backend "s3" {
  bucket         = "tf-state-example"
  key            = "prod/terraform.tfstate"
  region         = "ap-southeast-1"
  dynamodb_table = "terraform-locks"
  encrypt        = true
}

Operational practices

Enable versioning on the state bucket for point-in-time recovery
Block public access and restrict IAM to CI and approved roles
Use separate state keys per environment (dev/, prod/)
Never commit .tfstate or secrets to git

CI integration

GitHub Actions runs terraform plan on pull requests and apply on merge, using OIDC to assume a role with state bucket and lock table permissions only.

Outcomes

Predictable collaboration, audit trail via S3 versions, and infrastructure changes tracked the same way application code is.