AWS ha publicado un informe post-mortem sobre la gran incidencia del 19 al 20 de octubre que afectó a la región N. Virginia (us-east-1). El problema se originó debido a un fallo en la automatización interna que gestiona el DNS de DynamoDB. En un momento crítico, el sistema aplicó un plan vacío para el endpoint regional, lo que impidió la resolución de la dirección dynamodb.us-east-1.amazonaws.com. Este error provocó un efecto dominó que impactó gravemente a múltiples servicios, como IAM, STS, EC2, Lambda y Redshift, entre otros.
Para solucionar la crisis, AWS detuvo la automatización a nivel mundial y restauró manualmente la conectividad del DNS para DynamoDB. Gradualmente, y gracias a reinicios selectivos, la región comenzó a recuperarse.
La cronología del evento indica varios momentos clave. Entre las 08:48 y las 11:40 CEST del 20 de octubre, se observaron altos niveles de errores en las APIs de DynamoDB. Aunque la restauración del DNS comenzó a permitir la conectividad hacia las 11:40, la situación seguía complicada por fallos en el establecimiento de nuevas instancias EC2, y el gestor de flota física experimentó un colapso congestionado que se estabilizó hacia las 19:50. Durante el mismo período, picos en los errores de conexión afectaron al Network Load Balancer (NLB), lo que llevó a la desactivación temporal de su conmutación automática.
El incidente fue causado por un “fallo de carrera” en el sistema DNS de DynamoDB, vinculado a la interacción de múltiples componentes que aplicaron planes de DNS de forma simultánea. Esta situación dejó al endpoint sin dirección IPs y en un estado inconsistente, lo que requirió intervención manual para restablecer el registro adecuado.
El impacto de la caída se extendió por las dependencias cruzadas de muchos servicios en AWS, lo que resaltó la importancia de diseñar aplicaciones con resiliencia ante fallos en la región. En respuesta, AWS ha decidido deshabilitar la automatización DNS de DynamoDB y ha implementado controles que limitan la capacidad de los NLB ante fallos de health checks.
Las lecciones extraídas también servirán como guía para equipos de plataforma y SRE. Se destaca la importancia de tener un diseño que soporte la pérdida de regiones y dependencias internas, así como la necesidad de implementar mecanismos para manejar errores de DNS de manera eficaz. Adicionalmente, se recomendaron prácticas como el uso de cachés razonables para DNS y ajustar los checks de salud para prevenir failovers en cascada.
El informe concluye con reflexiones sobre la región us-east-1, considerada un punto de máxima complejidad en la nube de AWS, y enfatiza la importancia de no depender en exclusiva de ella para sistemas críticos.
Los equipos ahora deben comunicar con claridad el estado de los servicios afectados, los riesgos residuales y los planes de mejora. Se proporcionaron también listas de verificación para ayudar a mitigar riesgos en futuros eventos, centrándose en la resiliencia y la prevención de crisis similares.
