En el subcapítulo anterior añadimos una tabla de DynamoDB a nuestro backend «para el locking». Ahora vamos a entender bien qué es el state locking y por qué es imprescindible cuando varias personas trabajan sobre la misma infraestructura. Es la pieza que evita uno de los peores desastres posibles con Terraform: la corrupción del estado.

Recuerda que el estado (Capítulo 11) es el archivo que registra qué recursos existen y cómo se relacionan. Es la «fuente de la verdad» de Terraform. Ahora imagina esta situación en un equipo:

Si ambos modifican el estado al mismo tiempo, sus cambios se mezclan y se corrompen. El archivo de estado puede quedar inconsistente: registros a medias, recursos duplicados, o un estado que ya no refleja la realidad. Un estado corrupto es una pesadilla: Terraform pierde la noción de qué existe, y arreglarlo a mano es lento y peligroso.

Analogía: es como dos personas editando el mismo documento a la vez sin coordinación, cada una guardando encima de la otra. El resultado es un documento destrozado donde se pierden cambios y nada tiene sentido. Necesitas que, mientras uno edita, el otro espere su turno.

El state locking (bloqueo del estado) resuelve esto con una regla sencilla: mientras alguien está modificando el estado, nadie más puede hacerlo a la vez. Terraform pone un «cerrojo» (lock) antes de empezar a trabajar y lo quita al terminar.

Así, las operaciones se serializan: ocurren una detrás de otra, nunca a la vez. El estado nunca se corrompe por accesos simultáneos.

Aquí entra la tabla de DynamoDB que configuramos en el subcapítulo 20.1. Funciona como el «portero del cerrojo»:

1. Cuando alguien ejecuta apply (o plan), Terraform escribe un registro de bloqueo en la tabla DynamoDB (en la clave LockID).
2. Si otra persona intenta ejecutar Terraform, este comprueba la tabla, ve que ya hay un bloqueo activo y espera (o avisa de que está bloqueado).
3. Cuando el primero termina, Terraform borra el registro de bloqueo, liberando el cerrojo.

DynamoDB es ideal para esto porque garantiza operaciones atómicas y consistentes: dos personas no pueden «coger el cerrojo» a la vez; solo uno gana.

Si intentas ejecutar Terraform mientras otra persona tiene el cerrojo, verás un mensaje parecido a este:

Esto te dice quién tiene el bloqueo y desde cuándo. No es un error «malo»: es Terraform protegiéndote. Simplemente esperas a que la otra persona termine y vuelves a intentarlo.

La buena noticia: una vez configurado el backend con DynamoDB (subcapítulo 20.1), el locking funciona solo, sin que tengas que hacer nada. Terraform pone y quita el cerrojo automáticamente en cada operación. Tú simplemente trabajas con normalidad, y el sistema te protege por detrás.

Ocasionalmente, un bloqueo puede quedarse «pegado»: por ejemplo, si la conexión de alguien se corta a mitad de un apply, el cerrojo podría no liberarse. En esos casos raros, existe el comando terraform force-unlock para quitar el cerrojo manualmente:

⚠️ Úsalo con muchísimo cuidado. Antes de forzar el desbloqueo, asegúrate de que de verdad nadie está trabajando sobre el estado. Si fuerzas el desbloqueo mientras otra persona realmente está aplicando cambios, vuelves a arriesgarte a la corrupción que el locking pretendía evitar. Confirma siempre con tu equipo primero.

El state locking, junto con el estado remoto (subcapítulo 20.1), es lo que hace que Terraform sea seguro en equipo. Sin él, la colaboración sería una bomba de relojería: tarde o temprano dos personas coincidirían y corromperían el estado. Con él, decenas de personas pueden trabajar sobre la misma infraestructura sin miedo. Es la base, junto con el flujo de PR (subcapítulo 12.5), del trabajo profesional con Terraform.

• Si dos personas modifican el estado a la vez, este se corrompe (queda inconsistente), lo que es un desastre difícil de arreglar. Como dos personas editando el mismo documento sin coordinación.
• El state locking (bloqueo) evita esto: mientras alguien trabaja, pone un cerrojo que impide que otros modifiquen el estado a la vez. Las operaciones se serializan (una tras otra).
• Con el backend S3 + DynamoDB, el locking funciona automáticamente: Terraform escribe un registro de bloqueo en DynamoDB al empezar y lo borra al terminar.
• Si el estado está bloqueado, verás un mensaje indicando quién lo tiene; no es un error malo, es protección. Simplemente esperas.
• En casos raros de bloqueo «atascado», existe terraform force-unlock, pero úsalo con extremo cuidado y solo tras confirmar que nadie está trabajando.

En el siguiente subcapítulo veremos cómo mover el estado entre backends de forma segura, algo necesario cuando reorganizas o migras tu infraestructura.