8 Min. Tiempo de lectura · Fecha: Abril 2026

AWS CloudFormation y Terraform no son una alternativa en abril de 2026, sino una decisión de secuencia. Quien se toma en serio la multi-nube, utiliza Terraform para la plataforma y CloudFormation para las profundidades de AWS. Quien invierte esto, se construye exactamente las deudas de migración que quería evitar.

RelacionadoAWS Savings Plans vs. Reserved Instances 2026  /  Servicios de corretaje de nube y el informe de FinOps de abril de 2026

Qué distingue realmente a Terraform y CloudFormation en 2026

Ambos herramientas hacen la misma promesa: infraestructura como código, declarativa, idempotente y versionable. Antes de comparar, un breve repaso de los conceptos básicos.

¿Qué es la infraestructura como código? Un modelo en el que los servidores, las redes, las bases de datos y los roles de IAM ya no se crean mediante clics en una consola web, sino que se describen en archivos de texto. Estos archivos pasan por el mismo proceso de revisión que el código de la aplicación, pasan por las canalizaciones de CI y producen entornos reproducibles. Sin IaC, nadie puede decir con seguridad por qué un entorno de pruebas se ve diferente al de producción.

En las empresas medianas de la región DACH, he oído la misma pregunta durante dos años: «¿Cuál debemos elegir?» La pregunta está mal planteada. La pregunta correcta es: ¿cuál es nuestra estrategia de nube real? ¿Qué herramienta se adapta a qué capa? Quien aclare esto antes de elegir la herramienta se ahorrará la discusión en los próximos dos años.

CloudFormation es un componente nativo de AWS. Los nuevos servicios de AWS aparecen en el catálogo de recursos de CloudFormation el día de su lanzamiento. El proveedor de Terraform para AWS suele llegar entre seis y diez días después, ocasionalmente semanas. Quien necesite recursos de Bedrock Agent o las instancias EC2 C8i anunciadas en abril de 2026 en su código desde el primer día tiene una ventaja de velocidad medible con CloudFormation. Esto es relevante en el día a día de una empresa del DAX. En las empresas medianas, es raro.

Terraform juega su fuerza en la amplitud. Un catálogo de proveedores con más de 4.500 proveedores cubre no solo Azure y GCP, sino también Cloudflare, Datadog, GitHub, Okta, Snowflake. Quien quiera codificar configuraciones de identidad, monitoreo o borde sin aprender un lenguaje propio por pila no tiene una alternativa real. El cambio de licencia a BSL en agosto de 2023 llevó a la separación de OpenTofu. Ambos forks están listos para producción en abril de 2026 y son compatibles con la API. OpenTofu está alojado por la Fundación Linux, Terraform sigue bajo el paraguas de HashiCorp y ahora IBM.

La tabla explica por qué existen bandos, pero no por qué la discusión suele salir mal. Oculta dos puntos que son decisivos en las revisiones de arquitectura. ¿Quién asume el riesgo de gestión de estado? ¿Quién se encarga del onboarding de nuevos miembros del equipo? Ambos son más baratos en CloudFormation porque hay menos que saber. En Terraform es más caro porque se puede hacer más mal.

Donde CloudFormation gana, donde Terraform destaca

En la prueba práctica con tres equipos de nubes DACH del último trimestre, han surgido los mismos argumentos una y otra vez. Eran menos ideológicos de lo que internet hace creer. Un conglomerado de ingeniería mecánica con 4.500 empleados, un asegurador en el sur de Alemania y un proveedor de SaaS con 80 ingenieros. Tres niveles de madurez muy diferentes, tres puntos de dolor muy similares.

Una observación de las revisiones: los equipos de CloudFormation subestiman regularmente lo rápido que un «quizás más tarde Azure» se convierte en un requisito estricto. Tan pronto como las ventas incluyen una cláusula de multi-nube en un contrato con un cliente importante, la estrategia de IaC es el último dominó que cae. Quien entonces solo utiliza CloudFormation, escribe scripts paralelos para Azure sin una abstracción limpia. Ese es exactamente el funcionamiento mixto que nadie quiere.

Por el contrario, los equipos de Terraform subestiman la carga de mantenimiento del estado posterior. Un bucket de S3 con una tabla de bloqueo de DynamoDB, replicada regionalmente, con versión y cifrado KMS, suena simple. Hasta que un archivo de estado entre dos ejecuciones paralelas de CI produce una condición de carrera y nadie sabe qué salida de plan se aplicó realmente. Esto lo he dejado como predeterminado demasiadas veces. Hoy la recomendación es clara: un bloqueo por espacio de trabajo, un espacio de trabajo por trabajo de CI, una captura automática del archivo de estado antes de cada aplicación.

En el conglomerado de ingeniería mecánica sucedió exactamente eso. Una ejecución de la canalización con dos ramas paralelas, ambas en el mismo archivo de estado. La segunda ejecución sobrescribió el estado de la primera, una instancia de RDS era desconocida en Terraform, pero existía en AWS. Tres días de limpieza de deriva, dos tickets, un informe de estado vergonzoso en el comité de dirección. Si la segunda ejecución hubiera tenido su propio espacio de trabajo, habría sido cuestión de diez minutos.

Los proveedores de SaaS de la muestra han experimentado el caso contrario. Comenzaron con CloudFormation y elevaron la pila durante tres años. Luego llegó el requisito de aprovisionar programáticamente cuentas de Snowflake. Sin el proveedor de Terraform no había solución limpia. El puente era una Lambda que hace llamadas a la API de Snowflake y es activada por la pila de CloudFormation. Funciona, pero ya no es IaC. Es código de pegamento con una etiqueta de pila. Quien se encuentra en esta situación, ha tomado la elección de herramienta demasiado tarde.

Realidad de Multi-Cloud en la práctica DACH

En los tres escenarios prácticos que he examinado más de cerca para esta verificación, se ha destacado una constante: nadie utiliza solo uno de los dos. Las arquitecturas de Multi-Cloud en funcionamiento productivo combinan Terraform para la capa de plataforma y CloudFormation para profundidades específicas de AWS. La definición de capas es el truco completo. Quien la tenga por escrito, duerme mejor.

En concreto, se ve así: Terraform define VPCs, subredes, roles de IAM, confianza entre cuentas, clústeres de EKS, DNS de Cloudflare, configuraciones de monitoreo de Datadog. CloudFormation se encarga de lo que necesita el servicio de macros de AWS: aprovisionamiento del catálogo de servicios, planes de respaldo de AWS con reglas de ciclo de vida complejas, estrategias de implementación de AppConfig. La transición se realiza a través de salidas de Terraform, que se alimentan en una pila de CloudFormation como parámetros de SSM. El patrón se ha establecido en la práctica en 2026, porque conecta ambos mundos sin fricción.

El denominador común: la gestión del estado permanece claramente separada por capa. El estado de Terraform se encuentra en el bucket de S3 por cuenta y región. Las pilas de CloudFormation tienen su propia gestión de estado del lado del servicio. Ambos mundos se orquestan a través de canalizaciones de CI, que saben qué orden es válida: primero la plataforma, luego la carga de trabajo, luego las macros. Quien invierte esto, construye pilas que se refieren a recursos inexistentes.

Una segunda enseñanza práctica: la gestión del drift es el centro de costos invisible. La detección de drift de CloudFormation está integrada y reporta desviaciones de configuración por recurso. En Terraform, en la mayoría de los escenarios, un trabajo de planificación recurrente en la CI se hace cargo de esto, que genera tickets cuando hay drift. Ambos caminos funcionan. Pero solo uno está documentado de manera consistente. Quien alguna vez ha buscado un cambio de consola que ha invalidado un archivo de estado, conoce el valor de un informe de drift.

En el caso del asegurador de la verificación práctica, la gestión del drift fue la palanca que hizo posible la aceptación de cumplimiento. El auditor externo quería ver una referencia de pila verificada para cada recurso productivo. Con el informe de drift de CloudFormation nativo, esto se entregó en dos horas. En el lado de Terraform, tomó una semana hasta que driftctl categorizó correctamente los recursos no administrados. Ambos mundos funcionaron, pero el esfuerzo fue desigual.

Una tercera observación práctica se refiere al tema de la reutilización de módulos. En el caso del conglomerado de construcción de maquinaria, siete unidades de negocio trabajaron en paralelo en clústeres de EKS. Sin un módulo Terraform común, cada unidad tenía su propio código de clúster con desviaciones mínimas. El equipo de plataforma invirtió un mes en construir un módulo central de EKS, con variables de entrada claras y valores predeterminados significativos. Después de tres meses, todas las unidades fueron migradas, y el esfuerzo de mantenimiento se redujo a un tercio. Con CloudFormation, el mismo patrón habría funcionado, pero el ecosistema de módulos es más estrecho y el grupo común de bloques reutilizables es más pequeño.

Qué deben decidir los arquitectos antes de Q3 2026

Tres movimientos del mercado hacen que la cuestión de las capas sea más urgente en 2026, no menos. HashiCorp fue adquirida por IBM en febrero de 2024. La transición se lleva a cabo hasta 2027 y afecta la hoja de ruta de precios de HCP. OpenTofu se ha establecido como un proyecto de la Fundación Linux y se considera un reemplazo directo con su propio registro de módulos en 2026. AWS lanzó en abril de 2026 las CloudFormation Hooks GA, que integran comprobaciones de deriva y cumplimiento en cada ciclo de vida de la pila. Tres movimientos que aparecerán en cada revisión de la arquitectura de los próximos dos trimestres.

Quien no tenga una definición escrita de capas en 2026, debería escribirla ahora. No como una regulación de arquitectura, sino como una ayuda para la toma de decisiones para cada nuevo módulo: qué capa, qué herramienta, qué gestión de estado. Esto ahorra la discusión recurrente sobre si un nuevo servicio se coloca en CloudFormation o Terraform. Hace posible la incorporación de nuevos ingenieros de plataforma en días en lugar de semanas.

Tres pasos concretos que se han demostrado como una secuencia efectiva en las configuraciones prácticas. Primero: escribir un mapeo de capas de una página que aclare qué herramienta es responsable de cada tipo de recurso. Segundo: unificar el backend de estado por cuenta y región, con una convención clara de espacio de trabajo. Tercero: colgar un trabajo de informe de deriva en la CI que genere automáticamente tickets en caso de desviaciones. Estos tres pasos se pueden implementar en dos semanas y ahorran completamente la próxima reunión de revisión de la arquitectura.

Lo que no pertenece a esta secuencia: una migración de herramientas sin desencadenante. Quien quiera cambiar de CloudFormation a Terraform solo por higiene de código, sin requerimiento de multicloud en el fondo, desperdicia tres trimestres de tiempo de ingeniería en una refactorización que nadie mide. La discusión más honesta en cada revisión de la arquitectura de los próximos dos trimestres es, por lo tanto, la pregunta por el motivo concreto, no la pregunta por la herramienta concreta.

Preguntas frecuentes

¿Vale la pena cambiar de CloudFormation a Terraform en 2026?

Solo con un claro desencadenante de ingeniería de múltiples nubes o plataformas. Los stacks de AWS puros sin conexión SaaS se benefician poco del cambio y asumen la curva de aprendizaje y la carga de gestión de estado de nuevo. Quien tenga un contrato de múltiples nubes con grandes clientes en cartera, debería empezar en paralelo.

OpenTofu o Terraform con licencia BSL?

OpenTofu está listo para producción en 2026, compatible con API y alojado en Linux Foundation. Quien necesite claridad de licencia para cumplimiento o quiera compartir módulos sin riesgo de proveedor, está mejor posicionado con OpenTofu. La licencia BSL de HashiCorp sigue siendo no crítica para uso interno.

¿Cómo se resuelve la condición de carrera de estado entre ejecuciones paralelas de CI?

El bloqueo de estado de Terraform a través de DynamoDB es el estándar, OpenTofu utiliza el mismo esquema de backend. Un bloqueo por Workspace, un Workspace por trabajo de CI. Quien ejerce paralelismo de tuberías sin estrategia de bloqueo, se construye corrupción de estado.

¿Es suficiente el informe de deriva de CloudFormation o se necesita driftctl?

Para stacks de CloudFormation puros, el informe nativo es suficiente. Tan pronto como Terraform y CloudFormation se ejecutan en paralelo, vale la pena driftctl como segunda visión: también ve recursos no administrados que ningún stack conoce. Ambos se complementan, no se reemplazan.

¿Qué significa la adquisición de HashiCorp por IBM para la elección de herramientas?

Hasta 2027 se ejecuta el plan de integración, después se reorganizarán los modelos de precios y soporte. Terraform de código abierto y HCP seguirán disponibles hasta entonces. Quien conduce la independencia de proveedor como principio de arquitectura, debería evaluar OpenTofu.

Fuente de la imagen de portada: Pexels / panumas nikhomkhai (px:17489152)