Prevenir y corregir el drift de infraestructura en Terraform para Azure

By Mirko Peters · 2026-10-28

Aprende cómo se produce el drift de infraestructura en Terraform y Azure, cómo los hotfixes de emergencia en el portal rompen los archivos de estado y cómo detectar y corregir las discrepancias de forma segura.

Automatically translated with AI from the original post. Read the English original

El drift de infraestructura es uno de los asesinos silenciosos más comunes y peligrosos en los entornos de nube modernos. Cuando los ingenieros hacen ajustes manuales directamente en el portal de Azure durante una emergencia, sus acciones rompen en silencio la sincronización con los repositorios de código. Esta guía completa explica cómo se produce el drift, los riesgos que supone para tus archivos de estado y cómo detectar y corregir las discrepancias de forma sistemática sin provocar interrupciones en producción.

Puntos clave

• El drift de infraestructura se produce cuando las modificaciones manuales en la consola de la nube se desvían del código de Terraform que has declarado.
• Los hotfixes de emergencia realizados directamente en producción eluden el control de versiones y generan fallos silenciosos en futuras ejecuciones normales del plan.
• Los archivos de estado de Terraform actúan como el puente de memoria que compara tu configuración escrita, el estado anterior y los recursos reales de la nube.
• Detectar el drift a tiempo requiere ejecutar planes automatizados con regularidad y una política estricta contra los cambios manuales en el portal no documentados.
• Resolver el drift implica decidir si llevas el entorno real de vuelta al código o si actualizas tu configuración para que coincida con la realidad.

¿Qué es el drift de infraestructura y por qué se produce?

Incluso los equipos de ingeniería de nube más disciplinados acaban sufriendo drift de infraestructura. El drift se define como cualquier cambio no autorizado, no documentado o de emergencia realizado en recursos de nube que gestiona un estado fuera de tus pipelines automatizados. Imagina un escenario en el que un ingeniero recibe un aviso durante un incidente nocturno. Bajo presión, entra en la consola de Azure, escala un límite de escalado automático de cinco instancias a diez, resuelve el problema y se va a descansar.

El problema es que el archivo de configuración versionado en tu repositorio sigue indicando cinco. El entorno de nube real indica diez. Como nadie documentó el cambio ni actualizó el código, se forma una enorme desconexión entre la arquitectura prevista y la realidad. Esta brecha permanece oculta durante semanas, hasta que alguien ejecuta un plan rutinario de Terraform para una actualización completamente distinta. De repente, la salida de la terminal muestra una advertencia: Terraform pretende volver a reducir esas instancias a cinco.

El factor humano y la presión operativa

El drift rara vez es malintencionado; casi siempre nace de la urgencia operativa. Cuando los entornos de producción fallan, el instinto humano lleva a los ingenieros a corregir el problema de inmediato con las herramientas más rápidas. El aprovisionamiento point-and-click en el portal de Azure es rápido, tangible e inmediato. Sin embargo, cada vez que un ingeniero usa el portal para parchear un problema sin registrarlo en el código, genera deuda técnica que tendrá que pagarse más adelante con intereses.

Cómo el estado de Terraform identifica las discrepancias

Para entender cómo Terraform detecta el drift, hay que observar de cerca su mecanismo de memoria: el archivo de estado. El archivo de estado de Terraform actúa como la fuente de verdad definitiva, asociando tus recursos de nube con tus archivos de configuración. Cuando ejecutas un comando, Terraform no se limita a enviar archivos a la nube a ciegas. En cambio, realiza una comparación de tres vías.

Primero, lee lo que has escrito en tus archivos de configuración. Segundo, inspecciona lo que registró en el archivo de estado durante la última aplicación correcta. Tercero, consulta la API del proveedor de nube mediante plugins y comprueba qué existe realmente en tu suscripción en este momento. Cuando estos tres elementos no coinciden, Terraform reconoce que la realidad ha cambiado en silencio.

El peligro de las advertencias ignoradas

Durante la ejecución de un plan, Terraform genera una salida detallada que muestra las adiciones, las actualizaciones y las eliminaciones. Cuando hay drift, a menudo verás advertencias que indican que un recurso debe modificarse o incluso reemplazarse por completo. Los principiantes suelen entrar en pánico al ver advertencias sobre reemplazos forzados de recursos. Esta advertencia no es un error: es Terraform indicándote que el recurso real ha cambiado hasta resultar irreconocible y que, para volver a alinearlo con tu código, debe destruirse y volver a crearse.

Buenas prácticas para detectar y prevenir el drift

Prevenir el drift requiere una combinación de barreras culturales y controles técnicos automatizados. Si dejas la detección de drift totalmente en manos de comprobaciones manuales, inevitablemente sufrirás caídas dolorosas en producción. Estas son las estrategias fundamentales que usan los equipos para mantener sus entornos de nube alineados:

• Aplica acceso de solo lectura: Quita los permisos de escritura en producción a los usuarios humanos. Obliga a que todos los cambios de infraestructura pasen por tus pipelines de CI/CD y por las revisiones de pull requests.
• Programa ejecuciones automáticas de plan: Configura pipelines de integración continua para ejecutar con regularidad comandos de 'terraform plan' sin aplicarlos. Revisa la salida en busca de modificaciones inesperadas.
• Divide los archivos de estado monolíticos: Separa los entornos grandes en componentes más pequeños y modulares. Los archivos de estado más pequeños facilitan aislar, revisar y corregir el drift.
• Implementa el bloqueo de estado remoto: Asegúrate de que tu equipo utilice backends remotos seguros con bloqueo de estado para evitar que las ejecuciones concurrentes corrompan los registros de estado.

Cómo corregir el drift cuando se produce

Cuando descubres que tu infraestructura real se ha desviado de tu configuración, te enfrentas a una bifurcación estratégica. Tienes dos caminos principales para corregirlo:

La primera opción es dejar que Terraform sobrescriba el entorno real. Al ejecutar tu 'terraform apply' habitual, obligas a Azure a volver al estado descrito en tu código. Este es el camino correcto cuando el drift fue causado por un cambio manual no autorizado o por una configuración temporal de depuración que ya no debería existir.

La segunda opción es actualizar tu configuración de Terraform para que coincida con la realidad. Elige este camino cuando la corrección manual realizada durante un incidente resultó ser necesaria, estable y beneficiosa para producción. Al actualizar tu código para reflejar la nueva realidad, cierras la brecha y garantizas que las futuras ejecuciones automáticas conserven la configuración necesaria.

Conclusión

El drift de infraestructura es un desafío inevitable en los entornos de nube dinámicos, pero no tiene por qué ser un desastre para tu equipo. Si entiendes cómo el archivo de estado de Terraform registra los cambios, implementas controles de acceso estrictos y tratas la detección de drift como un hábito operativo regular, podrás mantener el control absoluto sobre tu arquitectura en la nube. Para explorar en más detalle los mecanismos fundamentales de la infraestructura como código, los proveedores y la gestión del estado, escucha el episodio completo y descubre todas las perspectivas de expertos para llevar tu automatización en la nube al siguiente nivel.

Preguntas frecuentes

¿Qué causa el drift de infraestructura en Terraform?

El drift lo causan los cambios fuera de banda realizados directamente sobre los recursos de la nube mediante portales, comandos de CLI o scripts que omiten el pipeline de Terraform.

¿Cómo detecta Terraform el drift de configuración durante una ejecución de plan?

Terraform compara el archivo de estado almacenado con los recursos reales de la nube, consultados mediante las API de los proveedores, y con tus archivos de configuración locales.

¿Qué ocurre si alguien cambia manualmente un recurso de Azure gestionado por Terraform?

La próxima vez que se ejecute un plan de Terraform, detectará la discrepancia e intentará revertir el recurso para que coincida con el código declarado, a menos que se actualice la configuración.

¿Debo actualizar mi código de Terraform o revertir el cambio en el portal de Azure?

Si el cambio manual fue un hotfix de emergencia que ahora es necesario para la estabilidad, actualiza tu configuración de Terraform. Si fue una modificación no autorizada o accidental, deja que Terraform la revierta.