Remote State and Backends

A backend determines where Terraform stores and locks its state. Standard backends like S3 store state remotely, but plan and apply still run locally on your machine or CI runner — running operations remotely is a separate feature of HCP Terraform, configured with the cloud block, not the S3 backend. The default local backend writes terraform.tfstate next to your code — fine for a solo experiment on a laptop, disqualifying the moment a second person or a CI job needs to touch the same infrastructure.

A remote backend puts state in shared, durable, encrypted storage. On AWS that means an S3 bucket: one object that a team and its pipeline read and write as a single source of truth, with versioning for recovery and encryption at rest. Switching from local to remote state is the line between a personal toy and a project anyone else can safely run.

The Local Backend and Its Limits

Local state is a single file on one machine. The local backend does lock it on that machine, but the lock cannot reach across machines — so the moment you share the file (commit it, pass it around) two laptops clobber each other; no sharing, so a teammate's plan is blind to what you just created; and no durability, so a wiped laptop or a fat-fingered rm takes your only record of production with it. People paper over this by committing the file to git or passing it around in chat, which trades one corruption mode for several worse ones. For anything beyond a throwaway sandbox, local state is the wrong answer.

The S3 Backend

The S3 backend stores the state object in a bucket you control. Turn on bucket versioning and every write becomes a recovery point — a bad apply is one console click from being rolled back. Default encryption (SSE-S3 or SSE-KMS) covers the plaintext secrets state carries, and blocking public access keeps the bucket off the open internet. Modern Terraform (1.10+) can also lock through S3 itself, which the locking topic covers next; older setups paired the bucket with a DynamoDB table.

terraform {
  backend "s3" {
    bucket       = "acme-tfstate-prod"
    key          = "network/terraform.tfstate"
    region       = "us-east-1"
    encrypt      = true
    use_lockfile = true
  }
}

Backend Configuration

The backend block is read before the rest of your configuration — before variables exist, before any expression is evaluated. That is why it cannot use var. references or interpolation: at the moment Terraform needs to find your state, the machinery that would resolve a variable has not run yet. The values in the block must be literals or supplied from outside. People hit this constantly, try to template the bucket name with a variable, and get a flat refusal.

Partial Backend Config

To serve dev and prod from the same code without duplicating the backend block, leave the changing values out and supply them at init time. This is partial configuration: the block declares it uses S3, and a per-environment file fills in the bucket and key. You pass it with terraform init -backend-config=prod.s3.tfbackend, swapping one file to point the same code at a different state.

# terraform init -backend-config=prod.s3.tfbackend
bucket = "acme-tfstate-prod"
key    = "network/terraform.tfstate"
region = "us-east-1"

Migrating Backends

When you move state from local to S3, or between backends, do it with terraform init -migrate-state. Terraform reads the existing state, writes it to the new backend, and preserves the lineage so the new location is recognized as the same history. Copying the file by hand looks equivalent and is not — a byte-for-byte copy does carry the serial and lineage along, but you skip the consistency check that compares them before writing, you don't rewrite the backend configuration, and you bypass the safety prompt that confirms what is moving where.