Resumen de la interrupción del servicio de Amazon DynamoDB ocurrida en la región del este de EE. UU. (Norte de Virginia, US-East-1)

 (aws.amazon.com)
3 puntos por GN⁺ 2025-10-24 | 2 comentarios | Compartir por WhatsApp
  • El 19 y 20 de octubre de 2025, en la región AWS N. Virginia (us-east-1), Amazon DynamoDB y varios servicios clave sufrieron una interrupción prolongada
  • La falla comenzó cuando se generó por error un registro DNS vacío e incorrecto debido a una condición de carrera (race condition) latente dentro del sistema automático de administración DNS de DynamoDB
  • Como resultado, se produjeron en cadena fallas en la creación de instancias EC2, errores de conexión en Network Load Balancer (NLB), y latencias y fallas de API en muchos servicios como Lambda, ECS y Redshift
  • AWS identificó la causa raíz como un conflicto de actualizaciones concurrentes anómalas entre los DynamoDB DNS Enactor, y realizó una recuperación manual hasta restablecer completamente el servicio alrededor de las 2:20 PM del 20 de octubre
  • Este incidente deja en evidencia la complejidad de las interdependencias entre los sistemas internos de automatización de AWS, y anticipa mejoras estructurales para reforzar la resiliencia de DNS, EC2 y NLB

Resumen del incidente

  • La interrupción comenzó el 19 de octubre de 2025 a las 11:48 PM (PDT) y terminó el 20 de octubre a las 2:20 PM (PDT)
    • Hubo tres periodos principales de impacto:
      1. 19 de octubre 11:48 PM ~ 20 de octubre 2:40 AM: fuerte aumento en la tasa de errores de la API de DynamoDB
      2. 20 de octubre 5:30 AM ~ 2:09 PM: aumento de errores de conexión en NLB
      3. 20 de octubre 2:25 AM ~ 10:36 AM: fallas en la creación de nuevas instancias EC2 y problemas de conectividad de red
  • La falla comenzó en un defecto del sistema de administración DNS de DynamoDB y se propagó a múltiples servicios como EC2, NLB, Lambda y Redshift

Causa e impacto de la falla de DynamoDB

  • Se activó un defecto latente en el sistema automático de administración DNS de DynamoDB, y el registro DNS de dynamodb.us-east-1.amazonaws.com se actualizó por error a un estado vacío
    • El sistema está dividido en dos componentes:
      • DNS Planner: monitorea el estado del balanceador de carga y genera nuevos planes DNS
      • DNS Enactor: aplica los cambios en Route53
  • Se produjo una condición de carrera (race condition) entre los DNS Enactor desplegados de forma independiente en tres zonas de disponibilidad (AZ)
    • El primer Enactor aplicó un plan antiguo mientras estaba retrasado
    • El segundo Enactor aplicó el plan más reciente y luego eliminó el plan antiguo, quitando todas las direcciones IP y llevando al sistema a un estado inconsistente
    • La recuperación automática falló, por lo que fue necesaria intervención manual (manual intervention)
  • Justo después de la falla a las 11:48 PM, todos los servicios y el tráfico de clientes que dependían de DynamoDB sufrieron fallas de conexión
    • Los clientes que usaban tablas globales pudieron enviar solicitudes a réplicas de otras regiones, pero hubo retraso de replicación (replication lag)
  • A las 12:38 AM, ingenieros de AWS confirmaron que el estado de DNS era la causa del problema
    • A la 1:15 AM, una medida temporal de recuperación restauró parte de la conectividad de servicios internos
    • A las 2:25 AM se restauró completamente la información DNS, y a las 2:40 AM toda la conectividad volvió a la normalidad

Impacto en Amazon EC2 y proceso de recuperación

  • Entre el 19 de octubre a las 11:48 PM y el 20 de octubre a la 1:50 PM se registraron aumentos en la tasa de errores de la API de EC2, fallas en la creación de instancias y mayor latencia
    • Las instancias ya en ejecución no se vieron afectadas
  • La administración de instancias EC2 utiliza dos subsistemas: DropletWorkflow Manager (DWFM) y Network Manager
    • DWFM administra el estado de los servidores físicos (“droplet”) y ejecuta verificaciones periódicas de estado
    • Network Manager propaga la configuración de red de las instancias
  • Debido a la falla de DynamoDB, las verificaciones de estado de DWFM fallaron y expiraron los leases de los droplet
    • Tras la recuperación de DynamoDB a las 2:25 AM, DWFM intentó reconectarse, pero por la gran cantidad de droplet se produjo un colapso por congestión (congestive collapse)
    • A las 4:14 AM, ingenieros reiniciaron selectivamente hosts de DWFM para vaciar las colas y avanzar con la recuperación
    • A las 5:28 AM se restauraron todos los leases de droplet y se reanudó la creación de nuevas instancias
  • Después, Network Manager procesó el backlog de propagación de estado de red, lo que provocó demoras en la conectividad de red
    • A las 10:36 AM los tiempos de propagación de red volvieron a la normalidad
    • A las 11:23 AM comenzó la relajación del throttling, y a la 1:50 PM EC2 se recuperó por completo

Impacto en Network Load Balancer (NLB)

  • Entre las 5:30 AM y las 2:09 PM del 20 de octubre, algunos clientes experimentaron un aumento de errores de conexión en NLB
    • NLB tiene una arquitectura multitenant y enruta tráfico a instancias EC2 backend
  • La causa fue la falla de health checks debido a retrasos en la propagación del estado de red
    • La configuración de red de las nuevas instancias EC2 agregadas no se completó, por lo que fallaron los health checks
    • Los resultados de health checks fluctuaban de forma inestable, haciendo que nodos de NLB fueran retirados del DNS y luego reincorporados
  • A las 6:52 AM, el sistema de monitoreo detectó el problema y los ingenieros iniciaron la respuesta
    • El aumento de carga en el subsistema de health checks activó un failover automático de DNS por AZ
    • A las 9:36 AM se desactivó el failover automático y regresaron todos los nodos sanos
    • A las 2:09 PM, tras la recuperación de EC2, se reactivó el failover automático

Impacto en otros servicios de AWS

  • AWS Lambda:
    • Entre el 19 de octubre a las 11:51 PM y el 20 de octubre a las 2:15 PM hubo errores y latencia en la API
    • La falla de DynamoDB provocó errores en la creación y actualización de funciones, y retrasos en el procesamiento de eventos de SQS/Kinesis
    • A las 7:04 AM, fallas de health checks en NLB redujeron la capacidad de sistemas internos y limitaron las invocaciones asíncronas
    • A las 2:15 PM se completó el procesamiento de todo el backlog y el servicio volvió a la normalidad
  • ECS, EKS, Fargate:
    • Entre el 19 de octubre a las 11:45 PM y el 20 de octubre a las 2:20 PM hubo fallas en la ejecución de contenedores y retrasos en el escalado de clústeres
  • Amazon Connect:
    • Entre el 19 de octubre a las 11:56 PM y el 20 de octubre a la 1:20 PM hubo errores en llamadas, chat y procesamiento de casos
    • Tras la recuperación de DynamoDB, la mayoría de las funciones volvió a la normalidad, pero después de las 7:04 AM reaparecieron errores por el impacto en NLB y Lambda
    • A la 1:20 PM se completó la recuperación total
  • AWS STS:
    • Entre el 19 de octubre a las 11:51 PM y el 20 de octubre a las 9:59 AM hubo errores y latencia en la API de autenticación
    • Tras la recuperación de DynamoDB hubo una normalización temporal, pero los problemas en NLB volvieron a causar errores
  • Inicio de sesión de IAM e Identity Center:
    • Entre el 19 de octubre a las 11:51 PM y el 20 de octubre a la 1:25 AM aumentaron las fallas de autenticación
    • Tras la recuperación de DynamoDB el servicio volvió a la normalidad
  • Amazon Redshift:
    • Entre el 19 de octubre a las 11:47 PM y el 20 de octubre a las 2:21 AM fallaron consultas y modificaciones de clústeres
    • Tras la recuperación de DynamoDB, algunos clústeres siguieron inestables por la falla en EC2
    • A las 4:05 AM del 21 de octubre se completó la recuperación total
    • Debido a una dependencia con la API de IAM, también hubo fallas temporales de consultas en regiones globales
  • Otros servicios:
    • También se vieron afectados Managed Workflows for Apache Airflow, Outposts y AWS Support Center, entre otros

Medidas posteriores y plan de mejoras

  • Desactivación total de la automatización de DynamoDB DNS Planner y Enactor; antes de reactivarla se corregirá la condición de carrera y se agregarán protecciones adicionales
  • NLB: se introducirá un mecanismo de control de velocidad para limitar la capacidad que un solo NLB puede retirar cuando fallen los health checks
  • EC2:
    • Se construirá una nueva suite de pruebas que incluya flujos de recuperación de DWFM
    • Se mejorará el throttling inteligente del sistema de propagación de datos para agregar limitación de solicitudes según el tamaño de la cola de espera
  • AWS está revisando adicionalmente formas de acortar el tiempo de recuperación y prevenir incidentes similares mediante un análisis general de interdependencias entre servicios

Conclusión y disculpa

  • AWS ofreció una disculpa oficial por el impacto de este incidente en sus clientes
  • Reconoció que, aunque ha mantenido una alta disponibilidad en sus servicios, esta interrupción tuvo un impacto significativo en los negocios de los clientes
  • AWS prometió tomar este incidente como lección para fortalecer la resiliencia de sus sistemas de automatización y sus procedimientos de respuesta ante fallas

Lecturas relacionadas

2 comentarios

 
shakespeares 2025-10-26

Dicen que es la secuela de haber despedido a los seniors... ¿es cierto?
 
GN⁺ 2025-10-24
Opiniones en Hacker News

  • Siempre digo lo mismo sobre este tema. Si todavía no has leído el texto de Richard Cook, te recomiendo detener este postmortem ahora mismo y leer primero How Complex Systems Fail. Es uno de los mejores textos técnicos sobre fallas en sistemas complejos. Cook rechaza la idea misma de una “causa raíz” (root cause), y creo que en este incidente tenía razón

    • El texto de Cook está bien, pero en la práctica se siente como una lista de afirmaciones intuitivas. Para entenderlo de verdad, probablemente haya que leer toda la bibliografía. En la materia de sistemas 6.033 del MIT también hacen leer un artículo de 1962 sobre temas parecidos y otro paper clásico. Creo que este tipo de problemas al final llega a un nivel de complejidad de “Wicked problem”
    • Lo que más me impresionó del texto de Cook fue la idea de que, después de un incidente, intentar corregir el sistema para hacerlo “más seguro” puede en realidad reducir su seguridad. La explicación de que las medidas para evitar errores humanos aumentan el acoplamiento y la complejidad del sistema, creando más puntos potenciales de falla y haciendo más difícil detectarlos y bloquearlos, me pareció especialmente certera
    • Otra perspectiva es la teoría de “Normal Accidents”. Sostiene que cuanto más fuertemente acoplados estén los componentes, más complejas sean sus interacciones y más graves sean las consecuencias de una falla, más riesgoso se vuelve el sistema por naturaleza. Ver Normal Accidents en Wikipedia
    • No he leído completos ninguno de los dos documentos, pero no estoy de acuerdo con la idea de que solo porque un sistema sea complejo no se pueda definir la causa raíz de una falla. En el deporte también se anota por una combinación de factores, pero al final sí existe un “anotador”. Tener una visión amplia está bien, pero identificar la causa principal también es práctico
    • Soy contratista y hago guardias de on-call. La mayoría de las empresas no se toma el on-call en serio. Falta documentación y tampoco te dan tiempo para leer código complejo escrito por otras personas. Me gustaría mucho vivir una cultura como la de AWS, donde el on-call se considera parte del aprendizaje y de la responsabilidad

  • Internet se está convirtiendo cada vez más en una red única centralizada (mononet). Nació en la Guerra Fría como una red distribuida, y ahora una sola mala implementación puede detener bancos, compras y viajes en todo el mundo. La metáfora de la nube ya pasó sus límites.
    Para startups o I+D sigue siendo útil, pero las empresas en etapa de crecimiento o los gobiernos deberían tener sus propios servidores, su propia nube y sus propios servicios críticos. Tecnología y personal hay de sobra

  • En el postmortem de AWS me impresionó la visualización precisa de la línea de tiempo. Igual que en la charla legendaria de la GDC “I Shot You First”, fue útil la forma de mostrar el paso del tiempo con flechas inclinadas y preguntar “¿dónde ocurrió la demora?”.
    Pero lo que más me sorprendió fue que el servicio de administración de leases de nodos de EC2 no tuviera un procedimiento de recuperación (runbook). Siendo un servicio central de AWS, yo habría esperado que casi cualquier caso excepcional ya estuviera previsto

    • Más que algo a lo que haya que temer, este tipo de situación debe entenderse como un patrón inherente de los sistemas complejos. Las fallas potenciales existen como fractales, y es imposible tener un runbook para todas las combinaciones posibles

  • El núcleo de este incidente parece una variación del problema de invalidación de caché (cache invalidation) en sistemas DNS. Dos DNS Enactor aplicaron el plan en momentos distintos y se produjo una condición de carrera, haciendo que un plan viejo sobrescribiera uno más nuevo

    • Esa es solo una explicación para el público; internamente, después de resolver el incidente, se hace una evaluación de posibilidad de recurrencia y se redactan mitigaciones (runbook). Después viene el aprendizaje y la difusión a nivel organizacional
    • Yo considero que esta condición de carrera en sí fue la causa raíz. Sin ese bug, el incidente no habría ocurrido
    • Me pregunto por qué separaron DNS Planner y Enactor. Si hubiera sido un solo servicio, esta condición de competencia habría quedado más clara. Puede ser el resultado de abusar de los microservicios y aumentar la complejidad
    • Me tocó vivir un problema parecido y la causa fue latencia del GC de la JVM y hardware defectuoso. También podría haber pasado algo así esta vez
    • Pero AWS no especificó qué medidas preventivas habrá si este tipo de demora vuelve a ocurrir

  • El Enactor debió haber hecho una comparación de versión del registro actual (CAS) antes de aplicar el nuevo valor. Aunque sea menos eficiente, es un mecanismo básico de seguridad. DynamoDB probablemente podía manejarlo por sí mismo

  • Me sorprendió leer que DynamoDB administra cientos de miles de registros DNS por región. Que dynamodb.us-east-1.amazonaws.com pueda resolverse a decenas de miles de IPs suena como algo que supera los límites de Route53. Probablemente usan TTL bajo y solo actualizan una parte

    • De hecho, así funciona el DNS de AWS. Route53 opera a nivel de conjunto de registros de recursos (RRSet) y devuelve el conjunto apropiado mediante health checks o lógica de selección basada en latencia
    • Los CDN funcionan de manera parecida. Recolectan métricas del sistema para calcular el PoP óptimo por red. Un buen ejemplo es bunny.net SmartEdge
    • Yo también hice pruebas con S3 y en pocos segundos obtuve cientos de IPs distintas. Incluso dentro de una sola región existe esa diversidad

  • Los bugs siempre existen. La verificación formal (formal verification) es difícil, y los bugs de baja probabilidad a veces explotan recién años después.
    Por eso hay que asumir que los sistemas van a fallar y diseñar estructuras que limiten el daño. La arquitectura basada en celdas, los despliegues graduales y las zonas aisladas son ejemplos de eso.
    AWS también intenta usar celdas, pero especialmente en us-east-1 todavía quedan dependencias cruzadas heredadas. A largo plazo, las regiones deberían diseñarse como completamente independientes.
    Este tipo de trabajo no avanza sin apoyo de altos ejecutivos, pero desde la perspectiva de los accionistas es una inversión clave para reducir el riesgo de continuidad de la empresa

  • Me llamó la atención que en el informe usaran la zona horaria PT y no UTC

    • Hasta da para el chiste de “¿epoch fail?”, pero como la mayoría de los clientes están en EE. UU., quizá PT resulte más intuitiva
    • Tal vez también buscaban destacar la dificultad de responder de noche

  • Me sorprendió que no hubiera patrones como versionado por endpoint o 2PC, single writer lease. Aun así, valoro mucho que AWS lo haya publicado con tanta transparencia

    • En la práctica, la API de cambios DNS sí hace CAS, pero varios escritores asíncronos compitieron sin un orden lógico. Deberían haber serializado el orden usando un zone serial o un sentinel record

  • Creo que la causa directa de este incidente fue una condición de carrera latente en el sistema de gestión DNS de DynamoDB. Un plan viejo sobrescribió al más reciente y dejó vacíos los registros DNS del endpoint regional

    • Pero hay que tener cuidado con el concepto de “causa raíz”. Esto fue un colapso metaestable (metastable collapse), y el problema central fue la ausencia de un procedimiento de recuperación (runbook)
      Referencia: How Complex Systems Fail