En el último correo te conté cómo pasé de 5 minutos a 40 segundos por deploy en AWS CDK.

Y sí, fue un salto brutal.

Pero, como suele pasar en el mundo DevOps… la historia no acabó ahí.

Un par de semanas después, noté algo raro:

los despliegues empezaban a ralentizarse otra vez, sin haber cambiado casi nada del código.

Y ahí es cuando entendí la lección.

El problema no estaba en el build,

ni en el cache,

ni en los assets.

Estaba en algo más invisible: las dependencias entre stacks.

Cada vez que añadía un nuevo stack con referencias cruzadas (por ejemplo, una Lambda que depende de una tabla DynamoDB o un topic SNS de otro stack), CloudFormation tenía que desplegar en orden, y eso arruinaba mi paralelismo.

Resultado: los builds seguían siendo rápidos…

pero los despliegues volvían a comportarse como una cadena lenta de fichas de dominó.

Así que rehice parte de mi arquitectura:

• Aislé recursos independientes en stacks separados.

• Eliminé referencias cruzadas innecesarias.

• Y empecé a usar outputs e imports para mantener la modularidad sin romper el aislamiento.

Desde entonces, los despliegues vuelven a volar ⚡

y, lo mejor, son más fáciles de mantener a largo plazo.

Moraleja:

Optimizar CDK no es cuestión de un comando o una flag.

Es un proceso continuo de detectar cuellos de botella que se esconden justo cuando crees que ya lo has resuelto todo.

Estoy preparando una guía práctica sobre cómo modularizar tus stacks y mantenerlos ultrarrápidos.

¿Te gustaría que la comparta por aquí cuando la tenga lista?