Era un lunes que muchos gerentes de TI recordarán durante mucho tiempo. El 20 de octubre de 2025, Amazon Web Services experimentó una interrupción masiva en la región más importante del norte de Virginia (US-EAST-1), que no solo paralizó numerosas aplicaciones empresariales, sino que también causó efectos absurdos: Incluso los propietarios de colchones en red sintieron las consecuencias. Ahora, Amazon ha publicado un detallado informe post mortem que muestra cómo una pequeña condición de raza en una reacción en cadena podría detener un enorme sistema de nubes.
El efecto dominó: Tres Etapas del Caos
La interrupción comenzó el domingo por la noche a las 11:48 p.m. hora del Pacífico (8:48 a.m. nuestra hora del lunes) y duró hasta la tarde en varias formas. Amazon distingue tres fases principales, algunas de las cuales se superponen y refuerzan entre sí.
En la primera fase, que duró de 8:48 a.m. a 11:40 a.m., la base de datos NoSQL DynamoDB de Amazon aumentó enormemente las tasas de error para el acceso a la API. Eso por sí solo habría sido lo suficientemente dramático, porque DynamoDB es un componente central para innumerables servicios de AWS. Pero debería empeorar.
La segunda fase se desarrolló entre las 2:30 p.m. y las 11:09 p.m.: El balanceador de carga de red (NLB) comenzó a producir mayores errores de conexión. Esto se debió a los controles de salud fallidos en la flota de NLB, lo que dio lugar a que los servidores en funcionamiento se retiraran de la circulación mientras que los fallos permanecían en el sistema.
La tercera fase, y quizás la más notable para muchos usuarios, fue el lanzamiento de nuevas instancias EC2. De 11:25 a.m. a 7:36 p.m. simplemente no funcionó. Incluso cuando las instancias comenzaron de nuevo a las 7:37 p.m., tuvieron problemas de conexión hasta las 10:50 p.m.
La raíz de todo mal: Una condición de raza traicionera
¿Qué pasó ahora? Amazon lo llama un "defecto latente" en el sistema automatizado de administración de DNS de DynamoDB. Esto suena inofensivo al principio, pero ha tenido consecuencias fatales. Para entender lo que salió mal, tienes que sumergirte un poco en la arquitectura.
Servicios como DynamoDB administran cientos de miles de registros DNS para alimentar su vasta y heterogénea flota de balanceadores de carga en cada región. El sistema DNS permite una escalabilidad perfecta, aislamiento de fallas, latencias bajas y acceso local. La automatización es esencial para agregar capacidad adicional, manejar fallas de hardware y distribuir el tráfico de manera eficiente.
El sistema de administración de DNS de Amazon para DynamoDB se divide en dos componentes independientes por razones de disponibilidad. El planificador DNS supervisa el estado y la capacidad de los balanceadores de carga y crea periódicamente nuevos planes DNS para cada punto final del servicio. Estos planes consisten en una colección de balanceadores de carga con los pesos correspondientes. El DNS Enactor, por otro lado, tiene dependencias mínimas e implementa estos planes DNS realizando los cambios necesarios en Amazon Route53. Para la resiliencia, el DNS Enactor se ejecuta de forma redundante y completamente independiente en tres zonas de disponibilidad diferentes.
Cada una de estas instancias independientes del DNS Enactor busca nuevos planes e intenta actualizar Route53 reemplazando el plan actual con un nuevo plan a través de una transacción Route53. Esto garantiza que cada punto final se actualice con un plan coherente, incluso si varios actores DNS intentan realizar actualizaciones al mismo tiempo.
Y aquí está el problema: La condición de raza fue creada por una interacción poco probable entre dos actores de ADN. Normalmente, un DNS Enactor toma el último plan y trabaja a través de los puntos finales de servicio para aplicar ese plan. Antes de aplicar un nuevo plan, verifica una vez si su plan es más nuevo que el plan aplicado anteriormente. A medida que pasa por la lista de puntos finales, puede haber retrasos cuando otro DNS Enactor está actualizando el mismo punto final. En tales casos, el DNS Enactor volverá a intentar cada punto final hasta que el plan se haya aplicado con éxito a todos los puntos finales.
Poco antes de la interrupción, un DNS Enactor experimentó retrasos inusualmente altos y tuvo que probar sus actualizaciones repetidamente en varios puntos finales de DNS. A medida que avanzaba lentamente a través de los puntos finales, varias otras cosas sucedieron al mismo tiempo: El planificador DNS continuó funcionando y produjo muchas nuevas generaciones de planes. Otro Enactor de ADN luego comenzó a aplicar uno de estos planes más nuevos y rápidamente superó todos los puntos finales.
El momento de estos eventos desencadenó la condición de raza latente. Cuando el segundo Enactor (que aplicó el último plan) completó sus actualizaciones de punto final, comenzó el proceso de limpieza del plan, que identifica planes significativamente más antiguos que el que acaba de aplicar, y los elimina. Fue en este punto que el primer Enactor (inusualmente retrasado) aplicó su plan mucho más antiguo al punto final regional de DynamoDB, anulando el plan más nuevo. La auditoría al comienzo del proceso de solicitud del plan estaba obsoleta debido a los retrasos inusualmente altos y no impidió que el plan anterior sobrescribiera el nuevo.
El proceso de limpieza del segundo actor luego borró este plan más antiguo porque era muchas generaciones más antiguo que el plan que acababa de aplicar. Cuando se eliminó este plan, todas las direcciones IP para el punto final regional se eliminaron inmediatamente. Además, la eliminación del plan activo puso al sistema en un estado inconsistente que impidió que las actualizaciones posteriores del plan fueran aplicadas por cualquier agente DNS. En última instancia, esta situación requirió la intervención manual de los operadores.
¿El resultado? El registro DNS de «dynamodb.us-east-1.amazonaws.com» estaba repentinamente vacío. Todos los sistemas que querían conectarse a DynamoDB en el norte de Virginia corrieron inmediatamente contra errores de DNS. Esto afectó tanto al tráfico de clientes como al tráfico de los servicios internos de AWS que dependen de DynamoDB.
Las consecuencias: Cuando la infraestructura falla
A las 9:38 a.m., los técnicos identificaron el error en la administración de DNS. Las contramedidas temporales iniciales tuvieron lugar a las 10:15 a.m. y permitieron que algunos servicios internos se reconectaran a DynamoDB. Esto era importante para desbloquear herramientas internas críticas necesarias para una mayor recuperación. A las 11:25 a.m., toda la información DNS fue restaurada.
Pero la crisis estaba lejos de terminar. Las instancias EC2 aún no querían comenzar. La razón de esto fue DropletWorkflow Manager (DWFM), que es responsable de administrar todos los servidores físicos subyacentes que EC2 utiliza para alojar instancias EC2. Amazon llama internamente a estos servidores «gotas».
Cada DWFM gestiona una serie de gotas dentro de cada zona de disponibilidad y mantiene un contrato de arrendamiento para cada gota actualmente bajo su gestión. Este contrato de arrendamiento permite al DWFM rastrear el estado de la gota y garantizar que todas las acciones de la API EC2 o dentro de la propia instancia EC2, como las operaciones de apagado o reinicio que se originan en el sistema operativo de la instancia EC2, resulten en los cambios de estado correctos en los sistemas EC2 más amplios. Como parte de esta gestión de arrendamiento, cada host DWFM debe registrarse y realizar una verificación de estado cada pocos minutos en cada gota que administran.
Sin embargo, este proceso depende de DynamoDB. Cuando DynamoDB no estaba disponible, estas comprobaciones de estado comenzaron a fallar. Si bien esto no afectó a la ejecución de instancias EC2, significaba que la gota tenía que establecer un nuevo contrato de arrendamiento con un DWFM antes de que pudieran producirse más cambios en el estado de la instancia para las instancias EC2 que aloja. Entre las 11:48 p.m. y las 2:24 a.m., los arrendamientos entre DWFM y Droplets en la flota EC2 comenzaron a disminuir lentamente.
Cuando DynamoDB volvió a estar disponible a las 2:25 a.m. hora del Pacífico (11:25 a.m. de nuestro tiempo), DWFM comenzó a restaurar los arrendamientos con gotitas en toda la flota de EC2. Dado que cada gota sin un arrendamiento activo no se considera candidata para nuevos lanzamientos de EC2, las API de EC2 devolvieron «errores de capacidad insuficientes» para las nuevas solicitudes de lanzamiento de EC2 entrantes.
Había un problema pérfido aquí: Debido a la gran cantidad de gotas, los intentos de establecer nuevos arrendamientos de gotas tardaron tanto tiempo que el trabajo no pudo completarse antes de que se volvieran a ejecutar en los tiempos de espera. El trabajo adicional se puso en cola para tratar de establecer el contrato de arrendamiento de gotas de nuevo. En este punto, DWFM había entrado en un estado de colapso congestivo y ya no podía hacer ningún progreso en la recuperación de los arrendamientos de gotas.
Dado que no había un procedimiento de recuperación operacional establecido para esta situación, los ingenieros procedieron con cautela a resolver el problema con DWFM sin causar más problemas. Después de varios intentos de mitigación, los ingenieros aceleraron el trabajo entrante a las 4:14 a.m. hora del Pacífico y comenzaron reinicios selectivos de hosts DWFM. Reiniciar los hosts de DWFM despejó las colas de DWFM, redujo los tiempos de procesamiento y permitió el establecimiento de arrendamientos de gotas. A las 5:28 a.m., DWFM había establecido arrendamientos con todas las gotitas en la región de Virginia del Norte, y los nuevos lanzamientos comenzaron a tener éxito nuevamente, aunque muchas solicitudes todavía vieron errores de «límite de solicitud excedido» debido a la limitación de la solicitud introducida.
El gestor de la red: Cuando la creación de redes se está quedando atrás
Pero incluso entonces, los problemas no habían terminado. Cuando se inicia una nueva instancia EC2, un sistema llamado Network Manager propaga la configuración de red que permite a la instancia comunicarse con otras instancias dentro de la misma nube privada virtual (VPC), otros dispositivos de red VPC e Internet.
A las 5:28 a.m. hora del Pacífico (14:28 p.m. de nuestro tiempo), poco después de que se restaurara DWFM, el administrador de red comenzó a propagar configuraciones de red actualizadas a instancias recién lanzadas e instancias que se habían terminado durante el evento. Dado que estos eventos de propagación de la red se habían retrasado por el problema DWFM, una acumulación significativa de propagaciones del estado de la red tuvo que ser procesada por el Administrador de la Red en la región del norte de Virginia.
Como resultado, a las 6:21 a.m., el Administrador de Red comenzó a experimentar mayores latencias en los tiempos de propagación de la red mientras trabajaba para procesar la acumulación de cambios de estado de la red. Si bien las nuevas instancias EC2 podían iniciarse con éxito, no tenían la conectividad de red necesaria debido a los retrasos en la propagación del estado de la red. Los ingenieros trabajaron para reducir la carga en el Administrador de red para abordar los tiempos de propagación de la configuración de la red y tomaron medidas para acelerar la recuperación. A las 10:36 a.m., los tiempos de propagación de la configuración de red habían vuelto a la normalidad, y los nuevos inicios de instancia EC2 volvieron a la normalidad.
Balanceador de carga de red: El sistema de salud se está enfermando
Los retrasos en la propagación del estado de la red para las instancias EC2 recién lanzadas también afectaron al servicio Network Load Balancer (NLB) y a los servicios de AWS que usan NLB. Entre las 5:30 a.m. y las 2:09 a.m. hora del Pacífico el 20 de octubre, algunos clientes experimentaron mayores errores de conexión con sus NLB en la región del norte de Virginia.
NLB se basa en una arquitectura de múltiples inquilinos altamente escalable que proporciona puntos finales de equilibrio de carga y enruta el tráfico a destinos de backend que suelen ser instancias EC2. La arquitectura también utiliza un subsistema de chequeo de salud separado que regularmente realiza chequeos de salud contra todos los nodos dentro de la arquitectura NLB y elimina cualquier nodo del servicio que se considere insalubre.
Durante el evento, el subsistema de verificación de salud NLB comenzó a experimentar un aumento de los errores de verificación de salud. Esto fue causado por la puesta en marcha de nuevas instancias EC2 por parte del subsistema de comprobación de estado, mientras que el estado de la red para estas instancias aún no se había propagado por completo. Esto significaba que, en algunos casos, los controles de salud fallaban, aunque los nodos NLB subyacentes y los objetivos de backend eran saludables. Esto llevó a que los controles de salud cambiaran entre fallidos y saludables. Esto causó que los nodos NLB y los objetivos de backend se eliminaran del ADN solo para volver a ponerse en funcionamiento en el próximo chequeo de salud exitoso.
La alternancia de los resultados del chequeo de salud aumentó la carga en el subsistema de chequeo de salud y causó su degradación, causando retrasos en los chequeos de salud y desencadenando la conmutación automática por error de ADN AZ. Para los equilibradores de carga multi-AZ, esto dio como resultado que la capacidad se retirara del servicio. En este caso, una aplicación experimentó mayores errores de conexión cuando la capacidad sana restante era insuficiente para soportar la carga de la aplicación.
A las 9:36 a.m., los ingenieros desactivaron la conmutación automática por error de verificación de salud para NLB, permitiendo que todos los nodos NLB sanos disponibles y los objetivos de backend vuelvan a ponerse en funcionamiento. Esto resolvió el aumento de los errores de conexión a los balanceadores de carga afectados. Poco después de que EC2 se recuperara, reactivaron la conmutación por error automática de la verificación de salud del DNS a las 2:09 a.m. hora del Pacífico.
El impacto: Una cola de rata de problemas
La interrupción de DynamoDB y los problemas resultantes han tenido consecuencias de gran alcance para muchos otros servicios de AWS. Las funciones de Lambda entregaron errores de API y latencias entre las 11:51 p.m. del 19 de octubre y las 2:15 p.m. hora del Pacífico del 20 de octubre. Inicialmente, los problemas de punto final de DynamoDB impidieron la creación y actualización de funciones, causaron retrasos en el procesamiento de las fuentes de eventos SQS/Kinesis y errores de llamada.
Amazon Elastic Container Service (ECS), Elastic Kubernetes Service (EKS) y Fargate experimentaron errores de lanzamiento de contenedores y retrasos en la escala del clúster entre las 11:45 p.m. del 19 de octubre y las 2:20 a.m. hora del Pacífico del 20 de octubre.
Los clientes de Amazon Connect experimentaron un aumento de los errores en el manejo de llamadas, chats y casos entre las 11:56 p.m. del 19 de octubre y la 1:20 a.m. hora del Pacífico del 20 de octubre. Las llamadas entrantes escucharon caracteres ocupados, mensajes de error o conexiones fallidas experimentadas. Las llamadas salientes iniciadas por el agente y las iniciadas por la API fallaron.
El servicio de tokens de seguridad de AWS (STS) experimentó errores de API y latencia entre las 11:51 p.m. y las 9:59 a.m. Los clientes que intentaron iniciar sesión en la consola de administración de AWS con un usuario de IAM experimentaron un aumento de los errores de autenticación debido a problemas subyacentes de DynamoDB entre las 11:51 p.m. del 19 de octubre y la 1:25 a.m. hora del Pacífico del 20 de octubre.
Los clientes de Amazon Redshift experimentaron errores de API al crear y modificar clústeres de Redshift o al ejecutar consultas contra clústeres existentes entre las 11:47 p.m. del 19 de octubre y las 2:21 a.m. hora del Pacífico del 20 de octubre. Curiosamente, los clientes de Redshift en todas las regiones de AWS no pudieron usar las credenciales de usuario de IAM para ejecutar consultas entre las 11:47 p.m. del 19 de octubre y la 1:20 a.m. del 20 de octubre, porque un defecto de Redshift usó una API de IAM en la región del norte de Virginia para resolver grupos de usuarios.
Las enseñanzas: Lo que Amazon está cambiando
Amazon ya ha tomado varias medidas y planea hacer más cambios para evitar la recurrencia. DynamoDB DNS Planner y DNS Enactor han sido deshabilitados en todo el mundo. Antes de reactivar esta automatización, Amazon arreglará el escenario de condición de carrera y agregará salvaguardas adicionales para evitar la aplicación de planes DNS falsos.
Para el balanceador de carga de red, se agrega un mecanismo de control de velocidad que limita la capacidad que un solo NLB puede eliminar si los errores de comprobación de estado causan una conmutación por error AZ. Esto es para evitar que se retire de la circulación demasiada capacidad a la vez.
Para EC2, Amazon está construyendo una suite de pruebas adicional para complementar sus pruebas de escalamiento existentes. Esto se ejecutará a través del flujo de trabajo de recuperación de DWFM para identificar futuras regresiones. Además, se mejora el mecanismo de estrangulamiento en los sistemas de propagación de datos EC2 para limitar el trabajo entrante en función del tamaño de la cola y proteger el servicio durante períodos de alta carga.
Conclusión: Cuando la redundancia no es suficiente
Esta interrupción demuestra de manera impresionante lo complejas que son las infraestructuras modernas en la nube y cómo una vulnerabilidad aparentemente pequeña —una condición racial que es poco probable que ocurra en circunstancias normales— puede dar lugar a una cascada de interrupciones. A pesar de todas las redundancias, a pesar de los actores DNS de triple diseño en diferentes zonas de disponibilidad, a pesar de la automatización sofisticada, un momento desafortunado podría derribar todo el sistema.
En su informe final, Amazon dijo que se disculpó por el impacto en sus clientes. Sabemos lo críticos que son los servicios para los clientes, sus aplicaciones, los usuarios finales y sus negocios. Haremos todo lo posible para aprender de este evento y usarlo para mejorar aún más la disponibilidad.
Para nosotros como usuarios, la visión sigue siendo: La nube puede ser robusta, pero no es infalible. Las estrategias multirregionales, los planes de recuperación en casos de desastre y los mecanismos alternativos no son paranoia, sino necesidad. Y a veces es el colchón en red lo que nos recuerda cuán dependientes nos hemos vuelto de esta infraestructura invisible.
ES 
DE 
EN 
FR 
IT