La interrupción de AWS en N. Virginia (us-east-1) del 19–20 de octubre dejó algo más que un rastro de alarmas: expuso lo frágil que puede ser una arquitectura cuando el plano de control depende de un “catálogo” central y este desaparece de la noche a la mañana. El post-mortem publicado por Amazon identifica una causa raíz tan técnica como reconocible para cualquier SRE: un race condition en la automatización interna de DNS de DynamoDB. El sistema aplicó un plan vacío al endpoint regional (dynamodb.us-east-1.amazonaws.com) y la autorreparación quedó bloqueada; a partir de ahí, IAM, STS, EC2, Lambda, NLB, ECS/EKS/Fargate, Redshift y otros servicios arrastraron fallos durante horas.
Para los equipos de sistemas, lo relevante no es solo “qué” se rompió, sino “por qué se propagó” y “qué modificar el lunes por la mañana” para resistir el siguiente incidente, sea en AWS o en cualquier otra nube.
“Esto no va de demonizar una región. Va de diseñar para perder una región y, a veces, para perder tu punto de coordinación. Si el ‘catálogo’ cae, ¿tu negocio puede seguir sirviendo?”
— David Carrero, cofundador de Stackscale (grupo Aire), cloud privado europeo sobre VMware y Proxmox.
Qué pasó realmente (visión de operador)
DynamoDB mantiene en cada región cientos de miles de registros DNS para dirigir tráfico a una flota heterogénea de balanceadores y variantes (público, FIPS, IPv6, endpoints por cuenta). Para gobernar esa complejidad hay dos piezas:
- DNS Planner: calcula periódicamente un plan DNS por endpoint (conjunto de LBs y pesos) según capacidad/salud.
- DNS Enactor: aplica el plan en Route 53 con transacciones atómicas. Por resiliencia, hay tres Enactors independientes (uno por AZ), trabajando en paralelo.
La secuencia fatídica fue un encadenado de tiempos: un Enactor muy retrasado terminó aplicando un plan antiguo justo cuando otro Enactor —que iba al día— había aplicado el plan nuevo y estaba ejecutando la limpieza de planes obsoletos. Resultado: el plan viejo machacó al nuevo y la limpieza borró ese plan por “demasiado antiguo”, dejando el endpoint sin IPs y el sistema en estado inconsistente que impedía nuevas correcciones automáticas. La recuperación exigió intervención manual (parar la automatización, restaurar el estado DNS correcto y desbloquear).
Ese vacío de DNS cortó de raíz las nuevas conexiones a DynamoDB. Con el “catálogo” caído, se encadenó la degradación del plano de control:
- EC2: al volver DynamoDB, el DropletWorkflow Manager (DWFM) intentó reanudar millones de leases con los servidores físicos (“droplets”) y entró en colapso congestivo; la solución fue throttling + reinicios selectivos hasta vaciar colas y normalizar.
- Network Manager: acumuló un backlog de propagaciones de estado de red para instancias nuevas; muchas instancias arrancaban sin conectividad hasta que llegaba su configuración.
- NLB: los health checks vieron nodos intermitentes (sin red todavía), provocando flapping y retiradas de capacidad por failover de AZ; AWS deshabilitó temporalmente esa conmutación automática y la rehabilitó al estabilizar la red.
El resto de impactos son el reflejo de ese cuadro: Lambda priorizando invocaciones síncronas y limitando event sources, ECS/EKS/Fargate con lanzamientos trabados, STS con latencias y Redshift con clústeres en “modifying” al no poder reemplazar hosts.
Lo importante para un sysadmin: patrones que fallaron, patrones que salvan
1) No diseñe solo para perder una AZ: diseñe para perder el “catálogo”
El incidente cae al corazón del control plane. Aunque el data plane estuviera razonablemente sano, sin poder arrancar instancias, propagar red, emitir credenciales o resolver un endpoint, su plataforma se queda sin manos.
Acción: separe conscientemente “sirvo tráfico” de “gestiono recursos”. ¿Puede su aplicación estar horas sin autoscaling, con capacidad preasignada o pool caliente?
“Hablamos mucho de multi-AZ, pero lo que te salva en eventos así es multi-región operativo y capacidad caliente que te permita aguantar sin controlar el orquestador durante un rato.”
— David Carrero (Stackscale)
2) DNS: amortigüe con caché (sin extremos)
La caché DNS amortigua fallos de resolución breves; TTL excesivos pueden retrasar arreglos.
Acción: TTL moderados en resolvers (ni 0 segundos ni días), reintentos con backoff en clientes críticos y, nunca IPs fijas de servicios gestionados.
3) Health checks con gracia: evite el flapping
Llevar en volandas nodos que aún no tienen red dispara falsos negativos y failovers agresivos.
Acción: umbrales, grace periods y velocidad limitada para retirar capacidad. Si despliega en masa, incremente temporalmente los tiempos de evaluación.
4) Circuit breakers y degradación funcional
Si no puede persistir en DynamoDB, ¿puede pasar a lectura-solo? Si no puede crear recursos, ¿puede pausar features no críticas y acumular trabajo localmente?
Acción: añada rutas de degradación y cortes claros por servicio (y métricas para saber cuándo activarlos).
5) STS/IAM: caducidades escalonadas
Evite que todo su parque renueve tokens a la vez cuando hay latencias.
Acción: rotaciones escalonadas, ventanas de gracia y reintentos con jitter.
6) Runbooks y simulacros “us-east-1 fuera de juego”
Documente qué apagar, qué priorizar, a quién avisar y cómo conmutar DNS/Región.
Acción: haga game days realistas: sin lanzamientos nuevos, sin STS, con NLB “nervioso”.
“¿Y si mi negocio no puede permitirse multi-región en nube pública?”
Muchos equipos de sistemas —sobre todo en Europa— optan por una estrategia híbrida: pública donde aporta, cloud privado donde interesa control, soberanía y previsibilidad.
“Nosotros operamos clusters VMware y Proxmox en Europa para empresas que quieren resiliencia y soberanía: latencias controladas, SLAs claros y la posibilidad de replicar entre centros de datos bajo su jurisdicción. No sustituye a la nube pública, la complementa.”
— David Carrero (Stackscale)
Patrones prácticos en privado/híbrido (VMware/Proxmox):
- Activa-activa entre dos CPD en la UE para frontales, APIs idempotentes, colas y cachés (con BGP/Anycast o GSLB simple).
- Replicación síncrona/semisíncrona para datos que lo permitan (latencia < 5–10 ms entre CPD).
- Backups inmutables 3-2-1-1-0 y restore probado (mensual).
- DNS propio + CDN (edge) para absorber picos y servir estáticos si el origen sufre.
- Observabilidad fuera del dominio de fallo principal (logs/métricas/trazas replicados).
- Runbook de “pérdida del orquestador”: ¿cómo opero mi plataforma sin vCenter/Proxmox durante horas?
Qué cambiar “el lunes por la mañana”
- Mapee dependencias del control plane: ¿qué parte de su software necesita crear/actualizar recursos para dar servicio? Enumérelas y proponga modos degradados.
- Revise TTL de DNS y resolvers internos: equilibrio entre resiliencia y tiempo de propagación tras un fix.
- Ajuste health checks en balanceadores: aumente thresholds y añada grace en despliegues masivos; evite reglas que retiren media plataforma por flapping.
- Throttle inteligente en reintentos: limite ráfagas cuando “vuelve” el plano de control para no auto-DDoSearse.
- STS/IAM: escalone expiraciones y alargue temporalmente validez de tokens en incidentes.
- Capacidad caliente: introduzca buffers de capacidad (reservas, instancias warm) para operar sin autoscaling durante X horas.
- Ensayo de conmutación regional: aunque de momento sea manual, practíquelo; si usa DynamoDB Global Tables, añada lógica de failover de cliente a réplicas.
“La lección no es ‘huir’ de Virginia; es no depender en exclusiva de Virginia —o de cualquier región— para tus puntos de coordinación. Reparte el riesgo.”
— David Carrero (Stackscale)
Medidas anunciadas por AWS (que también ayudan a planificar)
- Automatización DNS de DynamoDB deshabilitada globalmente hasta corregir el caso de carrera y añadir barreras contra planes incorrectos.
- NLB: control de velocidad para limitar cuánta capacidad saca un solo NLB ante failover por health check.
- EC2: nuevas pruebas de escala del flujo de recuperación de DWFM y mejoras de throttling basadas en tamaño de colas.
Como siempre, el proveedor endurece su plataforma —y es buena noticia—, pero la resiliencia de su sistema depende de su arquitectura y de sus runbooks.
Conclusión
La caída de us-east-1 no fue una tormenta mística: fue un bug de carrera en un sistema automatizado y crítico (DNS de DynamoDB) que dejó el endpoint sin IPs y bloqueó la autorreparación, arrastrando al plano de control. La respuesta SRE (parar automatismo, restaurar manual, throttling, reinicios selectivos) funcionó, pero tardó. La pregunta para los equipos de sistemas no es si habrá otra; es cuándo y cómo les va a encontrar: con capacidad caliente, degradación controlada y conmutación ensayada, o sin nada de eso. En 2025, el plan sensato combina nube pública con privado europeo bien diseñado, porque la diversidad reduce el riesgo.
Preguntas frecuentes
¿Cómo preparo un “modo degradado” realista si DynamoDB/IAM/STSes mi dependencia?
Defina cortes funcionales: lecturas cacheadas, lectura-solo en picos, queues locales temporales y feature flags para apagar módulos no críticos. Añada reintentos con backoff/jitter y límites por servicio para no colapsar al volver.
¿Qué TTL de DNS recomendar para servicios gestionados?
Evite extremos: TTL moderados (minutos) en resolvers internos amortiguan fallos breves y permiten que un fix se propague sin horas de espera. Complemento indispensable: reintentos y circuit breakers.
Si no puedo costear multi-región en la pública, ¿qué gano con cloud privado europeo?
Control de topología, latencia y jurisdicción; replicación activa-activa entre dos CPD europeos para frontales/datos compatibles y runbooks bajo su control. Lo híbrido le da margen cuando el control plane de un tercero se degrada.
¿Por dónde empiezo a medir que voy a mejor?
Defina objetivos RTO/RPO, tiempo de failover regional, TTFB medio post-incidente y “tiempo hasta primer contenido servido” con el origen caído (CDN + caché). Mida cuántas horas puede operar sin orquestador ni STS.
Fuentes: Post-Event Summary de AWS sobre la interrupción de DynamoDB y los impactos en EC2, NLB y otros servicios en N. Virginia (us-east-1); documentación técnica asociada con las medidas anunciadas tras el evento. Las opiniones de David Carrero (Stackscale) han sido recabadas para este artículo.
vía: Revista Cloud
