In Chapter 11 we briefly looked at remote state. Now we’re going to dive deeper, because it’s one of the pillars of teamwork with Terraform. In this subchapter we’ll configure the most widely used backend in the AWS world: S3 + DynamoDB. S3 stores the state, and DynamoDB handles the “locking” so multiple people don’t step on each other’s toes. Let’s see it step by step.

Remember from subchapter 11.3 the problem with local state: if the terraform.tfstate file is on your laptop, your team can’t collaborate (everyone would have their own copy), and if you lose the file, you lose control of your infrastructure. The solution is to store the state in a central and shared place: a remote backend.

The standard backend in AWS combines two services you already know, each with a role:

• S3 (Chapter 5): stores the tfstate file. It’s durable, versioned, and encrypted.
• DynamoDB (subchapter 8.3): manages locking to prevent two people from modifying the state at the same time (we’ll see this in detail in subchapter 20.2).

These two resources are the “foundations” that must exist before configuring the backend. They’re usually created just once:

Note two important details:

• The bucket’s versioning (see subchapter 5.3) saves the history of the state. If something goes wrong, you can roll back to a previous version. It’s an invaluable safety net.
• The DynamoDB table uses a LockID key: that’s where Terraform writes the “lock” when someone is working.

Once the bucket and table exist, configure your project to use that backend. This is done in the terraform block:

Let’s review each line:

• bucket: the S3 bucket where the state is stored.
• key: the path of the file inside the bucket. Note produccion/...: using a different path per environment is key for the directory strategy (subchapter 19.2). Each environment has its own separate state.
• dynamodb_table: the table that manages locks.
• encrypt = true: encrypts the state at rest. Important, because the state may contain sensitive data (subchapter 11.2).

After configuring the backend, run terraform init (subchapter 11.4). Terraform detects the backend and, if you already had local state, asks if you want to migrate it to remote:

Done! Your state is now centralized, versioned, encrypted, and locked. Your team can collaborate safely.

You might wonder: if Terraform creates the bucket and table... where is the state for those resources stored before the backend exists? It’s a small circular dilemma. The usual solution:

1. Create the bucket and table with local state (no backend yet).
2. Once they exist, add the backend configuration and run init to migrate the state to S3.

Another option is to create these “base” resources manually once. In any case, it’s an initial step that’s only done once per organization.

• Local state doesn’t work for teams (it’s not shared and can be lost); you need a central, shared remote backend.
• The standard backend in AWS is S3 + DynamoDB: S3 stores the state file (durable, versioned, encrypted) and DynamoDB manages the lock so no one steps on each other’s toes.
• Configuration: create the S3 bucket (with versioning as a safety net) and the DynamoDB table (LockID key); then declare the backend "s3" with bucket, key (per-environment path), dynamodb_table, and encrypt = true.
• Use a different key per environment (produccion/..., dev/...) to separate states (strategy from subchapter 19.2).
• After configuring, terraform init migrates the state to the backend. The “base” resources (bucket and table) are created only once (with an initial step for the “chicken and egg” problem).

In the next subchapter we’ll dive deeper into the piece that makes teamwork safe: state locking and how it prevents state corruption.