La Deriva de Infraestructura Nunca Se Fue. Ahora Hay Agentes Que la Persiguen.

Infraestructura como código (IaC) tenía una promesa simple: lo que está en el repositorio es lo que corre en producción. Una década después, esa promesa sigue sin cumplirse del todo. La deriva — cuando el estado real de la infraestructura se separa del código que supuestamente lo describe — sigue siendo, según HashiCorp, uno de los riesgos operativos más persistentes en entornos cloud.

Por qué la deriva nunca desapareció#

La causa no es técnica, es operativa. La deriva ocurre cuando alguien cambia infraestructura fuera del flujo de IaC — casi siempre por una buena razón. Durante un incidente de "romper el cristal", los equipos de respuesta a veces deciden saltarse los procedimientos estándar para arreglar el problema lo más rápido posible, y ese tipo de atajos generan cambios en los recursos difíciles de rastrear y resolver en el código.

El problema no es solo de higiene de código. La deriva no reconocida crea múltiples riesgos de seguridad que hay que resolver antes de que se conviertan en problemas reales, aumentando la probabilidad de exposiciones de datos críticos por sistemas dejados accidentalmente abiertos al acceso público. Y no es solo seguridad: también es dinero. Los cambios temporales de infraestructura pueden pasar desapercibidos, costando miles de dólares mensuales en aprovisionamiento innecesario.

Lo nuevo: agentes que no solo alertan, actúan#

Durante años, la respuesta a la deriva fue el mismo patrón: un job programado revisa el estado, genera un reporte, y alguien en el equipo tiene que leerlo, priorizarlo y decidir qué hacer. Eso cambió con la llegada de agentes operativos con capacidad de ejecutar tareas completas sin supervisión constante. AWS DevOps Agent, lanzado en preview a finales de 2025 y disponible en general desde marzo de 2026, es el ejemplo más visible.

Lo interesante no es que detecte deriva — eso ya existía. Es cómo lo hace. El prompt para el caso de uso típico es literalmente: "Crea un agente que revise los recursos de producción en AWS en busca de desviaciones de nuestros estándares de infraestructura (cifrado, aislamiento de red, etiquetado, manejo de credenciales y observabilidad) y genere recomendaciones para cualquier cosa fuera de cumplimiento." El equipo describe la regla de negocio en lenguaje natural; el agente la traduce en una verificación recurrente.

• Detecta: compara la infraestructura real contra las políticas definidas, no solo contra un archivo de estado estático.
• Documenta: para cada hallazgo, crea una recomendación con el recurso afectado, el estado actual frente al esperado, y una remediación sugerida.
• Evita el ruido duplicado: actualizar una recomendación existente en lugar de crear una duplicada mantiene limpio el backlog y muestra si un problema es nuevo, continuo o resuelto.
• Se programa como cualquier otro job: soporta expresiones cron compatibles con EventBridge, corriendo por ejemplo cada lunes antes de la revisión operativa semanal.

El resultado, según AWS, es que desde ahí, el mismo hallazgo se convierte en acción — aterriza como un ticket, una notificación o un traspaso al equipo responsable, en lugar de convertirse en otro reporte para leer. Es la diferencia entre un dashboard que nadie revisa y un flujo que efectivamente cierra el ciclo.

El otro lado de la moneda: más superficie, más gobernanza necesaria#

Mientras la capa de detección se automatiza, la capa de cambio se vuelve más compleja, no menos. El proveedor de Terraform para AWS — el puente entre el código y la API real de AWS — sigue creciendo a un ritmo notable. La versión v6.62.0, publicada en agosto de 2026, agregó soporte para nuevos recursos en servicios como Amazon DSQL, ECS, ECR, SES y Pinpoint, junto con mejoras adicionales en Bedrock AgentCore, CloudFront, ElastiCache, Resilience Hub y Secrets Manager.

Ese ritmo de crecimiento no es gratuito. Las actualizaciones del proveedor pueden afectar esquemas, valores por defecto, estado y comportamiento de los recursos, y el retiro de la versión v6.57.0 a principios de 2026 demostró que incluso una herramienta de infraestructura madura puede introducir riesgo de actualización. En ese incidente concreto, un error en la versión obligó a HashiCorp a retirarla del registro y recomendar temporalmente fijar la versión anterior mientras publicaban un parche.

Para equipos empresariales, el versionado de proveedores debería tratarse como gestión de dependencias de aplicación: fijar versiones, probar actualizaciones, revisar changelogs y promover cambios a través de entornos controlados en lugar de consumir automáticamente cada nueva versión.

Terraform y OpenTofu: la competencia no resuelve la gobernanza#

Vale la pena situar esto en contexto. Desde que OpenTofu se separó de Terraform en 2023 tras el cambio de licencia de HashiCorp, ambos proyectos han competido de cerca en funcionalidad — y en 2026 esa carrera sigue activa. Terraform 1.15 cerró brecha con capacidades como fuentes de módulo dinámicas, pero como señala InfoQ, algunas de sus funciones más destacadas ya estaban disponibles en el fork de código abierto OpenTofu desde hace casi dos años. OpenTofu 1.12, por su parte, resolvió una solicitud de la comunidad con casi una década de antigüedad, cableando prevent_destroy a una variable — algo que Terraform aún no ofrece de forma nativa.

La conclusión práctica para una empresa no es "cuál herramienta gana". Ya cubrimos ese terreno al comparar AWS CDK contra sus alternativas. La conclusión aquí es distinta: más opciones y más features no reducen la carga de gobernanza — la desplazan. Cada nueva capacidad (cifrado de estado nativo, políticas como código, agentes de detección) es una herramienta más que alguien en el equipo tiene que configurar, mantener y auditar con criterio.

Qué significa esto para una empresa con infraestructura en producción#

Los agentes de detección de deriva no eliminan la necesidad de un proceso de cambio. La hacen más visible. Un agente que revisa cifrado, aislamiento de red y etiquetado cada lunes solo es útil si alguien ya definió qué significa "correcto" para esa infraestructura en particular, y si existe un flujo real que convierta cada hallazgo en una acción cerrada — no en otro reporte acumulado sin dueño.

Eso es exactamente donde entra la diferencia entre tener herramientas y tener un sistema. Un equipo que ya gestiona infraestructura como código en AWS con criterios de gobernanza claros — versionado disciplinado de proveedores, políticas explícitas, y ownership continuo del pipeline — puede aprovechar estos agentes como una capa adicional de vigilancia. Un equipo sin esos criterios simplemente automatiza el ruido a mayor velocidad.

Resolver eso operativamente — no como un proyecto de una sola vez, sino como una función que alguien posee de forma continua — es exactamente el tipo de trabajo que separa una infraestructura que se mantiene sola sobre el papel de una que realmente se mantiene sola en producción. Nuestro trabajo con AWS en plataformas como Multimedios parte de esa misma premisa: la infraestructura como código vale lo que vale la disciplina operativa alrededor de ella.