AWS ha publicado el informe post-mortem de la interrupción que el 19 y 20 de octubre dejó fuera de juego a la región N. Virginia (us-east-1) y arrastró a decenas de servicios. El detonante fue tan sutil como devastador: un fallo de carrera (race condition) en la automatización interna que gestiona el DNS de Amazon DynamoDB. Ese bug terminó aplicando un plan DNS vacío sobre el endpoint regional dynamodb.us-east-1.amazonaws.com, impidiendo su resolución. Sin el “catálogo” que coordina a buena parte del plano de control de AWS, el efecto dominó no tardó en llegar: IAM, STS, EC2, Lambda, NLB, ECS/EKS/Fargate, Redshift y otros servicios encadenaron errores durante horas.
La compañía reconoce que tuvo que detener la automatización responsable a nivel global, restaurar manualmente el estado de DNS para DynamoDB y, a partir de ahí, ir desbloqueando subsistemas con reinicios selectivos y limitación temporal de peticiones para recuperar la región de forma escalonada. El documento oficial detalla con precisión qué pasó, por qué pasó y qué cambios se implementarán para evitar que ocurra de nuevo.
Cronología de un colapso (visión general)
AWS identifica tres ventanas principales de impacto (horario local de la Costa Oeste de EE. UU., PDT):
- 19/10, 23:48 – 20/10, 02:40: DynamoDB sufre un aumento de errores en las APIs. Clientes y servicios internos de AWS que dependen de DynamoDB no pueden abrir nuevas conexiones porque el endpoint regional deja de resolverse.
- 20/10, 02:25 – 10:36: Lanzar nuevas instancias de EC2 falla durante horas; cuando los arranques comienzan a funcionar, algunas instancias recién creadas no tienen conectividad por retrasos en la propagación de estado de red.
- 20/10, 05:30 – 14:09: Network Load Balancer (NLB) registra errores de conexión en parte de la flota debido a fallos espurios de health check: entra en servicio capacidad cuya red aún no estaba propagada, los chequeos fluctúan y la capa de orquestación saca y mete nodos de DNS, degradando el plano de datos.
En paralelo, servicios como Lambda (invocaciones y event sources), ECS/EKS/Fargate (arranque de contenedores y scaling), Amazon Connect (atención de llamadas/chats), STS (emisión de credenciales de corta vida) e incluso Redshift (consultas y modificaciones de clúster) sufren impactos por depender directa o indirectamente de DynamoDB, de nuevos launches en EC2 o del correcto comportamiento de NLB.
La raíz del problema: Planner, Enactor… y un vacío de DNS
DynamoDB opera cientos de miles de registros DNS por región para dirigir tráfico a un parque heterogéneo de balanceadores (y variantes como endpoint público, FIPS, IPv6, endpoints por cuenta, etc.). Esa complejidad se gobierna con dos módulos:
- DNS Planner: calcula de forma periódica un plan DNS para cada endpoint (lista de balanceadores y pesos) según capacidad y salud.
- DNS Enactor: aplica esos planes en Amazon Route 53 mediante transacciones atómicas. Por resiliencia, existen tres Enactors, uno en cada AZ, actuando en paralelo y de forma independiente.
El bug emerge cuando un Enactor retrasado intenta terminar de aplicar un plan antiguo al mismo tiempo que otro Enactor, que iba al día, termina de aplicar un plan nuevo y lanza su limpieza de planes obsoletos. La secuencia, improbable pero posible, fue esta:
- El Enactor atrasado machaca en el endpoint regional el plan nuevo con un plan viejo (la comprobación “esto es más nuevo que lo anterior” quedó obsoleta por el retraso acumulado).
- El Enactor que iba al día ejecuta la limpieza y borra el plan viejo por “demasiado antiguo”.
- Resultado: el endpoint regional queda sin direcciones y el sistema, en un estado inconsistente que bloquea futuras correcciones automáticas.
- Solución: intervención manual para reponer el estado correcto en Route 53 y desbloquear el ciclo.
Desde ese momento, todo lo que dependía de resolver DynamoDB empezó a fallar.
EC2: por qué no se podían lanzar instancias nuevas aunque “Dynamo ya volvía”
Restaurado el DNS de DynamoDB, quedaba por delante recuperar el plano de control de EC2. Aquí entran dos piezas internas:
- DropletWorkflow Manager (DWFM): gestiona los servidores físicos (llamados droplets) que alojan instancias EC2 y mantiene un “arrendamiento” (lease) activo por cada droplet.
- Network Manager: propaga el estado de red (rutas, reglas, adjuntos) a instancias y appliances.
Durante la caída de DynamoDB, los chequeos periódicos de DWFM a sus droplets fallaban y los leases fueron expirando de forma gradual. Con DynamoDB de vuelta, DWFM intentó re-tomar millones de leases a la vez; la operación fue tan voluminosa que entró en colapso congestivo (colas que se reintentan y vuelven a expirar). La receta de recuperación fue clásica SRE: estrangular entrada (throttling) y reinicios selectivos de los hosts de DWFM para vaciar colas y reducir latencias. Con los leases restablecidos, los lanzamientos empezaron a funcionar.
Quedaba el Network Manager: debía propagar el estado de red a todas las nuevas instancias y a las terminadas durante el evento. El backlog fue tal que la propagación se retrasó: instancias “recién nacidas” arrancaban sin conectividad hasta que su configuración llegaba. Ese desfase, a su vez, confundió al subsistema de health checks de NLB, que alternaba estados (flapping), sacando y metiendo capacidad en DNS de forma agresiva y provocando errores de conexión.
Para cortar la sangría, AWS deshabilitó temporalmente el failover automático por health check de NLB, devolvió capacidad a servicio y, más tarde, volvió a habilitarlo cuando EC2 y la red se estabilizaron.
Otros impactos relevantes
- Lambda: fallos iniciales por el endpoint de DynamoDB (creación, updates, triggers SQS/Kinesis). Horas después, con EC2 aún degradado, AWS priorizó invocaciones síncronas y limitó event source mappings y asíncronas para evitar cascadas.
- STS e IAM: errores de autenticación y latencias (dependencia indirecta de DynamoDB y, después, de NLB).
- Amazon Connect: errores en llamadas, chats y paneles por combinación de problemas en NLB y Lambda.
- Redshift: detenciones en consultas y operaciones de clúster; algunos clústeres quedaron “modifying” al no poder reemplazar hosts EC2 durante horas. Un defecto adicional afectó a consultas con credenciales IAM en todas las regiones durante un intervalo al depender de un API IAM en us-east-1 para resolver grupos: los clústeres con usuarios locales no se vieron afectados.
Qué va a cambiar AWS
El post-mortem anuncia medidas concretas:
- Automatización DNS de DynamoDB (Planner/Enactor) deshabilitada globalmente hasta corregir el escenario de carrera e introducir barreras adicionales para impedir planes incorrectos.
- NLB: control de velocidad para limitar cuánta capacidad puede retirar un único NLB cuando los health checks disparan un failover de AZ.
- EC2: nueva batería de pruebas que ejercita el flujo de recuperación de DWFM a gran escala y mejoras de throttling en los sistemas de propagación de datos, ajustando el ritmo según tamaño de cola para proteger el servicio.
Lecciones para arquitectos y SRE: diseñar para perder el “catálogo”
- No basta con multi-AZ; piense en multi-región (y multi-proveedor si procede).
Si su negocio no tolera horas de indisponibilidad, active-active o pilot light en otra región es la ruta. Para datos en DynamoDB, Global Tables ayuda… pero recuerde que el tráfico contra el endpoint regional caído no conmutará solo: la app debe saber usar réplicas cuando una región no responde (y aceptar lag temporal). - Diferencie data plane y control plane en el diseño.
Su aplicación puede seguir dando servicio con el plano de datos estable aunque el plano de control (lanzar instancias, actualizar configs, emitir credenciales) esté degradado. ¿Tiene capacidad caliente o pool de instancias para aguantar sin autoscaling? ¿Es capaz de degradar funciones que requieren recursos nuevos? - DNS: caché razonable, sin extremos.
Un TTL sensato amortigua fallos transitorios de resolución. Evite “TTL 0” por defecto, pero tampoco “hiper-largo”: cuando el proveedor arregle el endpoint, no quiere esperar horas para que caduquen cachés antiguas. En clientes críticos, evalúe resolver con reintentos y backoff y no fije IPs de servicios gestionados. - Health checks con paciencia (evite el flapping).
Defina umbrales y grace periods para no retirar capacidad por chequeos transitorios cuando hay propagaciones de red en curso. Un failover agresivo multiplica el problema: saca nodos sanos cuyo networking aún no ha llegado y empeora la congestión. - Circuit breakers y rutas de degradación funcional.
Si no puede escribir en DynamoDB, ¿puede pasar temporalmente a lectura-solo? Si no puede crear colas/instancias nuevas, ¿puede acumular trabajo en buffers locales o pausar componentes no críticos? - Credenciales y sesión.
Evite caducidades simultáneas de tokens. Cuando STS/IAM sufran latencias, no querrá que todo su parque intente renovar a la vez. Escalone y alargue márgenes prudencialmente durante eventos. - Runbooks y simulacros “us-east-1 cae”.
Documente quién hace qué y en qué orden: activar límites, desactivar partes del pipeline, conmutar DNS/Región, priorizar colas, etc. Ensaye los playbooks.
¿Es Virginia “el canario” de AWS?
En foros técnicos se repite una idea: us-east-1 es la región más grande, antigua y con más productos “rozando producción”; por tanto, más expuesta a incidentes complejos y a efectos sistémicos. Hay quien la considera el “canario” de AWS. Más allá del apodo, el mensaje práctico para las empresas es claro: no concentre todas las dependencias críticas en esa región, especialmente control plane y puntos únicos de coordinación. Diseñe pensando en que una región puede quedar degradada durante horas… o inaccesible por razones ajenas a su arquitectura.
Qué comunicar ahora a negocio (y a sus clientes)
- Qué ocurrió en su plataforma (fechas, servicios afectados, duración).
- Qué medidas de contingencia aplicó y qué riesgos residuales quedan (reprocesos, backlogs, datos retrasados).
- Qué hará a corto/medio plazo: backlog de cambios (multi-región, TTL DNS, health checks, throttling, capacidad pre-asignada) con fechas y responsables.
- Cómo medirán mejoras: indicadores de continuidad, RTO/RPO y metas de resiliencia.
Conclusión
El incidente de us-east-1 no fue una “tormenta perfecta” de la nada: fue la manifestación de un fallo de carrera escondido en un sistema crítico y automatizado (la gestión de DNS para un servicio central) que, al activarse, vació un endpoint y bloqueó la autorreparación. A partir de ahí, el resto son dependencias cruzadas y congestiones propias de cualquier plataforma a hiperescala. La buena noticia es que el post-mortem trae acciones concretas; la menos buena, que no hay magia: la resiliencia de cada empresa no la da el proveedor por decreto, se diseña. Y ese diseño empieza por aceptar que una región —incluso la más famosa del mundo— puede fallar cuando menos conviene.
Preguntas frecuentes
¿Cómo reducir el impacto de una caída regional de AWS en un e-commerce o medio digital?
Implemente multi-AZ + multi-región para el frontend y servicios críticos (cache/CDN, autenticación, catálogo). Use DynamoDB Global Tables o réplicas gestionadas donde proceda y asegure que la aplicación conmute a réplicas/regiones cuando un endpoint no responde. Mantenga capacidad caliente para servir sin autoscaling.
¿Por qué falló Network Load Balancer si “solo” estaba afectado DynamoDB?
Porque tras restaurar el DNS de DynamoDB, EC2 tardó en rearmar leases y propagar red a instancias nuevas. NLB trajo nodos a servicio antes de que su conectividad estuviera lista; los health checks fluctuaron y la lógica de failover retiró capacidad sana. Ajuste umbrales y grace periods y evite flapping en despliegues masivos.
¿Debo bajar los TTL de DNS para responder más rápido a arreglos del proveedor?
Un TTL moderado ayuda a amortiguar cortes breves y permite que el arreglo se propague sin esperar horas. Evite extremos (TTL 0 o muy altos) y complemente con reintentos y circuit breakers en clientes. No fije IPs de servicios gestionados.
¿Tiene sentido evitar us-east-1?
Más que “evitar”, diversifique. Es una región clave por latencia hacia EE. UU. y por abanico de servicios, pero concentre lo menos posible sus “puntos de coordinación” (autenticación, colas, catálogos) solo allí. Diseñe para degradación controlada y conmutación regional.
Fuentes: Post-Event Summary de AWS sobre la interrupción de DynamoDB y los impactos en EC2, NLB y otros servicios en N. Virginia (us-east-1), y documentación técnica de AWS relacionada con el incidente y las medidas anunciadas.
