La caída de AWS (Amazon Web Services) en la región US-EAST-1, ubicada en Virginia del Norte, se refiere a una interrupción masiva ocurrida el 20 de octubre de 2025, que afectó a servicios globales de la nube de Amazon. Esta región es la más crítica de AWS porque alberga la mayor parte de su infraestructura, datos y servicios para clientes en América del Norte y más allá, lo que amplifica el impacto en aplicaciones como Snapchat, Fortnite, ChatGPT y bancos. El problema principal comenzó con un fallo en la resolución de DNS (Domain Name System) para el endpoint de DynamoDB, un servicio de base de datos clave, propagándose a otros componentes y causando latencias, errores y downtime en cientos de plataformas.
En términos simples, AWS es como un “data center gigante” dividido en regiones geográficas; US-EAST-1 es el “corazón” porque muchas empresas la usan por costos bajos y baja latencia, pero un fallo aquí crea un efecto dominó global. El incidente duró varias horas, con reportes de más de 4 millones de problemas en Downdetector, superando el doble del tráfico normal. AWS confirmó tasas de error elevadas en múltiples servicios y trabajó en mitigaciones, logrando recuperación gradual hacia el mediodía ET.
Secuencia Detallada de la Caída
La explicación proporcionada describe el incidente en seis pasos cronológicos. A continuación, desgloso cada uno de manera sencilla, comparándolo con un “efecto cadena” en un sistema interconectado, como una fábrica donde un engranaje falla y detiene la línea de producción. Usaré analogías cotidianas para claridad, basándome en el comunicado oficial de AWS y reportes de impacto.
① Fallo de DNS impide que los servicios se comuniquen
El DNS es como la “guía telefónica” de internet: traduce nombres amigables (ej. “dynamodb.amazonaws.com”) en direcciones IP numéricas para que servidores se encuentren. En este caso, el fallo inicial ocurrió en el punto de acceso (endpoint) de la API de DynamoDB en US-EAST-1, donde el DNS no resolvió correctamente estas direcciones. Sin DNS funcional, los servicios de AWS no pudieron “encontrarse” entre sí, como si los empleados de una oficina perdieran sus contactos y no pudieran coordinar tareas.
Esto afectó primero a DynamoDB, una base de datos NoSQL que soporta muchas apps (ej. perfiles en Snapchat o puntuaciones en Fortnite). Sin comunicación, requests se atascaron, generando errores inmediatos. El problema se detectó alrededor de las 03:11 ET, propagándose rápidamente porque US-EAST-1 maneja el 60-70% del tráfico de AWS globalmente.
② DynamoDB cae y arrastra a EC2, Lambda y más
DynamoDB es el “almacén central” de datos para muchas aplicaciones serverless y escalables en AWS. Cuando su DNS falló, no pudo procesar lecturas/escrituras, causando que servicios dependientes colapsaran. EC2 (máquinas virtuales para hosting) y Lambda (funciones sin servidor) intentan acceder a DynamoDB para datos, pero al fallar, se “congelan” o devuelven errores, como una cadena de supermercados sin inventario que cierra secciones enteras.
Esto arrastró a servicios como Alexa (no responde comandos), Prime Video (carga infinita) y apps de terceros: ChatGPT (de OpenAI) no cargó, Perplexity falló en búsquedas, y juegos como Roblox/Fortnite no sincronizaron sesiones. Bancos como Lloyds reportaron fallos en apps móviles porque sus backends en AWS no accedieron a datos transaccionales. El impacto fue global porque muchas apps usan US-EAST-1 como primaria, incluso si operan en otras regiones.
③ Después un fallo interno en los balanceadores de red
Una vez que DynamoDB y servicios dependientes fallaron, surgió un problema secundario en los “balanceadores de red” (como Elastic Load Balancers o ALB), que distribuyen tráfico entre servidores. El “deterioro de varios dispositivos de red” (según AWS) impidió enrutar requests correctamente, exacerbando el caos: más latencia y errores porque el tráfico se acumuló en nodos fallidos, como un embotellamiento en una autopista donde los semáforos fallan.
Esto afectó directamente a S3 (almacenamiento), API Gateway y otros, haciendo que incluso servicios no-DynamoDB se volvieran inestables. Usuarios reportaron “503 Service Unavailable” en apps como Zoom y Duolingo, y operaciones internas de Amazon (ej. entregas de paquetes) se detuvieron porque sus apps de logística dependen de estos balanceadores.
④ AWS aplica más mitigaciones y resuelve el problema
AWS activó su “plan de respuesta a incidentes”: ingenieros identificaron la causa raíz (DNS en DynamoDB) y aplicaron mitigaciones, como redirigir tráfico a endpoints alternos, reiniciar componentes afectados y escalar capacidad en otras zonas de disponibilidad (AZs) dentro de US-EAST-1. Es como apagar y reiniciar un router defectuoso, pero a escala masiva, procesando “miles de servidores” en lotes para evitar más disrupciones.
Hacia las 09:50 ET, AWS reportó “señales significativas de recuperación” vía su dashboard de estado, recomendando a clientes reintentar requests fallidos. No pudieron crear tickets de soporte durante el pico, pero priorizaron fixes paralelos (múltiples rutas de resolución). El problema se resolvió principalmente para DNS y balanceadores alrededor del mediodía, aunque latencias persistieron.
⑤ Los servicios comienzan a volver poco a poco
Con las mitigaciones, servicios volvieron en fases: primero DynamoDB (lecturas/escrituras básicas), luego EC2/Lambda (instancias se estabilizaron), y finalmente balanceadores (tráfico fluyó). Apps como Snapchat recuperaron login, Fortnite sincronizó juegos, y ChatGPT respondió consultas, pero no todo fue instantáneo—algunos usuarios en Europa/Asia notaron delays porque dependen de US-EAST-1 para datos globales.
AWS enfatizó que “las solicitudes deberían procesarse correctamente”, pero advirtió latencia adicional. Plataformas como Canva y Signal volvieron intermitentemente, con recuperación total en 4-6 horas para la mayoría. Esto resalta la resiliencia de AWS: su diseño multi-AZ ayudó a contener el daño a una región.
⑥ Aún procesan el enorme backlog de tareas acumuladas
Incluso tras la recuperación, AWS enfrentó un “backlog masivo”: requests pendientes (ej. actualizaciones de datos en DynamoDB) se acumularon durante el outage, como una cola en un banco después de un cierre temporal. Procesarlos tomó horas extras, causando latencias residuales en servicios como Prime Video (buffering) o Venmo (transacciones demoradas).
Clientes con alto volumen (ej. Netflix) notaron picos de uso al reintentar, lo que AWS manejó escalando recursos. Hacia la tarde ET, el backlog se procesó, pero AWS prometió monitoreo continuo para evitar recurrencias, similar a incidentes pasados como el de 2021 donde un fallo en Kinesis propagó efectos similares.
Tabla de Tiempos del Incidente
| Hora (ET) | Evento Principal | Duración Aproximada | Notas de Recuperación |
|---|---|---|---|
| 03:11 | Inicio del fallo DNS en DynamoDB endpoint | ~6-7 horas total | Detección inicial; propagación rápida a servicios dependientes. |
| 04:00-06:00 | Colapso de EC2, Lambda y DynamoDB | Pico de impacto | Efecto dominó; reportes masivos en Downdetector comienzan. |
| 06:30-09:00 | Fallo secundario en balanceadores de red | ~2-3 horas | Latencia extrema; afectación a S3 y API Gateway. |
| 09:50 | Aplicación de mitigaciones por AWS | Inicio de fixes | Redirección de tráfico; recuperación parcial en AZs. |
| 11:00-12:00 | Servicios comienzan a volver (fases) | 1-2 horas | DynamoDB primero, luego EC2/Lambda; latencia residual. |
| 12:00-16:00 | Procesamiento de backlog acumulado | ~4 horas | Picos de uso post-recuperación; monitoreo continuo. |
Esta tabla resume la cronología basada en el dashboard de AWS y reportes en tiempo real, con una duración total estimada de 6-10 horas para recuperación completa. Latencias persistieron hasta la tarde debido al volumen de requests pendientes.
Tabla de Servicios AWS Afectados
| Servicio AWS | Impacto Principal | Apps/Terceros Afectados | Duración de Downtime | Notas |
|---|---|---|---|---|
| DynamoDB | Fallo en lecturas/escrituras (DNS) | ChatGPT, Perplexity, bases de datos apps | ~5-7 horas | Causa raíz; endpoint no resuelto. |
| EC2 | Instancias no responden; hosting falla | Roblox, Fortnite (servidores de juego) | ~4-6 horas | Dependencia de DynamoDB para datos. |
| Lambda | Funciones serverless no ejecutan | AWS Lambda apps, Alexa skills | ~3-5 horas | Invocaciones throttled por red. |
| S3 | Acceso a almacenamiento intermitente | Prime Video, backups | ~2-4 horas | Afectado por balanceadores. |
| ALB/ELB | Balanceo de tráfico colapsa | Zoom, Duolingo (load balancing) | ~3-5 horas | Deterioro de dispositivos de red. |
| API Gateway | Endpoints no responden | Apps móviles de bancos (Lloyds, Venmo) | ~4-6 horas | Propagación de errores DNS. |
| CloudFront | CDN con latencia alta | Snapchat, Canva (entrega de contenido) | ~2-4 horas | Impacto indirecto por US-EAST-1. |
Más de 66 servicios y apps de terceros reportaron problemas, con un enfoque en aquellos dependientes de US-EAST-1. AWS no reportó pérdidas de datos, pero el backlog causó delays en transacciones.
Impacto General y Lecciones
Esta caída afectó a más de 66 empresas reportadas, desde redes sociales hasta IA y finanzas, destacando la dependencia global de AWS: un 30-40% de la nube mundial corre en sus regiones. Para mitigar, AWS recomienda multi-región (ej. replicar en US-WEST-2) y backups en AZs múltiples, como se vio en guías de resiliencia post-2021.
En resumen, fue un recordatorio de que incluso gigantes como AWS no son infalibles; el DNS como “puerta de entrada” es vulnerable, pero su respuesta rápida minimizó daños. Si usas AWS, revisa tu arquitectura para failover (ej. Route 53 para DNS resilient).
