> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/es/2025/w43-lessons-learned-from-the-aws-incident.md).

# W43-Lecciones del incidente de AWS

La semana pasada AWS sufrió un fallo grave que duró 15 horas. Interrumpió los servicios de más de 1000 empresas en todo el mundo y causó pérdidas de miles de millones de dólares. Me dejó una lección profunda: ni el diseño de ingeniería más sofisticado puede vencer a una dependencia de un único punto.

El incidente se produjo en us-east-1, la región más importante de AWS. La causa raíz fue un defecto de condición de carrera en la automatización de la gestión DNS de DynamoDB, que vació por error los registros IP del endpoint regional e impidió resolverlo. us-east-1 no es un centro de datos cualquiera. Es el «sistema nervioso central» de la infraestructura mundial de AWS. Los planos de control compartidos de casi todas las regiones dependen de ella, incluidos servicios clave como la planificación de EC2, NLB y Lambda, lo que provocó un colapso en cascada.

Lo más irónico fue que, 75 minutos después de iniciarse el incidente, la página de estado de AWS seguía indicando que todo funcionaba normalmente. CloudWatch también depende de DynamoDB, así que el sistema de monitorización se quedó ciego junto con él.

La recuperación tampoco fue sencilla. Aunque los registros DNS se podían reparar rápidamente, DynamoDB es un nodo central de control. Los planificadores de EC2 tuvieron que reconstruir los arrendamientos de decenas de miles de servidores; los gestores de red tuvieron que eliminar la congestión y distribuir los estados retrasados; y los balanceadores retiraban una y otra vez instancias cuyo estado de salud evaluaban mal. Al final, AWS solo pudo frenar las avalanchas repetidas desactivando las comprobaciones automáticas de salud y la conmutación por error, e interviniendo manualmente.

Después de observar lo ocurrido, conviene revisar nuestros propios servicios. Los que más probabilidades tienen de esconder un punto único de fallo sistémico son, precisamente, los servicios básicos que reciben poca atención durante las iteraciones del negocio. Por ejemplo, el punto de entrada a los sistemas corporativos y los servicios de validación. El primero tiene una lógica de negocio sencilla, pero un radio de impacto enorme: concentra el 80% del tráfico. El diseño de ingeniería de estos servicios debería seguir los principios de dependencias mínimas y entropía máxima, y mantener la mayor claridad y sencillez posibles.

Un componente pequeño como el punto de entrada a los sistemas corporativos puede atraer a un ingeniero ambicioso por sus retos técnicos: mantener varias versiones para distintas tecnologías y afrontar ciclos de publicación largos que dependen de las páginas de negocio que lo alojan. Al repasar lo que hemos hecho este año en ese componente, creo que debemos revisar si elegimos la dirección correcta. Para permitir actualizaciones dinámicas, acortar los ciclos de publicación del negocio y ganar flexibilidad, hicimos mucho trabajo de ingeniería, introdujimos más dependencias y diseñamos una arquitectura más compleja. Al mismo tiempo, las reversiones tardan más en surtir efecto. Siguiendo esa dirección, después de resolver la actualización dinámica, el siguiente paso quizá sea crear un componente dinámico que se ejecute en distintos contenedores, unificar las versiones de implementación del punto de entrada y alcanzar un alto grado de dinamismo y reutilización. Pero, una vez que este componente supere su periodo de iteraciones más intensas, esas funciones empezarán a parecerse a deuda.

Al reflexionar sobre este año, veo que mi atención siguió centrada en entrenar las capacidades de ingeniería y dar al equipo ocasiones de practicar técnicas vistosas. No avancé lo suficiente hacia la mejora de la calidad de las decisiones técnicas desde el principio. En las decisiones faltaban un marco claro, hechos que las sustentaran y deducciones lógicas. Creo que lo único que hicimos bien fue introducir decisiones democráticas y colectivas.

Durante su desarrollo, todo ingeniero pasa por una etapa en la que rechaza la redundancia, abstrae todo y da importancia a la complejidad como medida del nivel técnico. Hay que atreverse a abandonar esas ideas de nivel intermedio y buscar una claridad y una sencillez fruto de sopesar las alternativas, como propone la filosofía de diseño de Unix. Hay que aprender a apreciar lo verdaderamente bueno.