La caída en AWS US-EAST-1 expuso la fragilidad de la nube ante fallos en DynamoDB y balanceadores, afectando servicios globales interconectados.
La caída de AWS dfue entre las 23:49 PDT (03:49 de Chile) del 19 de octubre y las 15:01 PDT (19:01 de Chile) del 20 de octubre afectó a múltiples servicios en la región US-EAST-1, con errores elevados y latencias críticas.
El golpe afectó directamente a Amazon.com y a operaciones de soporte, y obligó a aplicar mitigaciones como la limitación temporal de lanzamientos EC2 para estabilizar el plano de control.
El incidente comenzó con un aumento repentino de errores y demoras en los servicios alojados en la región US-EAST-1. Esa degradación afectó la conexión entre componentes internos y externos, lo que interrumpió funciones esenciales de cómputo, bases de datos y monitoreo que sostienen una parte importante del tráfico global de AWS.
En la práctica, las aplicaciones que dependen de esta infraestructura empezaron a perder disponibilidad, evidenciando cuán central es esa región para el ecosistema de la nube.
“A las 11:49 PM PDT (03:49 AM hora de Chile) del 19 de octubre se observaron tasas elevadas de error y latencias en múltiples servicios de la región US-EAST-1”.
La fuerte concentración de dependencias en US-EAST-1 amplificó el problema. Muchos servicios globales de Amazon se apoyan en esa ubicación como punto de control, por lo que una falla en la resolución de nombres o en el sistema de balanceadores se traduce rápidamente en interrupciones visibles para terceros.
El error se originó específicamente en los endpoints regionales de Amazon DynamoDB, donde una falla en la resolución DNS impidió que otros servicios dependientes pudieran localizar las direcciones de sus tablas o ejecutar consultas.
En términos simples, fue como si el sistema de direcciones de una ciudad dejara de funcionar: los servicios sabían adónde querían ir, pero no encontraban el camino, y por eso todas las aplicaciones que dependían de esas rutas quedaron detenidas.
“A las 12:26 AM PDT (04:26 AM hora de Chile) del 20 de octubre se determinó que el evento se originaba en problemas de resolución DNS para los endpoints regionales de DynamoDB”.
A la vez, la caída afectó los sistemas internos de soporte, lo que complicó la gestión de incidencias y la operación de servicios interdependientes como Lambda, SQS o CloudWatch. En los reportes del Health Dashboard se detalló que las fallas en el subsistema de red interno de EC2 afectaron la conectividad de los Network Load Balancers, y que esta degradación provocó errores en cadena en la capa de servicios.
“A las 8:43 AM PDT (12:43 PM hora de Chile) se identificó como origen de los problemas un subsistema interno responsable de monitorear la salud de los Network Load Balancers”.
Analógicamente, es como si el sistema que monitorea la salud de los balanceadores dejó de enviar señales de control, como si los semáforos de una red vial dejaran de coordinarse:
AWS identificó como origen inmediato del incidente una falla en la resolución DNS de los endpoints regionales de Amazon DynamoDB en la región US-EAST-1. Este error impidió que los servicios internos y los clientes pudieran traducir los nombres de dominio del servicio hacia sus direcciones reales, lo que bloqueó el acceso a las bases de datos y detuvo consultas que dependían de esa conexión.
Datos técnicos del fallo:
Un fallo de este tipo equivale a cortar el sistema de direcciones de una ciudad: los servidores siguen operativos, pero los servicios que necesitan encontrarlos no saben cómo llegar, y toda la red de dependencias queda detenida a la espera de referencias válidas.
A partir de ese punto, el error se propagó hacia otros servicios. En los reportes del Health Dashboard se describió que, tras el fallo inicial, surgieron problemas en un subsistema interno de la red EC2 encargado de monitorear el estado de los Network Load Balancers.
Cuando ese sistema dejó de enviar las señales de control, la red perdió su referencia de equilibrio y empezó a generar errores de comunicación entre distintas capas de la infraestructura.
Datos técnicos del subsistema afectado:
El comportamiento del sistema se asemejó a una red de semáforos que pierde su sincronización: cada intersección siguió operando de manera aislada, pero sin referencia común, lo que provocó bloqueos, desvíos aleatorios y tráfico detenido en distintos puntos de la infraestructura.
Esa combinación —la pérdida de resolución de nombres y la degradación del monitoreo de balanceadores— provocó:
El incidente demostró cuán interdependiente es la arquitectura de AWS: una alteración localizada en la red de nombres puede escalar hasta afectar el plano de cómputo global en cuestión de minutos.
Datos técnicos de los efectos combinados:
Esta cadena de errores, se asemeja a una cadena de producción donde una cinta transportadora se detiene, pero las máquinas a su alrededor siguen operando sin coordinación: las tareas se acumulan, los procesos se duplican y el sistema completo pierde ritmo, aunque cada componente individual permanezca encendido.
La caída no solo comprometió servicios clave dentro de AWS, sino también aplicaciones populares que dependen de su red. A continuación, se detallan los componentes y plataformas que presentaron fallas visibles.
A continuación, la lista técnica tras un párrafo de contexto.
Tras el contexto, se lista la data dura visible en el ecosistema.
El registro técnico publicado por AWS documenta con precisión la evolución del incidente, desde la detección de los primeros errores hasta la completa normalización de los servicios, incorporando las horas equivalentes entre PDT y Chile para facilitar la correlación temporal de cada evento crítico.
La restauración de servicios en AWS siguió una secuencia de acciones técnicas orientadas a aislar las causas raíz y estabilizar los planos de datos y red. El proceso combinó la corrección de la falla principal en la capa DNS con la recuperación de los subsistemas internos de monitoreo y control que garantizan la sincronización entre instancias y balanceadores.
Etapas principales de la resolución:
El incidente vuelve a plantear una pregunta esencial: ¿puede una infraestructura definida como descentralizada y resiliente depender tanto de un nodo regional sin comprometer su promesa de continuidad?
