AWS CDK: Ventajas, Desventajas y Cuándo No Es la Respuesta

Una decisión de infraestructura como código (IaC, el enfoque de definir y provisionar servidores, redes y bases de datos mediante código en lugar de clics manuales en una consola) no se revierte fácilmente. Una vez que cien microservicios dependen de una convención de nombres, un patrón de despliegue y un lenguaje concreto, cambiar de herramienta cuesta meses de trabajo, no una sprint. Por eso vale la pena mirar AWS CDK (Cloud Development Kit) con evidencia actual, no con la reputación que tenía hace tres años.

Qué es exactamente y por qué existe#

AWS CDK es un framework de código abierto que permite definir recursos de infraestructura en lenguajes de programación conocidos en lugar de plantillas declarativas. Es un framework de desarrollo de software de código abierto que permite definir los recursos de la aplicación en la nube usando lenguajes de programación conocidos, y soporta JavaScript, TypeScript, Python, Java, C# y Go. Por debajo, no reemplaza a CloudFormation: lo genera. El CDK provisiona los recursos de forma segura y repetible a través de AWS CloudFormation, y cuando se sintetiza el código CDK, el resultado es una plantilla de CloudFormation.

Esa distinción importa para el negocio: cualquier cosa que ya sepas sobre gobernanza, límites de CloudFormation o comportamiento de despliegues en AWS sigue aplicando. CDK no es una plataforma paralela; es una capa de autoría sobre la misma maquinaria.

Las ventajas reales#

• Velocidad de desarrollo: los equipos usan bucles, clases y tipos fuertes en lugar de copiar y pegar YAML. Esto reduce errores de configuración en infraestructuras grandes.
• Reutilización a escala: las 'constructs' (componentes que representan uno o más recursos de CloudFormation) se empaquetan, versionan y comparten como cualquier librería de software.
• Gobernanza programática: los 'aspects' de CDK permiten aplicar estándares — como etiquetado obligatorio o cifrado por defecto — a todos los recursos de un alcance determinado, sin depender de que cada desarrollador lo recuerde.
• Acceso inmediato a funciones nuevas de AWS, porque CDK y CloudFormation están alineados de forma nativa con la plataforma.

Casos como el de Thomson Reuters muestran el patrón real de adopción empresarial: no usar CDK 'de fábrica', sino construir una capa interna sobre él. Las grandes organizaciones suelen enfrentar desafíos de gestión de infraestructura, incluyendo problemas de cumplimiento, cuellos de botella en el desarrollo y errores por creación inconsistente de recursos de AWS entre equipos. Su solución fue extender CDK con una librería propia para estandarizar nombres, etiquetas y políticas sin obligar a cada desarrollador a aprender clases personalizadas. Un principio de diseño clave fue minimizar el código personalizado que un usuario de TR AWS CDK necesita frente a usar CDK estándar, lo que reduce la curva de aprendizaje para los desarrolladores.

Las desventajas — y por qué no son un defecto de diseño#

La documentación oficial de AWS es sorprendentemente directa sobre las limitaciones. CDK requiere un entorno preparado (bootstrapped) en cada cuenta de AWS — una acción única que debe realizarse en cada entorno donde se despliegan recursos — y solo puede usarse para desplegar infraestructura dentro de AWS Cloud. El bootstrapping no es un detalle menor: crea un bucket S3, un repositorio ECR y un conjunto de roles IAM en cada cuenta y región que uses. El bootstrapping prepara el entorno de AWS aprovisionando recursos específicos que usa el CDK, incluyendo un bucket de Amazon S3 para archivos del proyecto, un repositorio de Amazon ECR para imágenes Docker, y roles de AWS IAM configurados para otorgar los permisos que necesita el CDK.

Para una organización con decenas de cuentas y equipos de seguridad estrictos, ese bootstrap por defecto rara vez encaja sin fricción. GoDaddy documentó públicamente cómo tuvo que construir un enfoque 'sin bootstrap' propio porque sus requisitos de cifrado, etiquetado y límites de permisos superaban lo que el bootstrap estándar ofrecía. El setup por defecto de CDK incluye medidas de seguridad, pero los requisitos de gobernanza empresarial de GoDaddy tenían especificaciones adicionales que generaban dificultad con los recursos de bootstrap por defecto: los buckets S3 necesitaban cifrado, logging y cumplimiento adicionales; los roles IAM requerían alinearse con límites de permisos específicos. Esto no es un fallo de CDK. Es lo que ocurre cuando una herramienta diseñada para el caso general se encuentra con reglas de cumplimiento propias — el mismo patrón que aparece con cualquier framework al escalar.

Este ha sido un punto de dolor significativo: cualquier cambio al ID lógico de un recurso causado por renombrar o mover una construct forzaba a CloudFormation a eliminar y luego recrear el recurso, un proceso destructivo que a menudo generaba pérdida de datos y tiempo de inactividad para recursos con estado como bases de datos. AWS lanzó un comando de refactorización para resolverlo, pero todavía está en estado de pre-lanzamiento y requiere el flag --unstable=refactor, además de volver a hacer bootstrap del entorno CDK para obtener los permisos necesarios. Traducido a negocio: hoy, reorganizar tu código de infraestructura sigue siendo una operación que exige revisión cuidadosa, no un simple 'renombrar y desplegar'.

El punto de decisión real: AWS-nativo vs. multi-nube#

La comparación más honesta no es 'CDK bueno, Terraform malo' — es sobre dónde vive tu infraestructura. CloudFormation y CDK toman un enfoque de alineación mucho más estrecha con las capacidades nativas de AWS, lo que puede dar acceso más rápido a funciones nuevas, mientras que la ventaja de Terraform sigue siendo su ecosistema amplio, su modelo multi-nube y su flujo de trabajo maduro basado en estado. Terraform mantiene su fortaleza en volumen y madurez de módulos: sigue siendo popular por su ecosistema y su configuración simple: un binario único, un flujo de trabajo por línea de comandos y una biblioteca madura de módulos.

La guía oficial de AWS resume el criterio de decisión sin rodeos: si gestionas tu infraestructura completamente en AWS, CloudFormation y CDK son buenas opciones porque ofrecen gestión de estado lista para usar y acceso nativo a funciones nuevas; si quieres una utilidad multi-proveedor, especialmente para infraestructura multi-nube o híbrida, Terraform puede ser mejor opción porque es agnóstico de plataforma. Y sobre Pulumi: si tu organización puede tolerar un nivel alto de riesgo y necesita soportar entornos multi-nube o híbridos, considera usar Pulumi.

Un competidor que ya no compite: CDK for Terraform#

Durante años, CDKTF (CDK for Terraform, un proyecto conjunto de AWS y HashiCorp que permitía escribir configuración de Terraform en lenguajes como TypeScript o Python) parecía el mejor de ambos mundos: sintaxis de CDK, ecosistema de Terraform. Eso terminó. El Cloud Development Kit for Terraform está descontinuado desde el 10 de diciembre de 2025; HashiCorp ya no lo soporta ni lo mantiene. Para cualquier equipo que evaluaba CDKTF como puente entre ecosistemas, esa opción ya no es viable a largo plazo — un recordatorio de que las herramientas de integración entre plataformas de infraestructura tienen un ciclo de vida propio, independiente de las plataformas que conectan.

Otros nombres que aparecen en la conversación#

Crossplane se acerca desde un ángulo distinto: en vez de ejecutarse desde una CLI, convierte a Kubernetes en el plano de control de la infraestructura. Pulumi y CDK tratan la infraestructura como programación real, mientras que Crossplane trata la infraestructura como recursos de Kubernetes controlados por operadores y políticas. Ha ganado tracción empresarial seria — entre sus usuarios públicos están Nike, Autodesk, NASA Science Cloud, Elastic, SAP, IBM y Nokia — pero exige una organización que ya opera con Kubernetes como plataforma interna, no una decisión aislada de IaC.

Lo que esto significa para una decisión de negocio#

CDK no es 'mejor' ni 'peor' que Terraform o Pulumi de forma abstracta. Es la opción correcta cuando tu infraestructura vive casi enteramente en AWS y tu organización ya tiene desarrolladores fuertes en TypeScript, Python o Java — porque entonces la curva de aprendizaje de una nueva sintaxis desaparece. La clave es alinear la herramienta de IaC elegida con los objetivos de la organización y las habilidades de los desarrolladores; por ejemplo, si tu equipo domina JavaScript, podrías elegir AWS CDK con TypeScript porque optimiza tu flujo de trabajo de desarrollo.

El costo oculto no está en la sintaxis, está en la operación continua: bootstrapping por cuenta, aspects de gobernanza que alguien debe mantener actualizados, refactorizaciones que exigen revisión manual mientras la función nativa sigue en pre-lanzamiento, y una comunidad de práctica interna — como recomienda la propia AWS — para que el conocimiento no dependa de una sola persona. Nada de esto aparece en la demo inicial. Aparece seis meses después, cuando la primera stack con estado necesita reorganizarse y nadie en el equipo escribió las pruebas unitarias que protegen los IDs lógicos.

Para organizaciones que ya operan infraestructura AWS con Infrastructure as Code como parte de su stack, la pregunta no es qué herramienta gana en abstracto. Es quién está observando esa infraestructura de forma continua — quién bootstrapea cada cuenta nueva con las políticas correctas desde el primer día, quién revisa cada refactorización antes de que borre una base de datos, quién mantiene la librería interna de constructs al día con las funciones nuevas de AWS. Eso es trabajo operativo permanente, no un proyecto que se cierra.