Llegamos a uno de los conceptos más característicos —y al principio confusos— de Terraform: el estado (state). Es lo que hace que Terraform sea idempotente e inteligente, pero también una de las cosas que más problemas causa si no se entiende bien. Vamos a desmitificarlo por completo.

Recuerda el enfoque declarativo (subcapítulo 9.2): tú declaras lo que quieres y Terraform hace que la realidad coincida. Pero para eso, Terraform necesita responder a una pregunta crucial:

«¿Qué he creado ya, y qué falta o sobra?»

Sin una respuesta, Terraform no sabría si debe crear un recurso nuevo, modificar uno existente o no hacer nada. Necesita recordar qué recursos gestiona y cuál es su estado actual. Esa memoria es el fichero de estado.

El estado es un archivo (por defecto llamado terraform.tfstate) donde Terraform registra todos los recursos que gestiona y su información: qué creó, con qué IDs, con qué configuración.

Analogía: El estado es el inventario de Terraform. Es como la libreta donde un almacenero apunta todo lo que tiene: «tengo 3 servidores con estos IDs, 1 bucket llamado así, 2 subredes con estos rangos…». Sin esa libreta, no sabría qué hay ni qué cambió.

El archivo está en formato JSON y mapea lo que escribiste en tu código con los recursos reales en AWS:

Cada vez que ejecutas plan o apply, Terraform:

1. Lee el estado para saber qué cree que existe.
2. Consulta la realidad en AWS (qué hay de verdad).
3. Compara las tres cosas: tu código (lo deseado), el estado (lo que cree que hay) y la realidad (lo que hay).
4. Calcula las diferencias y decide qué crear, modificar o destruir.

Por esto el estado es esencial: es la referencia que permite a Terraform detectar cambios y ser idempotente.

El estado no es un archivo cualquiera. Tiene varias propiedades críticas:

Terraform confía en el estado para saber qué gestiona. Si el estado se pierde o se corrompe, Terraform «se olvida» de los recursos que creó y puede comportarse de forma peligrosa (intentar recrear cosas, o dejar recursos huérfanos que siguen costando dinero).

El estado puede incluir información sensible en texto plano: contraseñas de bases de datos, claves, datos privados de recursos. Por eso:

⚠️ Reglas de seguridad del estado:

• NUNCA subas el terraform.tfstate a un repositorio Git público (ni privado sin cifrar). Podrías filtrar secretos.
• Añade terraform.tfstate y *.tfstate.* a tu .gitignore siempre.
• Para equipos, guarda el estado en un backend remoto cifrado (subcapítulo 11.3).

El fichero de estado no debe modificarse manualmente. Está pensado para que Terraform lo gestione. Editarlo a mano puede corromperlo. Si necesitas manipularlo, hay comandos específicos (como terraform state mv, terraform state rm) hechos para ello.

El estado también ayuda a detectar el drift (recuerda el Capítulo 9): si alguien cambia algo manualmente en la consola de AWS, la realidad ya no coincide con el estado. La próxima vez que ejecutes plan, Terraform lo detectará y te avisará:

«Oye, este recurso ha cambiado fuera de Terraform. Tu código dice una cosa, pero la realidad es otra.»

Esto te permite reconciliar la situación: o ajustas tu código, o dejas que Terraform devuelva el recurso al estado declarado. Es una de las grandes ventajas de tener un estado.

Para que sepas que existen (los usarás más adelante):

• El estado (terraform.tfstate) es el inventario donde Terraform registra los recursos que gestiona y su información.
• Es esencial para que Terraform compare lo deseado (código), lo registrado (estado) y lo real (AWS), y así calcular los cambios. Es la base de la idempotencia.
• Es delicado: si se pierde o corrompe, Terraform «se olvida» de tus recursos. Trátalo con cuidado.
• Contiene datos sensibles: nunca lo subas a Git; añádelo al .gitignore y, en equipo, usa un backend remoto cifrado.
• No lo edites a mano: usa los comandos terraform state ... si necesitas manipularlo.
• El estado permite detectar el drift (cambios hechos manualmente fuera de Terraform).

En el siguiente subcapítulo veremos un tema clave para trabajar en equipo: el estado local vs remoto, y cómo guardarlo de forma segura y compartida con S3 y DynamoDB.