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.
Descripción del problema
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 origen del error de la caída de AWS: Amazon DynamoDB
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:
- Los semáforos de una red vial dejan de coordinarse.
- Cada servicio continúa funcionando de manera aislada, pero sin referencia común.
- El resultado son bloqueos, duplicaciones y rutas perdidas dentro de la infraestructura.
Factores que originaron el problema
El origen del incidente: una falla de DNS en los endpoints de DynamoDB
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:
- Naturaleza del fallo: error lógico en la capa de nombres, no físico en la infraestructura
- Componente afectado: Amazon DynamoDB (endpoints regionales en US-EAST-1)
- Tipo de error: Resolución DNS fallida
- Consecuencia directa: imposibilidad de localizar direcciones IP para las tablas y consultas de DynamoDB
- Impacto inmediato: interrupción de flujos de lectura y escritura entre servicios dependientes
- Dependencias afectadas: EC2, Lambda, SQS, CloudWatch y otros servicios vinculados al plano de datos
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.
Degradación del subsistema EC2 y fallas en los Network Load Balancers
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:
- Componente impactado: sistema interno de monitoreo de salud de los Network Load Balancers (NLB).
- Función principal: verificar la disponibilidad y el estado de los balanceadores para distribuir tráfico entre instancias EC2.
- Tipo de falla: interrupción en la emisión de señales de control desde la red EC2 hacia los balanceadores.
- Efecto inmediato: pérdida de visibilidad del estado de los NLB y degradación de la conectividad interna.
- Servicios arrastrados: Lambda, CloudWatch, DynamoDB y SQS, con errores derivados de dependencias de red.
- Hora registrada: 8:43 AM PDT (12:43 PM hora de Chile), según el registro oficial del AWS Health Dashboard.
- Naturaleza del impacto: fallo de coordinación interna entre los planos de red y cómputo, sin afectación física en infraestructura.
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.
Impacto combinado en los servicios dependientes de AWS
Esa combinación —la pérdida de resolución de nombres y la degradación del monitoreo de balanceadores— provocó:
- Errores de invocación en Lambda,
- Fallas en el lanzamiento de instancias EC2,
- Latencias anómalas en SQS
- Acumulación de tareas en servicios de auditoría y eventos como CloudTrail y EventBridge.
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:
- Causa compuesta: falla de resolución DNS (DynamoDB) + pérdida de señales del monitoreo de los Network Load Balancers.
- Errores resultantes: invocaciones fallidas en Lambda, interrupciones de lanzamiento de instancias EC2 y retrasos en colas SQS.
- Servicios con acumulación de eventos: CloudTrail y EventBridge, con tareas pendientes de auditoría y notificación.
- Efecto estructural: desincronización entre el plano de nombres (DNS) y el plano de red (EC2/NLB).
- Tipo de impacto: lógico y de control, sin daño físico a la infraestructura subyacente.
- Implicancia arquitectónica: evidencia del alto nivel de dependencia interna entre servicios distribuidos, donde un fallo en la capa de nombres puede repercutir directamente en la capacidad de cómputo global.
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.
Servicios de AWS afectos y sitios webs con intermitencia
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.
Servicios de AWS principales afectados por la caída
A continuación, la lista técnica tras un párrafo de contexto.
- DynamoDB: endpoints regionales con fallo de resolución DNS y efectos en Global Tables
- EC2: errores de lanzamiento, mensajes de capacidad y throttling temporal de nuevas instancias
- Lambda: errores de invocación y ajuste de sondeo SQS en los Event Source Mappings
- SQS y EventBridge: retrasos y colas a depurar durante la recuperación
- Network Load Balancer: degradación de health checks que afectó conectividad de servicios
- CloudWatch y CloudTrail: latencias y backlogs de entrega en ventanas específicas
- AWS Config, Redshift y Connect: operación restituida con backlogs en procesamiento
Sitios reconocidos con problemas
Tras el contexto, se lista la data dura visible en el ecosistema.
- Perplexity y otras aplicaciones de IA con interrupciones de acceso y respuestas
- Snapchat, Reddit, Zoom, Venmo y Coinbase con fallas generalizadas en uso masivo
- Fortnite y Epic Games Store con paradas y recuperaciones escalonadas
- Airtable, Canva y Zapier con incidencias en autenticación y flujos de trabajo
- Alexa y Ring con fallas de respuesta y registros ausentes en intervalos
Cronología de la caída basada en AWS Health
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.
¿Cómo se resolvió el problema?
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:
- Corrección del fallo DNS: se abordó la resolución incorrecta de los endpoints regionales de Amazon DynamoDB, restableciendo la traducción de nombres y el acceso a las bases de datos.
- Diagnóstico del impacto residual: se identificaron errores persistentes en servicios dependientes como IAM, Lambda y EC2 debido a la pérdida temporal de conectividad interna.
- Reparación del subsistema EC2: se corrigió el sistema interno encargado de monitorear la salud de los Network Load Balancers, restaurando la coordinación del tráfico entre zonas de disponibilidad.
- Aplicación de throttling controlado: se limitaron temporalmente las operaciones intensivas, especialmente el lanzamiento de nuevas instancias EC2 y el procesamiento de colas SQS por Lambda, para reducir carga y evitar congestión.
- Verificación de estabilidad: se supervisaron las métricas de red, bases de datos y balanceadores hasta confirmar la sincronización entre planos de control y cómputo.
- Normalización final: AWS declaró el restablecimiento total de operaciones a las 07:01 hora de Chile (15:01 PDT), sin registro de daño físico ni pérdida de datos.
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?
Fuente: Reuters | AWS 1 | AWS 2
