8 minutos de lectura<\/p>\n
AWS CloudFormation y Terraform no ser\u00e1n una alternativa en abril de 2026, sino una elecci\u00f3n secuencial. Quienes toman Multi-Cloud en serio, utilizar\u00e1n Terraform para la plataforma y CloudFormation para la profundidad de AWS. Si se reordena esto, se construir\u00e1n precisamente las deudas de migraci\u00f3n que se quer\u00edan evitar.<\/strong><\/p>\n Lo m\u00e1s importante en resumen<\/p>\n Relacionado<\/span>AWS Savings Plans vs. Reserved Instances 2026<\/a> \/<\/span> Servicios de broker\u00eda de nube y el informe FinOps de abril 2026<\/a><\/p>\n Ambas herramientas hacen el mismo promiso: infraestructura como c\u00f3digo, declarativa, idempotente y versionable. Antes de comparar, vamos a resumir las bases.<\/p>\n \u00bfQu\u00e9 es Infraestructura como C\u00f3digo?<\/strong> Un modelo en el que servidores, redes, bases de datos y roles de IAM no se crean m\u00e1s mediante clics en una consola web, sino que se describen en archivos de texto. Estos archivos pasan por el mismo proceso de revisi\u00f3n que el c\u00f3digo de aplicaciones, se integran en pipelines de CI y producen entornos reproducibles. Sin IaC, nadie puede asegurar por qu\u00e9 un entorno de staging se vea diferente al de producci\u00f3n.<\/p>\n En el sector medio de los pa\u00edses de la UE, he estado escuchando la misma pregunta durante dos a\u00f1os: \u00ab\u00bfCu\u00e1l deber\u00edamos elegir?\u00bb La pregunta est\u00e1 mal planteada. La pregunta correcta es: \u00bfCu\u00e1l es nuestra estrategia de nube real? \u00bfQu\u00e9 herramienta se adapta a qu\u00e9 capa? Quien resuelve esto antes de elegir la herramienta, evita discusiones en los pr\u00f3ximos dos a\u00f1os.<\/p>\n CloudFormation es un componente nativo de AWS. Nuevos servicios de AWS aparecen en el cat\u00e1logo de recursos de CloudFormation al d\u00eda de su lanzamiento. El proveedor de Terraform de AWS suele llegar alrededor de seis a diez d\u00edas despu\u00e9s, a veces semanas. Quien necesita tener recursos de Bedrock Agent o las instancias EC2 C8in lanzadas en abril de 2026 en c\u00f3digo al d\u00eda del lanzamiento, tiene un vencedor claro con CloudFormation. En el d\u00eda a d\u00eda de una empresa de consultor\u00eda, esto es relevante. En el sector medio, es raro.<\/p>\n Terraform destaca por su amplia gama de proveedores. Un cat\u00e1logo de m\u00e1s de 4.500 proveedores cubre no solo Azure y GCP, sino tambi\u00e9n 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\u00f3 a la desconexi\u00f3n de OpenTofu. Ambos forks est\u00e1n listos para producci\u00f3n y API-compatibles en abril de 2026. OpenTofu es mantenido por la Linux Foundation, mientras que Terraform sigue bajo la direcci\u00f3n de HashiCorp y IBM.<\/p>\n Fuente: Gu\u00eda de Usuario de CloudFormation de AWS abril de 2026, Snapshot del Registro de Proveedores de HashiCorp 24 de abril de 2026<\/p>\n<\/div>\n La tabla explica por qu\u00e9 hay diferencias, pero no por qu\u00e9 la discusi\u00f3n a menudo se desv\u00eda. Oculta dos puntos cruciales en las revisiones de arquitectura: \u00bfQui\u00e9n asume el riesgo de gesti\u00f3n de estado? \u00bfQui\u00e9n se encarga del onboarding de nuevos miembros del equipo? Ambos son m\u00e1s econ\u00f3micos con CloudFormation, ya que hay menos que aprender. Con Terraform, es m\u00e1s costoso, ya que hay m\u00e1s formas de equivocarse.<\/p>\n Durante el an\u00e1lisis pr\u00e1ctico con tres equipos de nube de la regi\u00f3n DACH del \u00faltimo cuarto, los mismos argumentos se han repetido una y otra vez. Estos argumentos fueron menos ideol\u00f3gicos que lo que parece en l\u00ednea. 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.<\/p>\n CloudFormation gana<\/p>\n Terraform \/ OpenTofu pierde<\/p>\n Una observaci\u00f3n de los comentarios: Los equipos de CloudFormation suelen subestimar la rapidez con la que una \u00abquiz\u00e1s Azure en el futuro\u00bb se convierte en una demanda s\u00f3lida. Inmediatamente despu\u00e9s que Ventas incluya una cl\u00e1usula de Multi-Cloud en un contrato de gran cliente, la estrategia de IaC es el \u00faltimo domino que cae. Quien sigue siendo solo CloudFormation, escribe scripts paralelos para Azure sin una abstracci\u00f3n limpia. Eso es exactamente el tipo de operaci\u00f3n mixta que nadie quiere.<\/p>\n 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\u00f3n de carrera y nadie sabe m\u00e1s qu\u00e9 salida de plan se ha aplicado realmente. Eso he visto m\u00e1s de una vez como la configuraci\u00f3n predeterminada. Hoy la recomendaci\u00f3n es clara: un bloqueo por espacio de trabajo, un espacio de trabajo por ejecuci\u00f3n de CI, y un snapshop autom\u00e1tico del archivo de estado antes de cada aplicaci\u00f3n.<\/p>\n En el conglomerado de maquinaria, exactamente eso sucedi\u00f3. Una ejecuci\u00f3n de la cadena de entrega con dos ramas paralelas, ambas sobre el mismo archivo de estado. La segunda ejecuci\u00f3n sobreescribi\u00f3 el estado del primero, y una instancia de RDS result\u00f3 desconocida en Terraform, pero exist\u00eda en AWS. Tres d\u00edas de limpieza de deriva, dos tickets, un informe de estado inc\u00f3modo en el comit\u00e9 de direcci\u00f3n. Si la segunda ejecuci\u00f3n hubiera tenido su propio espacio de trabajo, habr\u00eda sido una tarea de diez minutos.<\/p>\n El proveedor de SaaS de la muestra tuvo el caso contrario. Comenzaron con CloudFormation y han escalado el stack a trav\u00e9s de tres a\u00f1os. Luego lleg\u00f3 la solicitud de provisionar cuentas de Snowflake de manera program\u00e1tica. Sin un proveedor de Terraform, no hab\u00eda una soluci\u00f3n limpia. La soluci\u00f3n 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\u00f3digo de pegamento con sellos de stack. Quien est\u00e1 en esta situaci\u00f3n, ha elegido la herramienta demasiado tarde.<\/p>\n En los tres entornos de pr\u00e1ctica 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\u00edficas de AWS. La definici\u00f3n de capas es la clave. El que tenga la definici\u00f3n escrita, sue\u00f1a mejor.<\/p>\n Concretamente, se ve as\u00ed: Terraform define VPCs, subredes, roles de IAM, confianza entre cuentas, clusters de EKS, configuraci\u00f3n de DNS de Cloudflare y configuraci\u00f3n de monitores de Datadog. CloudFormation se encarga de lo que necesita los macros de servicio propios de AWS: provisionamiento del cat\u00e1logo de servicio, planes de copia de seguridad de AWS con reglas de ciclo de vida complejas, estrategias de despliegue de AppConfig. La transici\u00f3n se realiza a trav\u00e9s de salidas de Terraform que se alimentan a un stack de CloudFormation como par\u00e1metros de SSM. Este patr\u00f3n se ha impuesto en la pr\u00e1ctica en 2026 porque une ambos mundos sin contratiempos.<\/p>\n 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\u00f3n. Los stacks de CloudFormation tienen su propia administraci\u00f3n de estado en el lado del servicio. Ambos mundos se orquestan a trav\u00e9s 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.<\/p>\n Una segunda lecci\u00f3n pr\u00e1ctica: el manejo de desplazamientos es la parte invisible de los costos. El detector de desplazamientos de CloudFormation est\u00e1 integrado y notifica las diferencias de configuraci\u00f3n por recurso. En Terraform, en la mayor\u00eda 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\u00e1 documentado de manera consistente. Quien ha buscado una modificaci\u00f3n en la consola que invalida un archivo de estado, sabe el valor de un informe de desplazamiento.<\/p>\n En el chequeo del asegurador, el manejo de desplazamientos fue la clave para que la verificaci\u00f3n de cumplimiento fuera posible. El auditor externo requer\u00eda un stack verificado para cada recurso productivo. Con el informe de desplazamiento nativo de CloudFormation, se logr\u00f3 en dos horas. En el lado de Terraform, tard\u00f3 una semana hasta que driftctl categorizara las recursos no administradas. Ambos enfoques funcionaron, pero el esfuerzo fue desequilibrado.<\/p>\n Una tercera observaci\u00f3n pr\u00e1ctica se refiere al tema de la reutilizaci\u00f3n de m\u00f3dulos. En el grupo de empresas de maquinaria, siete unidades de negocio trabajaron en paralelo en clusters de EKS. Sin un m\u00f3dulo de Terraform compartido, cada unidad ten\u00eda su propio c\u00f3digo de cluster con diferencias m\u00ednimas. El equipo de plataforma inverti\u00f3 un mes en construir un m\u00f3dulo 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\u00f3n funcionar\u00eda, pero el ecosistema de m\u00f3dulos es m\u00e1s restringido y el pool com\u00fan de componentes reutilizables es m\u00e1s peque\u00f1o.<\/p>\n \n”<\/span><\/p>\n AWS CloudFormation y Terraform en abril de 2026 ya no son alternativas, sino una elecci\u00f3n de ordenaci\u00f3n.<\/p>\n<\/blockquote>\n<\/figure>\n Tres movimientos del mercado hacen que la pregunta sobre las capas en 2026 sea m\u00e1s urgente, no menos. HashiCorp fue adquirido por IBM en febrero de 2024. El proceso de transici\u00f3n se extender\u00e1 hasta 2027 y afectar\u00e1 la hoja de ruta de precios de HCP. OpenTofu se ha establecido como un proyecto de la Fundaci\u00f3n Linux y se considerar\u00e1 un reemplazo drop-in con su propio registro de m\u00f3dulos en 2026. AWS lanzar\u00e1 CloudFormation Hooks en abril de 2026, que incorporar\u00e1n chequeos de desfase y cumplimiento en cada ciclo de vida de la pila. Estos tres movimientos surgir\u00e1n en cada revisi\u00f3n de arquitectura de los pr\u00f3ximos dos cuartos.<\/p>\n Quien no tiene una definici\u00f3n 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\u00f3dulo: \u00bfqu\u00e9 capa, qu\u00e9 herramienta, qu\u00e9 administraci\u00f3n 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\u00edas, no en semanas.<\/p>\n Tres pasos concretos que se han probado como una secuencia en los setup de pr\u00e1ctica. 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\u00f3n, con una convenci\u00f3n clara de workspace. Tercero: anexar un trabajo de informe de desfase a la CI que genere autom\u00e1ticamente tickets en caso de desviaciones. Estos tres pasos se pueden implementar en dos semanas y evitar\u00e1n completamente la pr\u00f3xima reuni\u00f3n de revisi\u00f3n de arquitectura.<\/p>\n Lo que no pertenece a esta secuencia: una migraci\u00f3n de herramientas sin un desencadenante. Quien quiera cambiar de CloudFormation a Terraform solo por la higiene del c\u00f3digo, sin una demanda de multi-nube en el fondo, se quemar\u00e1 tres cuartos de tiempo de ingenier\u00eda en un refactor que nadie necesita. La discusi\u00f3n m\u00e1s honesta en cada revisi\u00f3n de arquitectura de los pr\u00f3ximos dos cuartos ser\u00e1 entonces la pregunta sobre el desencadenante concreto, no la pregunta sobre la herramienta concreta.<\/p>\n S\u00f3lo con un claro desencadenante de Multi-Cloud o de Ingenier\u00eda de Plataformas. Stacks de AWS sin conexi\u00f3n a SaaS no se benefician mucho del cambio y tienen que incorporar la curva de aprendizaje y la carga de administraci\u00f3n de estado. Quien tiene un contrato de Multi-Cloud con grandes clientes en el pipeline debe comenzar en paralelo.<\/p>\n<\/details>\n OpenTofu estar\u00e1 listo para producci\u00f3n en 2026, compatible con la API y alojado por la Linux Foundation. Quien necesita claridad de licencia para cumplir con regulaciones o quiere compartir m\u00f3dulos sin riesgos de proveedor est\u00e1 mejor protegido con OpenTofu. La licencia BSL de HashiCorp sigue siendo inocua para el uso interno.<\/p>\n<\/details>\n El bloqueo de estado de Terraform a trav\u00e9s de DynamoDB es el est\u00e1ndar. OpenTofu utiliza el mismo esquema de back-end. Un bloqueo por espacio de trabajo y un espacio de trabajo por ejecuci\u00f3n de CI. Quien corre pipelines en paralelo sin estrategia de bloqueo incorpora la corrupci\u00f3n del estado.<\/p>\n<\/details>\n Para stacks de CloudFormation puras, el informe nativo es suficiente. Una vez que Terraform y CloudFormation corran en paralelo, driftctl como segunda vista vale la pena: detecta recursos no administrados que no est\u00e1n asociados a stacks. Ambos complementan, no reemplazan.<\/p>\n<\/details>\n Hasta 2027, el plan de integraci\u00f3n se ejecutar\u00e1 y despu\u00e9s los modelos de precios y soporte se espera que se reorganicen. Terraform de c\u00f3digo abierto y HCP estar\u00e1n disponibles hasta entonces. Quien lleva la independencia del proveedor como principio arquitect\u00f3nico debe evaluar OpenTofu.<\/p>\n<\/details>\n Recomendaciones de lectura de la redacci\u00f3n<\/p>\n M\u00e1s del MBF Media Netzwerk<\/p>\n\n
\u00bfQu\u00e9 diferencia realmente Terraform y CloudFormation en 2026?<\/h2>\n
\n\n
\n \nCriterio<\/th>\n CloudFormation<\/th>\n Terraform \/ OpenTofu<\/th>\n<\/tr>\n<\/thead>\n \n Coverage de Nube<\/strong><\/td>\n Solo AWS (incluyendo AWS Outposts, Local Zones)<\/td>\n 4.500+ proveedores, todos los hyperscalers<\/td>\n<\/tr>\n \n Soporte de D\u00eda Uno de Servicio<\/strong><\/td>\n D\u00eda 0 (nativo)<\/td>\n 6 a 21 d\u00edas de retraso t\u00edpico<\/td>\n<\/tr>\n \n Gesti\u00f3n de Estado<\/strong><\/td>\n Servicio-side en AWS, sin gesti\u00f3n de bloqueo<\/td>\n Alojado por s\u00ed mismo (S3+DynamoDB), HCP o OpenTofu Cloud<\/td>\n<\/tr>\n \n Lenguaje<\/strong><\/td>\n YAML\/JSON declarativo<\/td>\n HCL con m\u00f3dulos, variables, bloques din\u00e1micos<\/td>\n<\/tr>\n \n Detecci\u00f3n de Deriva<\/strong><\/td>\n Reportes de deriva de stack nativo<\/td>\n terraform plan o herramientas de deriva (driftctl)<\/td>\n<\/tr>\n \n Ecosistema de M\u00f3dulos<\/strong><\/td>\n Public Registry de CloudFormation, cat\u00e1logo estrecho<\/td>\n Terraform Registry, amplio y impulsado por la comunidad<\/td>\n<\/tr>\n \n Licencia<\/strong><\/td>\n Servicio de AWS, gratuito<\/td>\n BSL (Terraform) o MPL 2.0 (OpenTofu)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n \u00bfD\u00f3nde CloudFormation gana, d\u00f3nde Terraform pierde?<\/h2>\n
\n
\n
Multi-Cloud realidad en la pr\u00e1ctica DACH<\/h2>\n
Lo que los arquitectos deben decidir hasta Q3 2026<\/h2>\n
Preguntas frecuentes<\/h2>\n
Lohnt 2026 noch ein Wechsel von CloudFormation auf Terraform?<\/strong><\/summary>\n
OpenTofu oder Terraform con licencia BSL?<\/strong><\/summary>\n
\u00bfC\u00f3mo resuelve la condici\u00f3n de carrera de estado entre ejecuciones de CI en paralelo?<\/strong><\/summary>\n
\u00bfEs suficiente el informe de desv\u00edo de CloudFormation o se necesita driftctl?<\/strong><\/summary>\n
\u00bfQu\u00e9 significa la adquisici\u00f3n de HashiCorp por IBM para la elecci\u00f3n de herramientas?<\/strong><\/summary>\n
\n