La lección anterior terminó con una limitación concreta: red-mercadofresco.yaml describe seis subredes casi idénticas escritas a mano, una detrás de otra, porque YAML no tiene bucles. Tampoco tiene funciones, ni tipos, ni forma de encapsular «la red estándar de MercadoFresco» en algo que se reutilice en tres entornos. Y no hay manera de escribir una prueba que verifique que ninguna plantilla abre el puerto 22 al mundo. El AWS Cloud Development Kit resuelve las cuatro cosas de una sola forma: dejando que la infraestructura se escriba en un lenguaje de programación de verdad.

Lo importante desde el primer minuto es que el CDK no sustituye a CloudFormation. Todo lo de 09-01 —pilas, conjuntos de cambios, deriva, DeletionPolicy, ROLLBACK_COMPLETE— sigue siendo exactamente igual de cierto. El CDK escribe las plantillas por ti.

Aviso de coste. El CDK es gratuito; pagas los recursos que crea. cdk bootstrap crea un bucket de S3, un repositorio de ECR y cinco roles de IAM por cuenta y región: céntimos al mes mientras estén vacíos. Los ejemplos de esta lección despliegan una VPC con NAT (unos 0,045 USD/hora cada uno) y un ALB (unos 0,025 USD/hora): si sigues los ejercicios, destruye las pilas al terminar con el comando del apartado de limpieza. Datos ficticios.

1. Qué es el CDK y su relación con CloudFormation
2. Por qué compensa, y cuándo CloudFormation puro sigue siendo mejor
3. Instalación, cdk init y estructura del proyecto
4. App, Stack, Construct y los tres niveles de constructos
5. La red de MercadoFresco en CDK
6. Un constructo propio: MercadoFrescoVpc
7. Las capas de aplicación e integración en Python
8. Activos: el código de las Lambdas dentro de la pila
9. El ciclo de vida: synth, diff, deploy, destroy y bootstrap
10. Contexto, entornos explícitos y una pila por entorno
11. Aspectos: etiquetado obligatorio y reglas de auditoría
12. Pruebas de infraestructura
13. Recursos con estado, RemovalPolicy y el peligro de cdk destroy
14. CDK Pipelines: el pipeline que se despliega a sí mismo
15. Terraform, CDK for Terraform y la comparación honesta
16. Coste y limpieza
17. Errores comunes y consejos
18. Ejercicios
19. Conclusión

El CDK es una biblioteca de clases —disponible en TypeScript, JavaScript, Python, Java, C# y Go— con la que se describe la infraestructura como objetos. Cuando ejecutas cdk synth, esos objetos se sintetizan: producen una plantilla de CloudFormation, que después se despliega como una pila normal.

De ese flujo salen tres consecuencias prácticas que conviene interiorizar antes de escribir una línea:

• El artefacto de despliegue sigue siendo una plantilla. Puedes leerla, versionarla, revisarla y desplegarla sin el CDK. cdk.out/ contiene el resultado exacto de la síntesis, y cdk synth > plantilla.yaml te lo deja en un fichero.
• Los errores de CloudFormation siguen ocurriendo. Un ROLLBACK_COMPLETE en una pila del CDK se diagnostica y se resuelve como en 09-01: mirando los eventos de la pila.
• El código no se ejecuta en AWS. Se ejecuta en tu portátil o en CodeBuild, y su única salida es JSON. No hay nada «vivo» del CDK en la cuenta salvo lo que crea el bootstrap.

Lo que aporta un lenguaje de programación no es sintaxis más bonita: son cinco capacidades que YAML no tiene. Bucles, para las seis subredes. Condicionales de verdad, evaluados en la síntesis y no en el despliegue, lo que hace que la plantilla generada sea más simple, no más compleja. Tipos, que convierten un error de propiedad en un fallo de compilación en el editor, no en un CREATE_FAILED a los ocho minutos. Reutilización, encapsulando patrones en clases con nombre. Y pruebas, ejecutables en el pipeline como las del código de aplicación.

Pero el CDK no es la respuesta correcta en todos los casos, y conviene decirlo sin adornos:

MercadoFresco elige CDK por dos razones concretas de su situación: tiene tres entornos que deben ser idénticos y un equipo de dos personas que ya programan a diario. Si el equipo fuera de sistemas puros y la infraestructura llevara dos años sin tocarse, la respuesta correcta sería quedarse en YAML.

El CDK se instala con npm, incluso para proyectos en Python: la herramienta de línea de comandos es Node.

cdk init genera un proyecto ejecutable. Lo importante de su estructura:

Una advertencia sobre cdk.json: la sección context incluye banderas de funcionalidad (@aws-cdk/aws-*:featureFlag) que cambian el comportamiento por omisión de los constructos. Se generan con la versión del CDK que creó el proyecto y no deben tocarse a mano: modificarlas puede cambiar el ARN o el nombre de recursos ya desplegados, con reemplazo incluido.

En el repositorio mercadofresco-infra, el proyecto vive en infra-cdk/ junto a las plantillas de 09-01, que se mantienen mientras dura la migración.

Tres conceptos, y todo lo demás se deduce de ellos:

• App: la aplicación CDK completa, raíz del árbol. Una App contiene pilas.
• Stack: la unidad de despliegue, que corresponde 1:1 con una pila de CloudFormation. Los límites de 09-01 —500 recursos— siguen aplicando.
• Construct: cualquier nodo del árbol. Un recurso, un grupo de recursos o una pila entera son constructos. Todos reciben los mismos tres argumentos: scope (el padre), id (único entre hermanos) y props.

El id es el equivalente del nombre lógico de 09-01, y hereda su regla más importante: cambiar el id de un constructo desplegado destruye y recrea el recurso. El CDK compone los identificadores lógicos concatenando la ruta del árbol y añadiendo un sufijo, así que mover un constructo de sitio también lo recrea.

Los constructos tienen tres niveles de abstracción, y el mismo bucket ilustra la diferencia:

Dos avisos. Del L2 siempre puedes bajar al L1 con recurso.node.defaultChild as s3.CfnBucket para tocar una propiedad que la API no expone; es la válvula de escape que evita quedarse bloqueado. Y los L3 son cómodos y opacos: crean más recursos de los que esperas y su configuración fina cuesta más que escribirla a mano, así que MercadoFresco los usa para prototipar y luego baja a L2.

Otra pieza que ahorra mucho tiempo son los métodos grant*: cola.grantConsumeMessages(rol) genera la política de IAM correcta —incluidos los permisos sobre la clave de KMS— sin que nadie escriba un JSON. Es, en la práctica, el mínimo privilegio de 04-01 por defecto.

Las 190 líneas de YAML de 09-01 se convierten en esto:

Veintiocho líneas frente a ciento noventa, y el resultado sintetizado es equivalente: la misma VPC, seis subredes (tres configuraciones × dos AZ), el gateway de internet, los NAT, cuatro tablas de rutas con sus asociaciones y el endpoint de S3. Lo que ha desaparecido no es la infraestructura, es la repetición mecánica.

Merece la pena detenerse en tres detalles:

• subnetConfiguration es el bucle. Declaras tres tipos de subred y el CDK crea una por AZ, calculando los CIDR automáticamente a partir del bloque de la VPC y de cidrMask. Añadir una tercera AZ es cambiar maxAzs: 2 por 3.
• SubnetType codifica la intención, no la implementación: PRIVATE_WITH_EGRESS significa «privada con salida por NAT» y PRIVATE_ISOLATED, «sin salida a internet». Las subredes de datos de MercadoFresco son exactamente lo segundo, y el CDK no les crea ruta a 0.0.0.0/0 porque el tipo lo prohíbe.
• El condicional del NAT se resuelve en la síntesis. En 09-01 hacía falta un Mappings, una Condition y un Fn::If; aquí es un operador ternario de TypeScript y la plantilla resultante no tiene ninguna condición. Esa es la diferencia entre evaluar en tiempo de síntesis y evaluar en tiempo de despliegue, y es la razón por la que las plantillas generadas suelen ser más simples que las escritas a mano.

Un matiz honesto: esa concisión tiene un precio. El L2 de ec2.Vpc toma decisiones por ti —el reparto de CIDR, los nombres, el número de tablas de rutas— y para saber exactamente qué ha creado hay que mirar la plantilla sintetizada. Por eso cdk synth no es un comando de depuración ocasional: es parte del flujo normal.

La reutilización de verdad llega al encapsular el patrón en una clase con las decisiones de MercadoFresco ya tomadas:

Usarlo en los tres entornos es una línea por entorno, y cualquier mejora del patrón llega a los tres a la vez: si mañana se decide activar los registros de flujo también en preproducción, se cambia en un sitio. Eso es lo que en 09-01 no existía, porque un Mappings con tres columnas no es una abstracción: es una tabla.

La convención de MercadoFresco es que los constructos propios exponen lo que los consumidores necesitan y nada más —aquí, vpc y sgTienda—, para poder cambiar el interior sin romper a nadie. Es encapsulación aplicada a infraestructura, y es exactamente el motivo por el que compensa un lenguaje de programación.

El CDK es multilenguaje de verdad: las bibliotecas se generan con jsii desde la misma fuente en TypeScript, así que la API es idéntica salvo por el estilo de nombres. Luis prefiere Python para la capa de aplicación:

Aquí ocurren cosas que en YAML costaban decenas de líneas. add_listener y add_targets crean el oyente, el grupo de destino, el registro del ASG y las reglas del grupo de seguridad necesarias para que el ALB llegue a las instancias: el SourceSecurityGroupId de 09-01 lo deduce el CDK del grafo de objetos. Y scale_on_request_count crea la política de escalado con su alarma de CloudWatch asociada.

La capa de integración es igual de compacta, y muestra el patrón de 07-05 con la cola de mensajes fallidos:

add_subscription crea la suscripción y la política de la cola que permite a SNS escribir en ella, con la condición aws:SourceArn incluida. Es el bloque de veinte líneas de la solución del ejercicio de 09-01, reducido a una llamada y sin posibilidad de olvidarlo.

Hay una cosa que CloudFormation no sabe hacer sola y que el CDK resuelve de forma casi invisible: subir el código. Una plantilla puede declarar una función Lambda, pero su código tiene que estar ya en un bucket, con una clave que alguien ha tenido que rellenar a mano o desde un script. En 09-01 eso quedaba fuera de la plantilla y lo hacía el pipeline.

Los activos (assets) del CDK cierran ese hueco: durante cdk deploy, la herramienta empaqueta el directorio indicado, calcula su huella, lo sube al bucket del bootstrap y sustituye la referencia en la plantilla.

Tres consecuencias prácticas. La primera: la huella del contenido forma parte del nombre del activo, así que cambiar el código cambia el activo y cdk diff lo detecta; si no cambia, el despliegue no toca la función. La segunda: add_event_source crea el mapeo de origen de eventos y los permisos de consumo sobre la cola, incluida la clave de KMS. Y la tercera, que es una advertencia: los activos se acumulan en el bucket del bootstrap y nadie los borra, así que la regla de ciclo de vida del apartado de limpieza no es opcional a los seis meses.

Un matiz sobre el reparto de responsabilidades. Que el CDK pueda desplegar el código no significa que deba hacerlo en producción: MercadoFresco mantiene la separación de 08-05 —el artefacto de la tienda se construye una vez y lo despliega CodeDeploy— y usa activos solo para las Lambdas, cuyo código es pequeño y va acoplado a su infraestructura. Mezclar el ciclo de vida del código de aplicación con el de la infraestructura vuelve a juntar lo que el módulo 8 separó.

cdk bootstrap merece una explicación, porque es la parte que más desconcierta. Crea una pila llamada CDKToolkit con: un bucket de S3 para los artefactos (plantillas grandes, código de Lambda, activos), un repositorio de ECR para imágenes de contenedor, y cinco roles de IAM —de despliegue, de publicación de activos, de búsqueda, de ejecución de CloudFormation y de imágenes—. Sin ella, cdk deploy falla con un mensaje explícito.

Hay tres cosas que saber sobre el bootstrap: es por cuenta y por región, así que desplegar en us-east-1 para un certificado de CloudFront exige bootstrapearla también; la versión importa, y una versión antigua provoca fallos crípticos que se resuelven volviendo a ejecutarlo; y los roles que crea son potentes por omisión, con AdministratorAccess en el rol de ejecución de CloudFormation, lo que en una cuenta compartida es una decisión que hay que tomar conscientemente —--cloudformation-execution-policies permite acotarlo—.

cdk diff es el equivalente cotidiano del conjunto de cambios de 09-01, y su salida marca con [-], [+] y [~] lo que se borra, se añade y se modifica, señalando además los cambios que provocan reemplazo. La regla de MercadoFresco es la misma que allí: ningún despliegue sin haber leído el diff.

Aquí se ataca de frente el problema que aparece en cada incidente: que preproducción no es igual que producción. La solución del CDK es hacer que las tres pilas salgan del mismo código, con un fichero de configuración por entorno como única diferencia.

Quedan nueve pilas con nombres predecibles: MercadoFrescoRedProduccion, MercadoFrescoAplicacionPreproduccion, y así. Y la diferencia entre entornos ya no es un misterio arqueológico: es un fichero de veinte líneas que se lee en diez segundos. La primera vez que se generó, Marta descubrió tres divergencias que llevaban meses ahí: preproducción tenía un solo NAT declarado como si fuera producción, la retención de registros era de 7 días en los tres entornos y el CIDR de desarrollo se solapaba con el de preproducción.

Dos conceptos importantes de este bloque:

Entornos explícitos. Si omites env, la pila es agnóstica de entorno y no puede usar información real de la cuenta: Vpc.fromLookup, el número de AZ o los certificados existentes. El CDK entonces genera plantillas con dos AZ ficticias y sorpresas al desplegar. Declara siempre env con cuenta y región literales.

Contexto y cdk.context.json. Las búsquedas (fromLookup) consultan la cuenta durante la síntesis y cachean el resultado en cdk.context.json, que sí se versiona: garantiza que la síntesis sea reproducible y que el pipeline no dependa de consultas en vivo. Cuando la realidad cambia, se refresca con cdk context --clear. La regla práctica: preferir referencias explícitas a búsquedas, porque una búsqueda es una dependencia oculta sobre el estado de la cuenta.

El paso de valores entre pilas es más natural que en 09-01: pasar red.vpc a AplicacionStack hace que el CDK cree automáticamente la exportación y la importación de CloudFormation. Es cómodo y tiene la misma trampa que allí —una exportación en uso es un cerrojo— con un agravante: el CDK la crea sin que la veas. Si dos pilas van a evolucionar por separado, sigue siendo mejor publicar en Parameter Store y leer con StringParameter.valueForStringParameter.

Un aspecto es un visitante que recorre todo el árbol de constructos y actúa sobre cada nodo. Sirve para dos cosas que en YAML eran imposibles: aplicar algo a todos los recursos de golpe y auditar reglas sobre lo que se va a desplegar.

El etiquetado obligatorio de MercadoFresco es trivial con Tags, que internamente es un aspecto:

Y una regla de auditoría propia es una clase de veinte líneas:

Tres detalles que marcan la diferencia entre que esto funcione y que dé falsos negativos. Los aspectos visitan constructos L1, así que hay que comprobar CfnBucket y no Bucket: los L2 crean L1 por debajo y es ahí donde están las propiedades reales. addError detiene la síntesis, lo que convierte la regla en una puerta de calidad de verdad y no en un aviso que nadie lee. Y los aspectos se ejecutan después de que el árbol esté construido pero antes de sintetizar, por lo que también pueden modificar recursos —añadir cifrado en lugar de fallar—, aunque MercadoFresco prefiere fallar: una infraestructura que se corrige sola esconde el error en lugar de arreglarlo.

Esto es lo que en 09-01 hacía cfn-guard con un lenguaje aparte. Aquí es el mismo lenguaje, con el mismo editor, el mismo depurador y las mismas pruebas.

La pirámide de pruebas de 08-05 tenía un hueco evidente: la infraestructura no se probaba. Con el CDK sí, porque una plantilla sintetizada es un objeto JSON contra el que se pueden hacer aserciones.

Hay dos familias de pruebas y sirven para cosas distintas:

MercadoFresco usa las dos con una regla estricta: las aserciones cubren lo que no puede fallar nunca —seis subredes, dos NAT en producción, sin SSH abierto, cifrado en todos los buckets— y las instantáneas actúan de red de seguridad. Y una norma de revisión: una instantánea actualizada en una PR obliga a explicar el diff en la descripción. Sin esa norma, jest -u se convierte en un reflejo y la prueba deja de valer nada.

La ganancia real se ve al actualizar aws-cdk-lib: la instantánea muestra exactamente qué ha cambiado en las plantillas generadas antes de desplegar nada. En una actualización menor de la biblioteca, MercadoFresco descubrió así un cambio de comportamiento por omisión en el cifrado de una cola que nadie habría notado.

RemovalPolicy del CDK es la DeletionPolicy de 09-01, con una diferencia peligrosa: los constructos L2 eligen un valor por omisión, y no siempre el que esperas.

Y aquí está el peligro real, que en MercadoFresco es concreto porque los tres entornos comparten la cuenta 111122223333: cdk destroy --all no pregunta a qué entorno pertenece cada pila. Un --all lanzado desde el directorio equivocado, o un cdk destroy MercadoFrescoRedProduccion con un autocompletado desafortunado, toca producción. Tres medidas, en orden de eficacia:

1. deletion_protection y termination_protection en las pilas de producción, que hacen que el borrado falle en el servicio, no en la buena voluntad de quien escribe el comando. cdk.Stack acepta terminationProtection: true.
2. Nunca --all en un terminal humano. Los despliegues de producción salen del pipeline; en local se nombra la pila entera.
3. Cuentas separadas, que es la solución de verdad y llega en 09-04. Mientras tanto, las dos anteriores son parches conscientes.

Un último matiz: RemovalPolicy.RETAIN deja el recurso huérfano, y el siguiente cdk deploy intentará crear otro con el mismo nombre físico y fallará. Es la contrapartida de la seguridad, y la razón por la que los nombres físicos fijos —table_name, bucket_name— tienen coste, igual que en 09-01.

Queda la última pieza de la asimetría del módulo 8: el pipeline se creó a mano. pipelines.CodePipeline resuelve eso con una propiedad llamada autoactualización: el pipeline se define en el mismo repositorio que la infraestructura y, en cada ejecución, su primera etapa se actualiza a sí mismo antes de desplegar nada.

Un Stage es un grupo de pilas que se despliegan juntas —red, datos, integración, aplicación y observabilidad de un entorno— y el CDK deduce el orden de despliegue del grafo de dependencias entre ellas. npm test ejecuta las pruebas de la sección anterior, así que una plantilla que viole una regla no llega a desplegarse.

Con esto, MercadoFresco cierra el círculo del módulo 8: el pipeline-mercadofresco-tienda despliega la aplicación y el pipeline-mercadofresco-infra despliega la infraestructura y a sí mismo. Añadir una etapa nueva es una PR, no un clic en la consola.

Dos advertencias. La primera: el pipeline autoactualizable es potente y peligroso —quien pueda fusionar en main puede cambiar el propio pipeline—, así que la protección de rama de 08-01 y la revisión obligatoria dejan de ser buenas prácticas y pasan a ser un control de seguridad. La segunda: la etapa de síntesis necesita los permisos de búsqueda, así que cdk.context.json versionado no es opcional si quieres síntesis reproducibles.

Terraform, de HashiCorp, es la alternativa multiproveedor más extendida: lenguaje declarativo propio (HCL), estado en un fichero que hay que almacenar y bloquear, y proveedores para AWS, Azure, GCP, Datadog o GitHub. CDK for Terraform (CDKTF) permite escribir configuración de Terraform con TypeScript o Python, igual que el CDK con CloudFormation.

La recomendación es sencilla y no depende de gustos. Si todo está en AWS, CloudFormation o CDK, porque el estado gestionado y la reversión automática son ventajas reales que se pagan caras en Terraform. Si hay varios proveedores —AWS más Cloudflare, más GitHub, más Datadog— Terraform gana, y el coste de mantener el estado se justifica. MercadoFresco está entero en AWS y ya tiene el pipeline montado sobre servicios nativos: cambiar sería trabajo sin retorno.

El CDK es gratuito; el bootstrap deja un bucket, un repositorio de ECR y cinco roles cuyo coste es despreciable mientras estén vacíos. Conviene, eso sí, poner una regla de ciclo de vida en el bucket de activos, que crece con cada despliegue y no se limpia solo.

El orden importa por la misma razón que en 09-01: primero los consumidores, después la red. Si una pila no se deja borrar, la causa suele ser una exportación en uso o un bucket con objetos, y se diagnostica en los eventos de CloudFormation, no en el CDK.

Error: cambiar el id de un constructo desplegado. Renombrar 'Vpc' por 'VpcPrincipal' recrea el recurso, igual que en 09-01. Consejo: los id son inmutables en la práctica; si de verdad hay que reorganizar, cdk diff avisa —léelo—, y overrideLogicalId permite conservar el identificador anterior.

Error: desplegar sin cdk diff. El CDK hace tan fácil desplegar que la gente se salta la vista previa. Consejo: cdk diff en cada PR, publicado como comentario, y --require-approval any-change en producción.

Error: pilas sin env explícito. Producen plantillas con dos AZ ficticias y fromLookup no funciona. Consejo: declara env con cuenta y región literales en todas las pilas.

Error: cdk destroy --all en la cuenta compartida. Es el riesgo concreto de MercadoFresco hasta 09-04. Consejo: terminationProtection: true en las pilas de producción, nombrar siempre la pila, y nunca --all fuera de un entorno de pruebas.

Error: actualizar instantáneas con -u sin mirar. Convierte la prueba en decoración. Consejo: exigir en la revisión que toda instantánea actualizada venga con la explicación del diff.

Error: creer que el L2 hace lo que tú harías. ec2.Vpc toma docenas de decisiones por ti. Consejo: cdk synth y leer la plantilla la primera vez que uses un constructo nuevo; es la única forma de saber qué has pedido de verdad.

Consejo: fija la versión de aws-cdk-lib y actualízala a propósito. Con las pruebas instantáneas, cada actualización te enseña exactamente qué cambia en las plantillas antes de tocar nada.

Consejo: usa los métodos grant* en lugar de escribir políticas. Generan el mínimo privilegio real, incluidos los permisos sobre KMS que casi todo el mundo olvida.

Consejo: no metas lógica de negocio en el código de infraestructura. El CDK invita a hacerlo por ser un lenguaje completo. Una pila que lee una base de datos durante la síntesis es una pila que no se puede sintetizar en el pipeline.

Escribe un constructo propio ColaMercadoFresco (TypeScript o Python) que encapsule el patrón de 07-05: una cola principal con su cola de mensajes fallidos, cifrado con alias/mercadofresco-datos, maxReceiveCount configurable con valor por omisión de 5, retención de 14 días en la DLQ, y una alarma de CloudWatch que salte cuando la DLQ tenga mensajes. Debe exponer la cola principal, la DLQ y un método concederConsumo(rol). Úsalo para crear las cuatro colas de MercadoFresco. Indica qué RemovalPolicy pones en cada cola y por qué.

Escribe cuatro pruebas para RedStack y AplicacionStack que verifiquen invariantes que a MercadoFresco le importan de verdad: (a) que en producción hay dos NAT y en desarrollo uno; (b) que ninguna subred de datos tiene ruta hacia un NAT; (c) que el ALB solo acepta HTTPS; (d) que todos los recursos etiquetables llevan las cinco etiquetas obligatorias. Para cada una, di si la resolverías con aserción o con instantánea y por qué, y qué haría falta además de la prueba para que la regla se cumpla siempre.

MercadoFresco tiene ya la pila mercadofresco-red-produccion desplegada con la plantilla YAML de 09-01, con la VPC y las seis subredes en producción. Marta quiere pasar esa pila a CDK sin recrear nada y sin cortar el servicio. Describe la estrategia completa: qué opciones hay, cuál eliges y por qué, qué comandos ejecutas, cómo compruebas que la migración no va a cambiar nada, y qué haces si cdk diff muestra diferencias. Explica también qué riesgo concreto tiene la opción que descartas.

Solución 1

Las políticas de borrado. La DLQ siempre RETAIN, en todos los entornos: contiene mensajes que no se procesaron y que alguien tendrá que examinar; borrarla al destruir una pila destruye la evidencia de un incidente. La cola principal, RETAIN en producción y DESTROY en el resto: en producción puede haber mensajes en vuelo cuya pérdida sería pérdida de pedidos, mientras que en desarrollo un residuo que impide recrear la pila cuesta más de lo que protege.

Y un detalle que se nota al usarlo cuatro veces: el bucle de cuatro líneas sustituye a ciento veinte líneas de YAML con doce recursos, y garantiza que las cuatro colas tengan exactamente la misma configuración —cifrado, reintentos, alarma—, que es justo lo que hoy no se cumple en MercadoFresco.

Solución 2

(a) Aserción. Es un invariante de negocio con dos valores concretos, y la prueba lo expresa mejor que cualquier instantánea. Además sobrevive a refactorizaciones: si mañana se reorganizan los constructos, la prueba sigue valiendo.

(b) Aserción, pero indirecta. Comprobar «ninguna subred de datos tiene ruta a un NAT» requiere seguir la relación entre RouteTable, Route y SubnetRouteTableAssociation en la plantilla, que es tedioso. Lo pragmático es afirmar que no existe ninguna AWS::EC2::Route con NatGatewayId cuya tabla esté asociada a una subred datos, y apoyarse en que el CDK garantiza la propiedad por construcción al usar PRIVATE_ISOLATED. La prueba vale como red de seguridad ante un cambio de tipo de subred.

(c) Aserción, con la parte negativa incluida. Comprobar que existe un oyente 443 no basta: lo que importa es que no exista uno en el 80 sin redirección. Las pruebas que solo verifican presencia dejan pasar precisamente los errores por adición, que son los que ocurren.

(d) Ni aserción ni instantánea: un aspecto. Una prueba que recorra todos los recursos comprobando etiquetas es frágil, porque muchos tipos no las admiten y habría que mantener la lista de excepciones. Lo correcto es un aspecto que falle la síntesis si falta una etiqueta obligatoria, más una prueba de que el aspecto está registrado en la App. Se prueba el mecanismo, no cada instancia.

Qué hace falta además de las pruebas. Nada de esto sirve si las pruebas no bloquean: tienen que ejecutarse en npm test dentro de la etapa de síntesis de CDK Pipelines, y la construcción debe fallar, no avisar. Es la misma conclusión de 08-02, aplicada a la infraestructura: una comprobación que no bloquea es documentación.

Solución 3

Hay dos opciones y no son equivalentes.

La primera es recrear la red en CDK y migrar: desplegar una VPC nueva junto a la vieja, mover las instancias, la base de datos y el ALB, y borrar la antigua. Es limpia conceptualmente y es la que se descarta, porque implica mover Aurora y el ALB entre VPC: cambio de endpoints, ventana de corte, riesgo sobre los datos de clientes y, sobre todo, un beneficio nulo —la red resultante es idéntica—. Todo el riesgo, ninguna ganancia.

La segunda, la elegida, es hacer que el CDK adopte la pila existente. La clave es que una pila de CloudFormation no sabe si su plantilla la escribió una persona o el CDK: solo compara identificadores lógicos. Si la plantilla sintetizada es equivalente, la actualización no toca ningún recurso.

El procedimiento. Se escribe la pila CDK con el mismo nombre de pila, mercadofresco-red-produccion, y se fuerzan los identificadores lógicos para que coincidan con los de la plantilla YAML, usando overrideLogicalId recurso a recurso:

La comprobación, que es el corazón del ejercicio:

cdk diff vacío es la condición de aceptación. Mientras muestre algo, no se despliega.

Si muestra diferencias, hay tres casos. Si son solo metadatos del CDK (CDKMetadata, la versión del analizador) se aceptan: no afectan a ningún recurso. Si son propiedades cosméticas —una descripción, una etiqueta— se decide caso a caso y se documenta. Y si hay algún [~] con reemplazo o cualquier [-], se para: significa que la plantilla generada no es equivalente y hay que ajustar el código hasta que lo sea. Un [-] sobre una subred en producción es exactamente el desastre que esta migración existe para evitar.

La red de seguridad, en dos pasos. Antes de nada, --enable-termination-protection en la pila y DeletionPolicy: Retain en los recursos críticos, para que ni siquiera un error grave destruya nada. Y el ensayo completo primero en desarrollo, luego en preproducción y solo entonces en producción, que es el mismo orden de promoción de 08-04 aplicado a la infraestructura.

La misma infraestructura, en un lenguaje de programación. Las 190 líneas de YAML de la red se han convertido en 28 líneas de TypeScript que sintetizan una plantilla equivalente, y las seis subredes casi idénticas han desaparecido dentro de un subnetConfiguration de tres entradas que el CDK multiplica por AZ. Lo que no ha cambiado es lo que hay debajo: el CDK no sustituye a CloudFormation, escribe las plantillas por ti, y los conjuntos de cambios, la deriva, ROLLBACK_COMPLETE y las políticas de borrado de 09-01 siguen gobernando lo que ocurre de verdad.

Tienes los tres niveles de constructos —el L1 que calca CloudFormation, el L2 con valores por defecto seguros y métodos grant* que generan el mínimo privilegio, y el L3 cómodo y opaco— con la válvula de escape de node.defaultChild para bajar de nivel cuando la API se queda corta. Tienes el constructo propio MercadoFrescoVpc, que es la diferencia entre una tabla de tres columnas y una abstracción de verdad: una mejora del patrón llega a los tres entornos a la vez. Y tienes el ciclo de vida completo, con cdk bootstrap explicado —el bucket, el repositorio de ECR y los cinco roles, por cuenta y región, con permisos de administración que hay que acotar conscientemente— y con la regla que se hereda de 09-01: ningún despliegue sin haber leído el diff.

Los tres entornos salen ahora del mismo código, y la diferencia entre preproducción y producción ha dejado de ser arqueología: es config/entornos.ts, veinte líneas legibles en diez segundos, que al escribirse por primera vez destapó tres divergencias que llevaban meses ahí. Con entornos explícitos en todas las pilas —sin env no hay búsquedas y sí AZ ficticias— y cdk.context.json versionado para que la síntesis sea reproducible en el pipeline.

Y la infraestructura entra por fin en la pirámide de pruebas de 08-05. Los aspectos aplican el etiquetado obligatorio de golpe y auditan reglas —buckets sin cifrar, el puerto 22 abierto— con addError, que detiene la síntesis en lugar de avisar; visitando siempre constructos L1, que es donde están las propiedades reales. Las aserciones cubren lo que no puede fallar nunca y las instantáneas actúan de red de seguridad, con la norma de revisión que las mantiene vivas: una instantánea actualizada obliga a explicar el diff. Más CDK Pipelines, que cierra la asimetría del módulo 8 al desplegar la infraestructura y actualizarse a sí mismo —y que convierte la protección de rama de 08-01 en un control de seguridad, porque quien fusiona en main cambia el pipeline—.

Queda un riesgo señalado tres veces y no resuelto: cdk destroy apuntando a producción. La protección de terminación y la disciplina de nombrar siempre la pila son parches conscientes, no soluciones, porque el problema de fondo es que los tres entornos comparten la cuenta 111122223333. Mientras eso siga siendo cierto, un comando mal escrito, una variable de entorno olvidada o un --all en el directorio equivocado pueden alcanzar la tienda en producción. Y el radio de explosión no es lo único: las cuotas se comparten, un despliegue de desarrollo puede agotar el límite de direcciones IP elásticas de producción, la factura no se separa de verdad y ninguna política de IAM aísla del todo a alguien que ya tiene permisos amplios en la cuenta.

En 09-03, «AWS Elastic Beanstalk», damos un paso atrás para mirar la alternativa gestionada: qué hace por ti una plataforma como servicio, cuándo habría sido la decisión correcta para MercadoFresco —y por qué hoy ya no lo es—. Después, 09-04, «AWS Organizations», ataca el problema de fondo: separar de verdad los entornos en cuentas distintas, con políticas de control de servicios, facturación consolidada y una línea base que se despliega sola en cada cuenta nueva.