En el Capítulo 11 vimos por encima el estado remoto. Ahora vamos a profundizar, porque es uno de los pilares del trabajo en equipo con Terraform. En este subcapítulo configuraremos el backend más usado del mundo AWS: S3 + DynamoDB. S3 guarda el estado, y DynamoDB se encarga del «locking» (bloqueo) para que varias personas no se pisen. Veámoslo paso a paso.

Recuerda del subcapítulo 11.3 el problema del estado local: si el archivo terraform.tfstate está en tu portátil, tu equipo no puede colaborar (cada uno tendría su propia copia), y si pierdes el archivo, pierdes el control de tu infraestructura. La solución es guardar el estado en un sitio central y compartido: un backend remoto.

El backend estándar en AWS combina dos servicios que ya conoces, cada uno con un papel:

• S3 (Capítulo 5): almacena el archivo tfstate. Es duradero, está versionado y cifrado.
• DynamoDB (subcapítulo 8.3): gestiona el bloqueo para evitar que dos personas modifiquen el estado a la vez (lo veremos a fondo en el subcapítulo 20.2).

Estos dos recursos son los «cimientos» que deben existir antes de configurar el backend. Se suelen crear una sola vez:

Fíjate en dos detalles importantes:

• El versionado del bucket (recuerda el subcapítulo 5.3) guarda el historial del estado. Si algo sale mal, puedes volver a una versión anterior. Es una red de seguridad valiosísima.
• La tabla de DynamoDB usa una clave LockID: ahí es donde Terraform escribe el «cerrojo» cuando alguien está trabajando.

Una vez existen el bucket y la tabla, configuras tu proyecto para que use ese backend. Esto se hace en el bloque terraform:

Repasemos cada línea:

• bucket: el bucket de S3 donde se guarda el estado.
• key: la ruta del archivo dentro del bucket. Fíjate en produccion/...: usar una ruta distinta por entorno es clave para la estrategia de directorios (subcapítulo 19.2). Cada entorno tiene su propio estado separado.
• dynamodb_table: la tabla que gestiona los bloqueos.
• encrypt = true: cifra el estado en reposo. Importante, porque el estado puede contener datos sensibles (subcapítulo 11.2).

Tras configurar el backend, ejecutas terraform init (subcapítulo 11.4). Terraform detecta el backend y, si ya tenías estado local, te pregunta si quieres migrarlo al remoto:

¡Listo! Tu estado ya está centralizado, versionado, cifrado y con bloqueo. Tu equipo puede colaborar de forma segura.

Quizá te preguntes: si Terraform crea el bucket y la tabla... ¿dónde se guarda el estado de esos recursos antes de que el backend exista? Es un pequeño dilema circular. La solución habitual:

1. Creas el bucket y la tabla con estado local (sin backend todavía).
2. Una vez existen, añades la configuración del backend y haces init para migrar el estado a S3.

Otra opción es crear estos recursos «base» manualmente una vez. En cualquier caso, es un paso inicial que solo se hace una vez por organización.

• El estado local no sirve para equipos (no se comparte y se puede perder); necesitas un backend remoto central y compartido.
• El backend estándar en AWS es S3 + DynamoDB: S3 guarda el archivo de estado (duradero, versionado, cifrado) y DynamoDB gestiona el bloqueo (lock) para que nadie se pise.
• Configuración: crea el bucket S3 (con versionado, como red de seguridad) y la tabla DynamoDB (clave LockID); luego declara el backend "s3" con bucket, key (ruta por entorno), dynamodb_table y encrypt = true.
• Usa una key distinta por entorno (produccion/..., dev/...) para separar los estados (estrategia del subcapítulo 19.2).
• Tras configurarlo, terraform init migra el estado al backend. Los recursos «base» (bucket y tabla) se crean una sola vez (con un paso inicial para el «huevo y la gallina»).

En el siguiente subcapítulo profundizaremos en la pieza que hace seguro el trabajo en equipo: el state locking y cómo evita la corrupción del estado.