CloudFormation vs Terraform: prueba práctica multi nube 2026

AWS CloudFormation y Terraform no serán una alternativa en abril de 2026, sino una elección secuencial. Quienes toman Multi-Cloud en serio, utilizarán Terraform para la plataforma y CloudFormation para la profundidad de AWS. Si se reordena esto, se construirán precisamente las deudas de migración que se querían evitar.

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

¿Qué diferencia realmente Terraform y CloudFormation en 2026?

Ambas herramientas hacen el mismo promiso: infraestructura como código, declarativa, idempotente y versionable. Antes de comparar, vamos a resumir las bases.

¿Qué es Infraestructura como Código? Un modelo en el que servidores, redes, bases de datos y roles de IAM no se crean más 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 aplicaciones, se integran en pipelines de CI y producen entornos reproducibles. Sin IaC, nadie puede asegurar por qué un entorno de staging se vea diferente al de producción.

En el sector medio de los países de la UE, he estado escuchando la misma pregunta durante dos años: «¿Cuál deberíamos 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 resuelve esto antes de elegir la herramienta, evita discusiones en los próximos dos años.

CloudFormation es un componente nativo de AWS. Nuevos servicios de AWS aparecen en el catálogo de recursos de CloudFormation al día de su lanzamiento. El proveedor de Terraform de AWS suele llegar alrededor de seis a diez días después, a veces semanas. Quien necesita tener recursos de Bedrock Agent o las instancias EC2 C8in lanzadas en abril de 2026 en código al día del lanzamiento, tiene un vencedor claro con CloudFormation. En el día a día de una empresa de consultoría, esto es relevante. En el sector medio, es raro.

Terraform destaca por su amplia gama de proveedores. Un catálogo de más de 4.500 proveedores cubre no solo Azure y GCP, sino también Cloudflare, Datadog, GitHub, Okta, Snowflake. Quien quiere codificar identidad, monitoreo o configuraciones de edge sin aprender una nueva lenguaje por cada stack, no tiene una alternativa real. La cambio de licencia a BSL en agosto de 2023 llevó a la desconexión de OpenTofu. Ambos forks están listos para producción y API-compatibles en abril de 2026. OpenTofu es mantenido por la Linux Foundation, mientras que Terraform sigue bajo la dirección de HashiCorp y IBM.

La tabla explica por qué hay diferencias, pero no por qué la discusión a menudo se desvía. Oculta dos puntos cruciales 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 económicos con CloudFormation, ya que hay menos que aprender. Con Terraform, es más costoso, ya que hay más formas de equivocarse.

¿Dónde CloudFormation gana, dónde Terraform pierde?

Durante el análisis práctico con tres equipos de nube de la región DACH del último cuarto, los mismos argumentos se han repetido una y otra vez. Estos argumentos fueron menos ideológicos que lo que parece en línea. Un conglomerado de maquinaria con 4.500 empleados, un seguros en el sur de Alemania y un proveedor de SaaS con 80 ingenieros. Tres estadios de madurez muy diferentes, tres puntos de dolor muy similares.

Una observación de los comentarios: Los equipos de CloudFormation suelen subestimar la rapidez con la que una «quizás Azure en el futuro» se convierte en una demanda sólida. Inmediatamente después que Ventas incluya una cláusula de Multi-Cloud en un contrato de gran cliente, la estrategia de IaC es el último domino que cae. Quien sigue siendo solo CloudFormation, escribe scripts paralelos para Azure sin una abstracción limpia. Eso es exactamente el tipo de operación mixta que nadie quiere.

En contraste, los equipos de Terraform suelen subestimar la carga de mantenimiento del backend del estado. Un bucket de S3 con una tabla de bloqueo de DynamoDB, replicado regionalmente, con versionado y cifrado de KMS, parece simple. Hasta que un archivo de estado entre dos ejecuciones de CI produce una condición de carrera y nadie sabe más qué salida de plan se ha aplicado realmente. Eso he visto más de una vez como la configuración predeterminada. Hoy la recomendación es clara: un bloqueo por espacio de trabajo, un espacio de trabajo por ejecución de CI, y un snapshop automático del archivo de estado antes de cada aplicación.

En el conglomerado de maquinaria, exactamente eso sucedió. Una ejecución de la cadena de entrega con dos ramas paralelas, ambas sobre el mismo archivo de estado. La segunda ejecución sobreescribió el estado del primero, y una instancia de RDS resultó desconocida en Terraform, pero existía en AWS. Tres días de limpieza de deriva, dos tickets, un informe de estado incómodo en el comité de dirección. Si la segunda ejecución hubiera tenido su propio espacio de trabajo, habría sido una tarea de diez minutos.

El proveedor de SaaS de la muestra tuvo el caso contrario. Comenzaron con CloudFormation y han escalado el stack a través de tres años. Luego llegó la solicitud de provisionar cuentas de Snowflake de manera programática. Sin un proveedor de Terraform, no había una solución limpia. La solución fue una Lambda que hace llamadas a la API de Snowflake y se activa desde el stack de CloudFormation. Funciona, pero ya no es IaC. Es código de pegamento con sellos de stack. Quien está en esta situación, ha elegido la herramienta demasiado tarde.

Multi-Cloud realidad en la práctica DACH

En los tres entornos de práctica que he analizado para este chequeo, he notado una constante: nadie usa solo uno de los dos. Las arquitecturas de multi-cloud que se ejecutan de manera productiva combinan Terraform para la capa de plataforma y CloudFormation para las operaciones específicas de AWS. La definición de capas es la clave. El que tenga la definición escrita, sueña mejor.

Concretamente, se ve así: Terraform define VPCs, subredes, roles de IAM, confianza entre cuentas, clusters de EKS, configuración de DNS de Cloudflare y configuración de monitores de Datadog. CloudFormation se encarga de lo que necesita los macros de servicio propios de AWS: provisionamiento del catálogo de servicio, planes de copia de seguridad de AWS con reglas de ciclo de vida complejas, estrategias de despliegue de AppConfig. La transición se realiza a través de salidas de Terraform que se alimentan a un stack de CloudFormation como parámetros de SSM. Este patrón se ha impuesto en la práctica en 2026 porque une ambos mundos sin contratiempos.

La constante: el manejo del estado se mantiene claramente separado por capa. El estado de Terraform se encuentra en un bucket de S3 por cuenta y región. Los stacks de CloudFormation tienen su propia administración de estado en el lado del servicio. Ambos mundos se orquestan a través de pipelines de CI que saben la secuencia: primero plataforma, luego carga de trabajo, luego macros. Quien las reordena construye stacks que hacen referencia a recursos no existentes.

Una segunda lección práctica: el manejo de desplazamientos es la parte invisible de los costos. El detector de desplazamientos de CloudFormation está integrado y notifica las diferencias de configuración por recurso. En Terraform, en la mayoría de los entornos, un trabajo de plano recurrente en la CI genera tickets de desplazamiento cuando se detectan. Ambos enfoques funcionan, pero solo uno está documentado de manera consistente. Quien ha buscado una modificación en la consola que invalida un archivo de estado, sabe el valor de un informe de desplazamiento.

En el chequeo del asegurador, el manejo de desplazamientos fue la clave para que la verificación de cumplimiento fuera posible. El auditor externo requería un stack verificado para cada recurso productivo. Con el informe de desplazamiento nativo de CloudFormation, se logró en dos horas. En el lado de Terraform, tardó una semana hasta que driftctl categorizara las recursos no administradas. Ambos enfoques funcionaron, pero el esfuerzo fue desequilibrado.

Una tercera observación práctica se refiere al tema de la reutilización de módulos. En el grupo de empresas de maquinaria, siete unidades de negocio trabajaron en paralelo en clusters de EKS. Sin un módulo de Terraform compartido, cada unidad tenía su propio código de cluster con diferencias mínimas. El equipo de plataforma invertió un mes en construir un módulo de EKS centralizado con variables de entrada claras y defaults sensibles. Tras tres meses, todas las unidades se movieron, el costo de mantenimiento se redujo a un tercio. Con CloudFormation, el mismo patrón funcionaría, pero el ecosistema de módulos es más restringido y el pool común de componentes reutilizables es más pequeño.

Lo que los arquitectos deben decidir hasta Q3 2026

Tres movimientos del mercado hacen que la pregunta sobre las capas en 2026 sea más urgente, no menos. HashiCorp fue adquirido por IBM en febrero de 2024. El proceso de transición se extenderá hasta 2027 y afectará la hoja de ruta de precios de HCP. OpenTofu se ha establecido como un proyecto de la Fundación Linux y se considerará un reemplazo drop-in con su propio registro de módulos en 2026. AWS lanzará CloudFormation Hooks en abril de 2026, que incorporarán chequeos de desfase y cumplimiento en cada ciclo de vida de la pila. Estos tres movimientos surgirán en cada revisión de arquitectura de los próximos dos cuartos.

Quien no tiene una definición escrita de la capa para 2026 debe escribirla ahora. No como una regla de arquitectura, sino como una ayuda para la toma de decisiones para cada nuevo módulo: ¿qué capa, qué herramienta, qué administración de estado. Esto evita las discusiones recurrentes sobre si un nuevo servicio se debe implementar en CloudFormation o Terraform. Facilita el onboarding de nuevos ingenieros de plataforma en días, no en semanas.

Tres pasos concretos que se han probado como una secuencia en los setup de práctica. Primero: escribir un mapping de capa unidireccional que clare el herramienta responsable para cada tipo de recurso. Segundo: unificar el backend de estado por cuenta y región, con una convención clara de workspace. Tercero: anexar un trabajo de informe de desfase a la CI que genere automáticamente tickets en caso de desviaciones. Estos tres pasos se pueden implementar en dos semanas y evitarán completamente la próxima reunión de revisión de arquitectura.

Lo que no pertenece a esta secuencia: una migración de herramientas sin un desencadenante. Quien quiera cambiar de CloudFormation a Terraform solo por la higiene del código, sin una demanda de multi-nube en el fondo, se quemará tres cuartos de tiempo de ingeniería en un refactor que nadie necesita. La discusión más honesta en cada revisión de arquitectura de los próximos dos cuartos será entonces la pregunta sobre el desencadenante concreto, no la pregunta sobre la herramienta concreta.

Preguntas frecuentes

Fuente de la imagen del título: Pexels / Kampus Production (px:8353774)