8 Min. Tiempo de lectura \u00b7 Fecha: Abril 2026<\/p>\n
AWS CloudFormation y Terraform no son una alternativa en abril de 2026, sino una decisi\u00f3n 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\u00f3n que quer\u00eda 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 corretaje de nube y el informe de FinOps de abril de 2026<\/a><\/p>\n Ambos herramientas hacen la misma promesa: infraestructura como c\u00f3digo, declarativa, idempotente y versionable. Antes de comparar, un breve repaso de los conceptos b\u00e1sicos.<\/p>\n \u00bfQu\u00e9 es la infraestructura como c\u00f3digo?<\/strong> 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\u00f3n que el c\u00f3digo de la aplicaci\u00f3n, pasan por las canalizaciones de CI y producen entornos reproducibles. Sin IaC, nadie puede decir con seguridad por qu\u00e9 un entorno de pruebas se ve diferente al de producci\u00f3n.<\/p>\n En las empresas medianas de la regi\u00f3n DACH, he o\u00eddo la misma pregunta durante dos a\u00f1os: \u00ab\u00bfCu\u00e1l debemos 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 aclare esto antes de elegir la herramienta se ahorrar\u00e1 la discusi\u00f3n en los pr\u00f3ximos dos a\u00f1os.<\/p>\n CloudFormation es un componente nativo de AWS. Los nuevos servicios de AWS aparecen en el cat\u00e1logo de recursos de CloudFormation el d\u00eda de su lanzamiento. El proveedor de Terraform para AWS suele llegar entre seis y diez d\u00edas despu\u00e9s, ocasionalmente semanas. Quien necesite recursos de Bedrock Agent o las instancias EC2 C8i anunciadas en abril de 2026 en su c\u00f3digo desde el primer d\u00eda tiene una ventaja de velocidad medible con CloudFormation. Esto es relevante en el d\u00eda a d\u00eda de una empresa del DAX. En las empresas medianas, es raro.<\/p>\n Terraform juega su fuerza en la amplitud. Un cat\u00e1logo de proveedores con m\u00e1s de 4.500 proveedores cubre no solo Azure y GCP, sino tambi\u00e9n 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\u00f3 a la separaci\u00f3n de OpenTofu. Ambos forks est\u00e1n listos para producci\u00f3n en abril de 2026 y son compatibles con la API. OpenTofu est\u00e1 alojado por la Fundaci\u00f3n Linux, Terraform sigue bajo el paraguas de HashiCorp y ahora IBM.<\/p>\n Fuente: Gu\u00eda del usuario de AWS CloudFormation abril 2026, HashiCorp Provider Registry Snapshot 24 de abril de 2026<\/p>\n<\/div>\n La tabla explica por qu\u00e9 existen bandos, pero no por qu\u00e9 la discusi\u00f3n suele salir mal. Oculta dos puntos que son decisivos 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 baratos en CloudFormation porque hay menos que saber. En Terraform es m\u00e1s caro porque se puede hacer m\u00e1s mal.<\/p>\n En la prueba pr\u00e1ctica con tres equipos de nubes DACH del \u00faltimo trimestre, han surgido los mismos argumentos una y otra vez. Eran menos ideol\u00f3gicos de lo que internet hace creer. Un conglomerado de ingenier\u00eda mec\u00e1nica 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.<\/p>\n CloudFormation gana<\/p>\n Terraform \/ OpenTofu destaca<\/p>\n Una observaci\u00f3n de las revisiones: los equipos de CloudFormation subestiman regularmente lo r\u00e1pido que un \u00abquiz\u00e1s m\u00e1s tarde Azure\u00bb se convierte en un requisito estricto. Tan pronto como las ventas incluyen una cl\u00e1usula de multi-nube en un contrato con un cliente importante, la estrategia de IaC es el \u00faltimo domin\u00f3 que cae. Quien entonces solo utiliza CloudFormation, escribe scripts paralelos para Azure sin una abstracci\u00f3n limpia. Ese es exactamente el funcionamiento mixto que nadie quiere.<\/p>\n 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\u00f3n y cifrado KMS, suena simple. Hasta que un archivo de estado entre dos ejecuciones paralelas de CI produce una condici\u00f3n de carrera y nadie sabe qu\u00e9 salida de plan se aplic\u00f3 realmente. Esto lo he dejado como predeterminado demasiadas veces. Hoy la recomendaci\u00f3n es clara: un bloqueo por espacio de trabajo, un espacio de trabajo por trabajo de CI, una captura autom\u00e1tica del archivo de estado antes de cada aplicaci\u00f3n.<\/p>\n En el conglomerado de ingenier\u00eda mec\u00e1nica sucedi\u00f3 exactamente eso. Una ejecuci\u00f3n de la canalizaci\u00f3n con dos ramas paralelas, ambas en el mismo archivo de estado. La segunda ejecuci\u00f3n sobrescribi\u00f3 el estado de la primera, una instancia de RDS era desconocida en Terraform, pero exist\u00eda en AWS. Tres d\u00edas de limpieza de deriva, dos tickets, un informe de estado vergonzoso en el comit\u00e9 de direcci\u00f3n. Si la segunda ejecuci\u00f3n hubiera tenido su propio espacio de trabajo, habr\u00eda sido cuesti\u00f3n de diez minutos.<\/p>\n Los proveedores de SaaS de la muestra han experimentado el caso contrario. Comenzaron con CloudFormation y elevaron la pila durante tres a\u00f1os. Luego lleg\u00f3 el requisito de aprovisionar program\u00e1ticamente cuentas de Snowflake. Sin el proveedor de Terraform no hab\u00eda soluci\u00f3n 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\u00f3digo de pegamento con una etiqueta de pila. Quien se encuentra en esta situaci\u00f3n, ha tomado la elecci\u00f3n de herramienta demasiado tarde.<\/p>\n En los tres escenarios pr\u00e1cticos que he examinado m\u00e1s de cerca para esta verificaci\u00f3n, 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\u00edficas de AWS. La definici\u00f3n de capas es el truco completo. Quien la tenga por escrito, duerme mejor.<\/p>\n En concreto, se ve as\u00ed: Terraform define VPCs, subredes, roles de IAM, confianza entre cuentas, cl\u00fasteres 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\u00e1logo de servicios, planes de respaldo de AWS con reglas de ciclo de vida complejas, estrategias de implementaci\u00f3n de AppConfig. La transici\u00f3n se realiza a trav\u00e9s de salidas de Terraform, que se alimentan en una pila de CloudFormation como par\u00e1metros de SSM. El patr\u00f3n se ha establecido en la pr\u00e1ctica en 2026, porque conecta ambos mundos sin fricci\u00f3n.<\/p>\n El denominador com\u00fan: la gesti\u00f3n del estado permanece claramente separada por capa. El estado de Terraform se encuentra en el bucket de S3 por cuenta y regi\u00f3n. Las pilas de CloudFormation tienen su propia gesti\u00f3n de estado del lado del servicio. Ambos mundos se orquestan a trav\u00e9s de canalizaciones de CI, que saben qu\u00e9 orden es v\u00e1lida: primero la plataforma, luego la carga de trabajo, luego las macros. Quien invierte esto, construye pilas que se refieren a recursos inexistentes.<\/p>\n Una segunda ense\u00f1anza pr\u00e1ctica: la gesti\u00f3n del drift es el centro de costos invisible. La detecci\u00f3n de drift de CloudFormation est\u00e1 integrada y reporta desviaciones de configuraci\u00f3n por recurso. En Terraform, en la mayor\u00eda de los escenarios, un trabajo de planificaci\u00f3n recurrente en la CI se hace cargo de esto, que genera tickets cuando hay drift. Ambos caminos funcionan. Pero solo uno est\u00e1 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.<\/p>\n En el caso del asegurador de la verificaci\u00f3n pr\u00e1ctica, la gesti\u00f3n del drift fue la palanca que hizo posible la aceptaci\u00f3n de cumplimiento. El auditor externo quer\u00eda ver una referencia de pila verificada para cada recurso productivo. Con el informe de drift de CloudFormation nativo, esto se entreg\u00f3 en dos horas. En el lado de Terraform, tom\u00f3 una semana hasta que driftctl categoriz\u00f3 correctamente los recursos no administrados. Ambos mundos funcionaron, pero el esfuerzo fue desigual.<\/p>\n Una tercera observaci\u00f3n pr\u00e1ctica se refiere al tema de la reutilizaci\u00f3n de m\u00f3dulos. En el caso del conglomerado de construcci\u00f3n de maquinaria, siete unidades de negocio trabajaron en paralelo en cl\u00fasteres de EKS. Sin un m\u00f3dulo Terraform com\u00fan, cada unidad ten\u00eda su propio c\u00f3digo de cl\u00faster con desviaciones m\u00ednimas. El equipo de plataforma invirti\u00f3 un mes en construir un m\u00f3dulo central de EKS, con variables de entrada claras y valores predeterminados significativos. Despu\u00e9s de tres meses, todas las unidades fueron migradas, y el esfuerzo de mantenimiento se redujo a un tercio. Con CloudFormation, el mismo patr\u00f3n habr\u00eda funcionado, pero el ecosistema de m\u00f3dulos es m\u00e1s estrecho y el grupo com\u00fan de bloques reutilizables es m\u00e1s peque\u00f1o.<\/p>\n Tres movimientos del mercado hacen que la cuesti\u00f3n de las capas sea m\u00e1s urgente en 2026, no menos. HashiCorp fue adquirida por IBM en febrero de 2024. La transici\u00f3n 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\u00f3n Linux y se considera un reemplazo directo con su propio registro de m\u00f3dulos en 2026. AWS lanz\u00f3 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\u00e1n en cada revisi\u00f3n de la arquitectura de los pr\u00f3ximos dos trimestres.<\/p>\n Quien no tenga una definici\u00f3n escrita de capas en 2026, deber\u00eda escribirla ahora. No como una regulaci\u00f3n de arquitectura, sino como una ayuda para la toma de decisiones para cada nuevo m\u00f3dulo: qu\u00e9 capa, qu\u00e9 herramienta, qu\u00e9 gesti\u00f3n de estado. Esto ahorra la discusi\u00f3n recurrente sobre si un nuevo servicio se coloca en CloudFormation o Terraform. Hace posible la incorporaci\u00f3n de nuevos ingenieros de plataforma en d\u00edas en lugar de semanas.<\/p>\n Tres pasos concretos que se han demostrado como una secuencia efectiva en las configuraciones pr\u00e1cticas. Primero: escribir un mapeo de capas de una p\u00e1gina que aclare qu\u00e9 herramienta es responsable de cada tipo de recurso. Segundo: unificar el backend de estado por cuenta y regi\u00f3n, con una convenci\u00f3n clara de espacio de trabajo. Tercero: colgar un trabajo de informe de deriva en la CI que genere autom\u00e1ticamente tickets en caso de desviaciones. Estos tres pasos se pueden implementar en dos semanas y ahorran completamente la pr\u00f3xima reuni\u00f3n de revisi\u00f3n de la arquitectura.<\/p>\n Lo que no pertenece a esta secuencia: una migraci\u00f3n de herramientas sin desencadenante. Quien quiera cambiar de CloudFormation a Terraform solo por higiene de c\u00f3digo, sin requerimiento de multicloud en el fondo, desperdicia tres trimestres de tiempo de ingenier\u00eda en una refactorizaci\u00f3n que nadie mide. La discusi\u00f3n m\u00e1s honesta en cada revisi\u00f3n de la arquitectura de los pr\u00f3ximos dos trimestres es, por lo tanto, la pregunta por el motivo concreto, no la pregunta por la herramienta concreta.<\/p>\n Solo con un claro desencadenante de ingenier\u00eda de m\u00faltiples nubes o plataformas. Los stacks de AWS puros sin conexi\u00f3n SaaS se benefician poco del cambio y asumen la curva de aprendizaje y la carga de gesti\u00f3n de estado de nuevo. Quien tenga un contrato de m\u00faltiples nubes con grandes clientes en cartera, deber\u00eda empezar en paralelo.<\/p>\n<\/details>\n OpenTofu est\u00e1 listo para producci\u00f3n en 2026, compatible con API y alojado en Linux Foundation. Quien necesite claridad de licencia para cumplimiento o quiera compartir m\u00f3dulos sin riesgo de proveedor, est\u00e1 mejor posicionado con OpenTofu. La licencia BSL de HashiCorp sigue siendo no cr\u00edtica para 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 backend. Un bloqueo por Workspace, un Workspace por trabajo de CI. Quien ejerce paralelismo de tuber\u00edas sin estrategia de bloqueo, se construye corrupci\u00f3n de estado.<\/p>\n<\/details>\n 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\u00f3n: tambi\u00e9n ve recursos no administrados que ning\u00fan stack conoce. Ambos se complementan, no se reemplazan.<\/p>\n<\/details>\n Hasta 2027 se ejecuta el plan de integraci\u00f3n, despu\u00e9s se reorganizar\u00e1n los modelos de precios y soporte. Terraform de c\u00f3digo abierto y HCP seguir\u00e1n disponibles hasta entonces. Quien conduce la independencia de proveedor como principio de arquitectura, deber\u00eda evaluar OpenTofu.<\/p>\n<\/details>\n Consejos de lectura de la redacci\u00f3n<\/p>\n M\u00e1s del network de MBF Media<\/p>\n\n
Qu\u00e9 distingue realmente a 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 Cobertura de nube<\/strong><\/td>\n Solo AWS (incl. AWS Outposts, Local Zones)<\/td>\n M\u00e1s de 4.500 proveedores, todos los hyperscalers<\/td>\n<\/tr>\n \n Soporte de servicio desde el primer d\u00eda<\/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 Lado del servicio en AWS, sin gesti\u00f3n de bloqueo<\/td>\n Autohosted (S3 + DynamoDB), HCP o OpenTofu Cloud<\/td>\n<\/tr>\n \n Idioma<\/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 Informes de deriva de pila nativos<\/td>\n terraform plan o herramientas de deriva (driftctl)<\/td>\n<\/tr>\n \n Ecossistema de m\u00f3dulos<\/strong><\/td>\n Registro p\u00fablico de CloudFormation, cat\u00e1logo limitado<\/td>\n Registro de Terraform, 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 Donde CloudFormation gana, donde Terraform destaca<\/h2>\n
\n
\n
Realidad de Multi-Cloud en la pr\u00e1ctica DACH<\/h2>\n
Qu\u00e9 deben decidir los arquitectos antes de Q3 2026<\/h2>\n
Preguntas frecuentes<\/h2>\n
\u00bfVale la pena cambiar de CloudFormation a Terraform en 2026?<\/strong><\/summary>\n
OpenTofu o Terraform con licencia BSL?<\/strong><\/summary>\n
\u00bfC\u00f3mo se resuelve la condici\u00f3n de carrera de estado entre ejecuciones paralelas de CI?<\/strong><\/summary>\n
\u00bfEs suficiente el informe de deriva 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