Cuando us‑east‑1 estornuda: Guía de campo de la interrupción de AWS del 19–20 de oct

Name

Akira Sakamoto

Updated on 22/10/2025

Fecha del evento: 19–20 de oct, 2025 (hora del Pacífico) Disparador primario: defecto en la automatización DNS del endpoint regional de DynamoDB Radio de impacto: DynamoDB → lanzamientos de EC2 → Network Manager → NLB → (Lambda, STS, IAM sign‑in, Redshift, ECS/EKS/Fargate, Connect) en us‑east‑1

TL;DR (para personas ocupadas)

• Qué lo inició (11:48 PM 19 de oct): Una condición de carrera en la gestión automatizada de DNS de DynamoDB cambió el endpoint regional dynamodb.us-east-1.amazonaws.com a un registro vacío. Cualquier cosa que intentara abrir una nueva conexión a DynamoDB en us‑east‑1 falló la resolución DNS.
• Recuperación primaria de DynamoDB (2:25–2:40 AM 20 de oct): AWS restauró el DNS correcto; los clientes se recuperaron a medida que expiraron las entradas DNS en caché.
• Por qué no terminó ahí: El plano de control de EC2 depende de DynamoDB para los leases de hosts (“droplets”). Esos leases expiraron durante la ventana DNS, provocando un colapso por congestión en el gestor de flujo de droplets (DWFM) y una acumulación en Network Manager. Los lanzamientos de nuevas instancias EC2 fallaron o arrancaron sin estado de red.
• Turbulencia en los load balancers (5:30 AM–2:09 PM): Los Network Load Balancer (NLB) vieron flapping en las comprobaciones de salud debido a la propagación de red retardada, causando eliminación intermitente de capacidad y errores de conexión.
• Retorno a estado estable completo: La mayoría de los servicios se estabilizaron la tarde del 20 de oct; rezagados de Redshift (por reemplazos de EC2) finalizaron el 21 de oct a las 4:05 AM.

El “qué pasó”, en una línea de tiempo tipo diagrama (PDT)

Dos minutos sobre los conceptos clave (para lectores más nuevos)

DNS (Domain Name System) Piensa en DNS como la guía telefónica de Internet. Preguntas por un nombre; te devuelve dónde llamar (direcciones IP). A hiperescala, los proveedores usan registros DNS y comprobaciones de salud para dirigir tráfico entre enormes flotas y Availability Zones. Es rápido y omnipresente, pero no es una base de datos transaccional; consistencia y orden de cambios son problemas complejos que deben diseñarse cuidadosamente.

DynamoDB Base de datos NoSQL/clave‑valor completamente gestionada de AWS. Bajas latencias, elástica y usada en todas partes —incluido por AWS mismo para planos de control y metadatos. Global Tables se replican entre Regiones. Si tu app o un subsistema de AWS necesita leer/escribir estado de control y no puede alcanzar DynamoDB, las cosas malas se acumulan.

EC2 y el plano de control EC2 ejecuta tus instancias sobre “droplets” (hosts físicos). Servicios internos gestionan leases a esos hosts y propagan el estado de red (rutas, security groups, etc.). Lanzar una nueva instancia es sencillo—a menos que la coordinación interna esté degradada o con colas.

NLB (Network Load Balancer) Un balanceador en capa 4. Realiza comprobaciones de salud y puede enrutar entre AZs. Si las comprobaciones de salud flapear o el failover basado en DNS es demasiado agresivo, puedes eliminar capacidad justo cuando más la necesitas.

Lo que falló realmente: la automatización DNS de DynamoDB

AWS divide la gestión DNS de DynamoDB en dos roles:

• DNS Planner: calcula los conjuntos de registros deseados (qué load balancers, con qué weights) para cada endpoint (regional, FIPS, IPv6, específicos de cuenta).
• DNS Enactor: tres workers redundantes en distintas AZs que aplican esos planes a Route 53, cada uno haciendo actualizaciones transaccionales.

Bajo una contención inusual, un Enactor progresó lentamente mientras otro compitió y avanzó con planes más nuevos y luego garbage‑collected generaciones antiguas. El plan anticuado del Enactor lento sobrescribió el endpoint regional justo antes de que el Enactor rápido eliminara ese plan antiguo—borrando todas las IP del endpoint y dejando el sistema en un estado que bloqueó más actualizaciones automáticas. Humanos intervinieron para reparar.

Por qué importó: el endpoint regional desapareció. Cualquier cosa que necesitara una nueva resolución DNS hacia DynamoDB en us‑east‑1 falló de inmediato. Las conexiones existentes, por lo general, siguieron funcionando.

Por qué cascó: acoplamientos estrechos y la flecha del tiempo

1. Acoplamiento del plano de control (EC2 ⇄ DynamoDB). El Droplet Workflow Manager (DWFM) de EC2 mantiene leases en hosts físicos. Esas comprobaciones dependen de DynamoDB. Durante el evento DNS, los leases expiraron, haciendo que los droplets no fueran elegibles para nueva colocación. Cuando DynamoDB se restauró, DWFM tuvo que re‑establecer leases en una enorme flota, alcanzó timeouts de cola y se congestionó.

2. Propagación de red retrasada. Incluso cuando las instancias empezaron a lanzarse de nuevo, Network Manager tenía una acumulación para publicar su estado de red. Instancias arrancaron sin conectividad completa hasta que las propagaciones se pusieron al día (~10:36 AM).

3. Bucles de retroalimentación en comprobaciones de salud (NLB). Nueva capacidad con estado de red incompleto parecía no saludable, así que NLB retiró nodos o AZs del DNS, reduciendo temporalmente la capacidad y empeorando los errores de conexión. Operadores pausaron el failover automático para detener la oscilación y lo re‑habilitaron tras la estabilización de EC2.

4. Ecos en servicios downstream. Lambda aplicó throttling en ciertas rutas para proteger invocaciones síncronas; STS/IAM sign‑in fallaron y luego se recuperaron; los planos de control de contenedores (ECS/EKS/Fargate) y Connect sufrieron los efectos combinados de EC2/NLB; Redshift añadió otro matiz: la autorización de queries respaldada por IAM falló brevemente a escala global, y algunos clusters esperaron reemplazos de hosts EC2, extendiendo la recuperación hasta 21 de oct.

Si estás pensando “modelo del queso suizo” —muchas capas delgadas de defensa alineadas justo así— estás leyendo bien.

Una mirada de sistemas complejos (por qué “causa raíz” no basta)

Varios practicantes en HN invocaron How Complex Systems Fail de Richard Cook y Normal Accidents de Charles Perrow. Ese encuadre encaja inquietantemente bien aquí:

• No hubo una sola causa. La carrera en DNS encendió la chispa, pero la larga cola vino del modo de recuperación metaestable de EC2 y de la oscilación de comprobaciones de salud del NLB —cada uno un diseño localmente racional que interactuó mal bajo estrés.
• Los sistemas suelen funcionar degradados. Reintentos del Planner/Enactor, expiraciones de leases, colas—fricciones normales que el sistema tolera—se alinearon de forma desafortunada.
• La gente crea seguridad. La automatización se atascó; los operadores improvisaron reparaciones (restauración manual de DNS, throttling/reinicios de DWFM, deshabilitar failover automático de NLB) para volver a coser la tela.

Conclusión: arregla el bug, sí—pero también busca trampas de recuperación metaestable y bucles de retroalimentación que hacen que fallos pequeños se agraven.

Qué dice AWS que va a cambiar

• Automatización DNS de DynamoDB: deshabilitada globalmente mientras corrigen la carrera; agregar salvaguardas para impedir aplicar o eliminar planes incorrectos.
• NLB: añadir un control de velocidad para que el failover por comprobación de salud no pueda eliminar demasiada capacidad demasiado rápido.
• EC2: nuevos test suites de recuperación para DWFM; mejor throttling consciente de colas en sistemas de propagación de datos.

Son las clases correctas de mitigaciones: evitar escrituras dañinas, regular la auto‑sanación y ejercitar rutas de recuperación bajo carga.

Qué puedes hacer (checklist de lunes por la mañana)

Aunque no puedas cambiar AWS, puedes amortiguar el golpe en tu propia pila.

1. Prefiere endpoints regionales y elimina dependencias ocultas en us‑east‑1. Cuando los servicios ofrecen planos de control regionales (p. ej., STS), úsalos. No centralices autenticación o metadatos en us‑east‑1 por costumbre.

2. Diseña para acceso multi‑Region a datos —especialmente para estado crítico de control. DynamoDB Global Tables te permiten conmutar lecturas/escrituras a una segunda Región. Tu código debe tolerar lag de replicación y reconciliar después.

3. Falla cerrado frente a oscilaciones de health‑check. Asegura failover automático con amortiguamiento: múltiples fallos consecutivos, histeresis y topes de capacidad removida por minuto. Considera un interruptor manual (circuit breaker) para detener el flapping.

4. Haz explícitos los grafos de dependencias. Documenta qué servicios deben estar arriba para lanzar/escalar (auth, colas, stores de config). Practica “¿qué pasa si X está lento/no disponible por 2 horas?”

5. Practica recuperaciones metaestables. Día‑caos para el plano de control, no solo para el plano de datos:

   • Simula expiración de leases en una porción de la flota.
   • Satura tu propagador de configuración de red.
   • Ensaya la presión de retroceso y la secuencia de levantar throttles.

6. Cachea con intención. Las cachés DNS ocultaron la latencia de recuperación (los clientes necesitaron expirar TTLs). Para SDKs que abren nuevas conexiones agresivamente, considera pooling de conexiones y backoff exponencial con jitter para evitar reintentos sincronizados.

7. Construye runbooks de “modo seguro”.

   • Reducir concurrencia o aplicar límites de tasa durante picos de error.
   • Preferir drenar backlogs antes de re‑activar auto‑scalers.
   • Usar feature flags para desactivar trabajos costosos en segundo plano durante incidentes del plano de control.

8. Protege tus propios patrones “planner/enactor”. Si generas estado deseado y lo aplicas en otro sitio, añade:

   • Planes versionados con semántica compare‑and‑swap.
   • Limpieza que no pueda eliminar el último plan conocido como bueno.
   • Un lease de escritor único por endpoint o un pequeño secuenciador (vector clock / contador monotónico).

¿Fue esto “malusar DNS”?

No exactamente. A hiperescala, DNS es una herramienta de service discovery y steering porque todos los clientes, librerías y resolvers de VPC la hablan. El pecado aquí no fue usar DNS; fue permitir escritores concurrentes y que un limpiador interactuara sin un orden absoluto, y además dejar que la lógica basada en health‑checks en DNS eliminara capacidad demasiado rápido durante una acumulación de propagación de red. Esas son elecciones de ingeniería corregibles.

Glosario (refrescos de 60 segundos)

• Route 53: el servicio DNS y de health‑checks de AWS. Soporta routing ponderado/latencia/salud y cambios transaccionales de registros.
• TTL (time to live): cuánto tiempo un resolver puede cachear una respuesta DNS. TTL cortos aceleran failover y amplifican la tasa de consultas.
• DWFM (Droplet Workflow Manager): subsistema de EC2 que gestiona leases a hosts físicos.
• Network Manager: propaga la configuración VPC/de red a instancias y dispositivos de red.
• Global Tables (DynamoDB): replicación multi‑Region para tablas, con consistencia eventual y resolución de conflictos.

Reflexiones finales

Esta interrupción no fue “solo DNS.” Fue DNS + recuperación del plano de control + dinámicas de health‑check + intervención humana —un recordatorio de que la disponibilidad es una propiedad del sistema, no de un componente. Lo alentador es lo específicas que son las mitigaciones: serializar la aplicación de planes, modular la remoción de capacidad, y poner a prueba las recuperaciones bajo presión. Copia esos patrones en tu propia pila, y la próxima vez que us‑east‑1 estornude, tu app necesitará menos pañuelos.