Reference · Terraform

Remote State & Backends

State as a shared, locked, versioned artifact — the modern (2025+) S3 setup.

The canonical modern S3 backend block

terraform {
  backend "s3" {
    bucket       = "acme-terraform-state"
    key          = "prod/network/terraform.tfstate"   # ← your isolation strategy lives here
    region       = "us-east-1"
    encrypt      = true
    use_lockfile = true                              # S3-native locking (TF ≥1.10)
  }
}

Stale-tutorial alert: most older guides add a dynamodb_table for locking. That's the old way — Terraform 1.10 introduced S3-native locking via use_lockfile = true (S3 conditional writes create a .tflock object), and the DynamoDB arguments are deprecated since 1.11. New projects: lockfile only. Migrating: you can set both during transition, then drop DynamoDB.

Source: S3 backend reference

Why remote state at all

Sync: one shared memory — everyone's run starts from the latest state (the 4th reason state exists).
Locking: a lock is taken at the start of any state-writing operation and released at the end — two concurrent applies can't interleave writes and corrupt state.
Durability & recovery: bucket versioning means a bad state write is a rollback, not a disaster.
Secrecy: state can hold secrets in plaintext — a private, encrypted bucket beats laptops and far beats git.

Backend facts that matter

The backend is configured in the terraform {} block and activated at terraform init — it is not stored in state, and changing it requires re-init.
Moving existing local state into a new backend: terraform init -migrate-state (Terraform offers to copy it).
Changing backend settings without moving state: terraform init -reconfigure.
The key is just an object path — one state file per key. Different components/environments use different keys (or different buckets). This is the seed of project structure.
Locking is per-state-file: two applies on different keys don't block each other.

Lock-related commands & flags

Command / flag	Use when
`-lock-timeout=5m`	Instead of failing instantly on a held lock, wait up to N for it to free (CI queues).
`terraform force-unlock LOCK_ID`	A crashed run left a stale lock. Verify no run is actually active, then unlock with the ID from the error message.
`-lock=false`	Almost never. Disables locking for one operation — a footgun kept for emergencies.

State bucket hardening checklist (AWS)

☑️ Versioning enabled (state rollback)
☑️ Default encryption (SSE-S3 or KMS) + encrypt = true
☑️ Block all public access; least-privilege bucket policy
☑️ use_lockfile = true in every backend block
☑️ Never in git — state is a credential, not code

Source: AWS Prescriptive Guidance — backend best practices