--- title: "El “race condition” que tumbó Virginia: anatomía de la caída de AWS en us-east-1 y las lecciones que deja para arquitectos cloud" description: "AWS ha publicado el informe post-mortem de la interrupción que el 19 y 20 de octubre dejó fuera de juego a la región N. Virginia (us-east-1) y arrastró a decenas de servicios. El detonante fue tan sut..." url: https://revistacloud.com/el-race-condition-que-tumbo-virginia-anatomia-de-la-caida-de-aws-en-us-east-1-y-las-lecciones-que-deja-para-arquitectos-cloud/ date: 2025-10-24 modified: 2025-10-24 author: "Silvia A. Feliz" image: https://revistacloud.com/wp-content/uploads/2025/10/aws-us-east-1-postmortom.jpg categories: ["Análisis y opinión", "Noticias"] tags: ["amazon", "aws", "postmortem", "us-east-1", "Virginia"] type: post lang: es --- # El “race condition” que tumbó Virginia: anatomía de la caída de AWS en us-east-1 y las lecciones que deja para arquitectos cloud AWS ha publicado el informe post-mortem de la interrupción que el **19 y 20 de octubre** [dejó fuera de juego a la región **N. Virginia (us-east-1)**](https://revistacloud.com/falla-masiva-aws-region-us-east-1/) y arrastró a decenas de servicios. El detonante fue tan sutil como devastador: un **fallo de carrera** (*race condition*) en la automatización interna que gestiona el **DNS de Amazon DynamoDB**. Ese bug terminó aplicando un **plan DNS vacío** sobre el endpoint regional **`dynamodb.us-east-1.amazonaws.com`**, impidiendo su resolución. Sin el “catálogo” que coordina a buena parte del plano de control de AWS, el efecto dominó no tardó en llegar: **IAM, STS, EC2, Lambda, NLB, ECS/EKS/Fargate, Redshift** y otros servicios encadenaron errores durante horas. La compañía reconoce que tuvo que **detener la automatización** responsable a nivel global, **restaurar manualmente** el estado de DNS para DynamoDB y, a partir de ahí, ir desbloqueando subsistemas con **reinicios selectivos** y **limitación temporal de peticiones** para recuperar la región de forma escalonada. El documento oficial detalla con precisión qué pasó, por qué pasó y qué cambios se implementarán para evitar que ocurra de nuevo. --- ## Cronología de un colapso (visión general) AWS identifica **tres ventanas principales** de impacto (horario local de la Costa Oeste de EE. UU., PDT): - **19/10, 23:48 – 20/10, 02:40**: **DynamoDB** sufre un aumento de errores en las APIs. Clientes y servicios internos de AWS que dependen de DynamoDB **no pueden abrir nuevas conexiones** porque el endpoint regional **deja de resolverse**. - **20/10, 02:25 – 10:36**: **Lanzar nuevas instancias de EC2** falla durante horas; cuando los arranques comienzan a funcionar, **algunas instancias recién creadas no tienen conectividad** por retrasos en la propagación de estado de red. - **20/10, 05:30 – 14:09**: **Network Load Balancer (NLB)** registra **errores de conexión** en parte de la flota debido a **fallos espurios de health check**: entra en servicio capacidad cuya red **aún no estaba propagada**, los chequeos fluctúan y la capa de orquestación saca y mete nodos de DNS, degradando el plano de datos. En paralelo, servicios como **Lambda** (invocaciones y *event sources*), **ECS/EKS/Fargate** (arranque de contenedores y *scaling*), **Amazon Connect** (atención de llamadas/chats), **STS** (emisión de credenciales de corta vida) e incluso **Redshift** (consultas y modificaciones de clúster) sufren impactos por depender directa o indirectamente de DynamoDB, de nuevos *launches* en EC2 o del correcto comportamiento de NLB. --- ## La raíz del problema: Planner, Enactor… y un vacío de DNS DynamoDB opera **cientos de miles de registros DNS** por región para dirigir tráfico a un parque heterogéneo de **balanceadores** (y variantes como endpoint público, FIPS, IPv6, endpoints por cuenta, etc.). Esa complejidad se gobierna con dos módulos: - **DNS Planner**: calcula de forma periódica un **plan DNS** para cada endpoint (lista de balanceadores y pesos) según capacidad y salud. - **DNS Enactor**: aplica esos planes en **Amazon Route 53** mediante **transacciones atómicas**. Por resiliencia, existen **tres Enactors**, uno en cada **AZ**, actuando **en paralelo** y de forma **independiente**. El bug emerge cuando un **Enactor retrasado** intenta terminar de aplicar **un plan antiguo** al mismo tiempo que otro Enactor, que iba al día, **termina de aplicar un plan nuevo** y lanza su **limpieza de planes obsoletos**. La secuencia, improbable pero posible, fue esta: 1. El Enactor atrasado **machaca** en el endpoint regional el plan nuevo con **un plan viejo** (la comprobación “esto es más nuevo que lo anterior” quedó **obsoleta** por el retraso acumulado). 2. El Enactor que iba al día ejecuta la **limpieza** y **borra** el plan viejo por “demasiado antiguo”. 3. Resultado: el endpoint regional queda **sin direcciones** y el sistema, en un **estado inconsistente** que **bloquea** futuras correcciones automáticas. 4. Solución: **intervención manual** para **reponer** el estado correcto en Route 53 y **desbloquear** el ciclo. Desde ese momento, **todo lo que dependía de resolver DynamoDB** empezó a fallar. --- ## EC2: por qué no se podían lanzar instancias nuevas aunque “Dynamo ya volvía” Restaurado el DNS de DynamoDB, quedaba por delante recuperar el **plano de control** de EC2. Aquí entran dos piezas internas: - **DropletWorkflow Manager (DWFM)**: gestiona los servidores físicos (llamados *droplets*) que alojan instancias EC2 y mantiene un **“arrendamiento”** (*lease*) activo por cada droplet. - **Network Manager**: propaga el **estado de red** (rutas, reglas, adjuntos) a instancias y *appliances*. Durante la caída de DynamoDB, los **chequeos periódicos** de DWFM a sus droplets **fallaban** y los **leases** **fueron expirando** de forma gradual. Con DynamoDB de vuelta, DWFM intentó **re-tomar** millones de leases a la vez; la operación fue **tan voluminosa** que entró en **colapso congestivo** (colas que se reintentan y vuelven a expirar). La receta de recuperación fue clásica SRE: **estrangular entrada** (*throttling*) y **reinicios selectivos** de los hosts de DWFM para vaciar colas y **reducir latencias**. Con los leases restablecidos, **los lanzamientos empezaron a funcionar**. Quedaba el **Network Manager**: debía **propagar** el estado de red a todas las nuevas instancias y a las terminadas durante el evento. El **backlog** fue tal que la propagación **se retrasó**: instancias “recién nacidas” **arrancaban sin conectividad** hasta que su configuración llegaba. Ese desfase, a su vez, **confundió** al subsistema de **health checks de NLB**, que alternaba estados (**flapping**), sacando y metiendo capacidad en DNS de forma agresiva y provocando **errores de conexión**. Para cortar la sangría, AWS **deshabilitó temporalmente** el *failover* automático por health check de NLB, devolvió capacidad a servicio y, más tarde, **volvió a habilitarlo** cuando EC2 y la red se estabilizaron. --- ## Otros impactos relevantes - **Lambda**: fallos iniciales por el endpoint de DynamoDB (creación, *updates*, *triggers* SQS/Kinesis). Horas después, con EC2 aún degradado, AWS **priorizó invocaciones síncronas** y **limitó** *event source mappings* y asíncronas para evitar cascadas. - **STS e IAM**: errores de autenticación y latencias (dependencia indirecta de DynamoDB y, después, de NLB). - **Amazon Connect**: errores en llamadas, chats y paneles por combinación de problemas en NLB y Lambda. - **Redshift**: detenciones en consultas y operaciones de clúster; algunos clústeres quedaron **“modifying”** al no poder reemplazar hosts EC2 durante horas. Un defecto adicional afectó a consultas con **credenciales IAM** en **todas las regiones** durante un intervalo al depender de un API IAM en us-east-1 para resolver grupos: los clústeres con **usuarios locales** no se vieron afectados. --- ## Qué va a cambiar AWS El post-mortem anuncia medidas concretas: - **Automatización DNS de DynamoDB** (**Planner**/**Enactor**) **deshabilitada globalmente** hasta corregir el escenario de carrera e introducir **barreras adicionales** para impedir planes incorrectos. - **NLB**: **control de velocidad** para **limitar** cuánta capacidad puede retirar un único NLB cuando los *health checks* disparan un *failover* de AZ. - **EC2**: nueva **batería de pruebas** que ejercita el flujo de recuperación de **DWFM** a gran escala y mejoras de **throttling** en los sistemas de propagación de datos, ajustando el ritmo según **tamaño de cola** para proteger el servicio. --- ## Lecciones para arquitectos y SRE: diseñar para perder el “catálogo” 1. **No basta con multi-AZ; piense en multi-región (y multi-proveedor si procede).**Si su negocio no tolera horas de indisponibilidad, *active-active* o *pilot light* en otra región es la ruta. Para datos en DynamoDB, **Global Tables** ayuda… pero recuerde que el **tráfico contra el endpoint regional caído no conmutará solo**: la app debe saber **usar réplicas** cuando una región no responde (y aceptar **lag** temporal). 2. **Diferencie *data plane* y *control plane* en el diseño.**Su aplicación puede seguir dando servicio con el **plano de datos** estable aunque el **plano de control** (lanzar instancias, actualizar *configs*, emitir credenciales) esté degradado. ¿Tiene **capacidad caliente** o **pool de instancias** para aguantar sin *autoscaling*? ¿Es capaz de **degradar** funciones que requieren recursos nuevos? 3. **DNS: caché razonable, sin extremos.**Un **TTL sensato** amortigua fallos transitorios de resolución. Evite “TTL 0” por defecto, pero tampoco “hiper-largo”: cuando el proveedor arregle el endpoint, no quiere esperar horas para que caduquen cachés antiguas. En clientes críticos, evalúe resolver con **reintentos y *backoff*** y **no** fije IPs de servicios gestionados. 4. **Health checks con paciencia (evite el flapping).**Defina **umbrales y *grace periods*** para no retirar capacidad por chequeos transitorios cuando hay **propagaciones de red** en curso. Un *failover* agresivo multiplica el problema: saca nodos sanos cuyo *networking* aún no ha llegado y empeora la congestión. 5. **Circuit breakers y rutas de degradación funcional.**Si no puede escribir en DynamoDB, ¿puede pasar temporalmente a **lectura-solo**? Si no puede crear colas/instancias nuevas, ¿puede **acumular trabajo** en *buffers* locales o **pausar** componentes no críticos? 6. **Credenciales y sesión**.Evite **caducidades simultáneas** de tokens. Cuando **STS/IAM** sufran latencias, no querrá que todo su parque intente renovar a la vez. Escalone y **alargue márgenes** prudencialmente durante eventos. 7. **Runbooks y simulacros “us-east-1 cae”.**Documente **quién hace qué** y **en qué orden**: activar límites, desactivar partes del *pipeline*, conmutar DNS/Región, priorizar colas, etc. Ensaye los *playbooks*. --- ## ¿Es Virginia “el canario” de AWS? En foros técnicos se repite una idea: **us-east-1** es la región más grande, antigua y con más productos “rozando producción”; por tanto, **más expuesta** a incidentes complejos y a efectos sistémicos. Hay quien la considera el **“canario”** de AWS. Más allá del apodo, el mensaje práctico para las empresas es claro: **no concentre todas las dependencias críticas en esa región**, especialmente **control plane** y **puntos únicos de coordinación**. Diseñe pensando en que **una región puede quedar degradada** durante horas… o inaccesible por razones ajenas a su arquitectura. --- ## Qué comunicar ahora a negocio (y a sus clientes) - **Qué ocurrió** en su plataforma (fechas, servicios afectados, duración). - **Qué medidas** de contingencia aplicó y qué **riesgos residuales** quedan (reprocesos, *backlogs*, datos retrasados). - **Qué hará** a corto/medio plazo: *backlog* de cambios (multi-región, TTL DNS, *health checks*, *throttling*, capacidad pre-asignada) con **fechas** y responsables. - **Cómo medirán** mejoras: indicadores de continuidad, RTO/RPO y metas de resiliencia. --- ## Conclusión El incidente de us-east-1 no fue una “tormenta perfecta” de la nada: fue la manifestación de un **fallo de carrera** escondido en un sistema **crítico y automatizado** (la gestión de DNS para un servicio central) que, al activarse, **vació** un endpoint y **bloqueó** la autorreparación. A partir de ahí, el resto son **dependencias cruzadas** y **congestiones** propias de cualquier plataforma a hiperescala. La buena noticia es que el post-mortem trae **acciones concretas**; la menos buena, que **no hay magia**: la resiliencia de cada empresa **no la da** el proveedor por decreto, se **diseña**. Y ese diseño empieza por **aceptar** que una región —incluso la más famosa del mundo— puede fallar cuando menos conviene. --- ## Preguntas frecuentes **¿Cómo reducir el impacto de una caída regional de AWS en un e-commerce o medio digital?** Implemente **multi-AZ + multi-región** para el *frontend* y servicios críticos (cache/CDN, autenticación, catálogo). Use **DynamoDB Global Tables** o réplicas gestionadas donde proceda y asegure que la **aplicación conmute** a réplicas/regiones cuando un endpoint no responde. Mantenga **capacidad caliente** para servir sin *autoscaling*. **¿Por qué falló Network Load Balancer si “solo” estaba afectado DynamoDB?** Porque tras restaurar el DNS de DynamoDB, **EC2** tardó en **rearmar leases** y **propagar red** a instancias nuevas. NLB trajo nodos a servicio **antes** de que su conectividad estuviera lista; los *health checks* **fluctuaron** y la lógica de *failover* retiró capacidad sana. Ajuste **umbrales y *grace periods*** y evite *flapping* en despliegues masivos. **¿Debo bajar los TTL de DNS para responder más rápido a arreglos del proveedor?** Un **TTL moderado** ayuda a amortiguar cortes breves y permite que el **arreglo** se propague sin esperar horas. Evite extremos (TTL 0 o muy altos) y complemente con **reintentos** y **circuit breakers** en clientes. No fije **IPs** de servicios gestionados. **¿Tiene sentido evitar us-east-1?** Más que “evitar”, **diversifique**. Es una región clave por latencia hacia EE. UU. y por abanico de servicios, pero concentre lo **menos posible** sus “puntos de coordinación” (autenticación, colas, catálogos) **solo** allí. Diseñe para **degradación controlada** y **conmutación regional**. --- **Fuentes**: [Post-Event Summary](https://aws.amazon.com/es/message/101925/) de AWS sobre la interrupción de DynamoDB y los impactos en EC2, NLB y otros servicios en **N. Virginia (us-east-1)**, y documentación técnica de AWS relacionada con el incidente y las medidas anunciadas.