Cerramos la Parte V con un problema muy real que afecta a toda infraestructura gestionada con código: el drift (deriva o desviación). Ocurre cuando la infraestructura real deja de coincidir con lo que dice tu código. En este subcapítulo entenderás por qué pasa, por qué es peligroso, y cómo detectarlo y corregirlo automáticamente. Es la guinda de un flujo de Infraestructura como Código maduro.

Recuerda la idea central de Terraform: tu código describe cómo debe ser la infraestructura, y Terraform hace que la realidad coincida con él (Capítulo 9). El drift (deriva) es cuando la infraestructura real se desvía de lo que dice el código, sin que el código haya cambiado.

El código y la realidad ya no coinciden. Esa diferencia es el drift.

El drift aparece cuando alguien o algo modifica la infraestructura por fuera de Terraform:

• Cambios manuales: alguien entra en la consola de AWS y modifica un recurso «rápidamente» para resolver una urgencia (abre un puerto, cambia un tamaño...), sin actualizar el código.
• Otras herramientas o scripts que tocan los mismos recursos.
• Procesos automáticos de AWS que modifican algo (raro, pero posible).
• Autoescalado u otros sistemas que cambian el número de recursos.

El caso más común y peligroso: un cambio manual «de emergencia». A las 3 de la madrugada hay un incidente, alguien entra en la consola de AWS y cambia algo a mano para apagar el fuego, y luego se olvida de reflejarlo en el código. A partir de ahí, el código miente: ya no describe la realidad.

Analogía: el drift es como tener los planos de una casa que ya no coinciden con la casa real porque alguien tiró un tabique sin actualizar los planos. Si más adelante un constructor trabaja guiándose por los planos antiguos, puede provocar un desastre, porque la realidad es otra.

El drift socava toda la confianza en tu Infraestructura como Código:

• El código deja de ser la fuente de la verdad: ya no puedes confiar en que el código describe lo que hay de verdad.
• Sorpresas en el próximo apply: cuando alguien vuelva a aplicar Terraform, este intentará «corregir» el cambio manual (revertirlo a lo que dice el código), lo que puede romper lo que se arregló a mano, ¡o eliminar un parche de seguridad!
• Riesgos de seguridad ocultos: si el cambio manual abrió un puerto peligroso, el código no lo refleja, así que las revisiones de seguridad (Capítulo 21) no lo detectan. El agujero queda oculto.
• Pérdida de reproducibilidad: si recreas la infraestructura desde el código, no obtendrás lo que realmente había, porque el código está desactualizado.

La buena noticia es que detectar el drift es sencillo, porque Terraform ya sabe comparar el código con la realidad. Recuerda que terraform plan (subcapítulo 11.4) hace exactamente eso: compara código, estado y realidad. Si hay drift, el plan lo muestra:

La clave es no esperar a que alguien ejecute un plan por casualidad. La detección de drift automática consiste en ejecutar terraform plan periódicamente (por ejemplo, cada noche) de forma automática, y avisar si detecta diferencias:

Así, si alguien hizo un cambio manual, el equipo se entera al día siguiente, no semanas después cuando ya causó un problema. Plataformas como HCP Terraform (subcapítulo 22.3) ofrecen esta detección de drift integrada; también puedes montarla con un pipeline programado (recuerda los schedules de EventBridge, subcapítulo 15.3, o un cron en tu CI).

Detectar el drift es solo la mitad; luego hay que reconciliar (volver a alinear código y realidad). Hay dos formas, según qué cambio sea el «correcto»:

Si el cambio manual no debía hacerse, ejecutas terraform apply para que Terraform devuelva la infraestructura a lo que dice el código, eliminando la desviación.

Si el cambio manual era correcto (un ajuste que hay que mantener), entonces actualizas el código para que refleje ese cambio, y lo subes mediante un PR (subcapítulo 12.5). Ahora el código vuelve a ser la verdad.

Reconciliación automática: algunos equipos configuran que, ante ciertos drifts, el sistema revierta automáticamente al estado del código (opción A) sin intervención. Esto es potente para forzar que todo cambio pase por código, pero hay que usarlo con cuidado: revertir automáticamente un cambio que era un parche de emergencia legítimo podría reabrir un problema. Por eso muchos prefieren detección automática + decisión humana sobre cómo reconciliar.

El drift refuerza el mensaje central de toda la Infraestructura como Código: todos los cambios deben hacerse a través del código, nunca a mano. La detección de drift es la vigilancia que hace cumplir esa regla, avisando cuando alguien se la salta.

Ejemplo del mundo real: una empresa ejecuta detección de drift cada noche en producción. Una mañana, la alerta avisa: «el Security Group de la base de datos tiene el puerto 5432 abierto a internet, y no está en el código». Investigan: un desarrollador lo abrió a mano la tarde anterior para una prueba y se olvidó de cerrarlo. Gracias a la detección de drift, lo descubren en horas (no cuando un atacante lo encuentre) y lo corrigen. Sin esa vigilancia, ese agujero podría haber pasado meses desapercibido.

• El drift (deriva) es cuando la infraestructura real deja de coincidir con el código, normalmente por cambios manuales hechos por fuera de Terraform (el clásico parche de emergencia que no se refleja en el código).
• Es peligroso: el código deja de ser la fuente de la verdad, el próximo apply puede revertir cambios importantes, oculta riesgos de seguridad y rompe la reproducibilidad. Como unos planos que ya no coinciden con la casa.
• Se detecta con terraform plan (compara código y realidad); lo ideal es la detección automática y periódica (ej. cada noche) que alerta al equipo ante diferencias.
• Se reconcilia de dos formas: revertir el cambio manual con apply (si el código es la verdad) o actualizar el código vía PR (si el cambio manual era válido).
• La lección de fondo: todos los cambios deben hacerse por código; la detección de drift es la vigilancia que hace cumplir esa regla.

¡Has terminado el Capítulo 22 y la Parte V! Ya dominas Terraform a nivel avanzado: módulos, entornos, estado, testing y CI/CD. En la Parte VI cambiamos el foco hacia los aspectos transversales de AWS que distinguen a un profesional: empezaremos por la seguridad en profundidad.