Amazon ha publicado el análisis detallado de un incidente que paralizó sus servicios en la nube y arrastró a grandes webs y servicios a la oscuridad por horas. El problema comenzó a las 23:48 PDT del 19 de octubre (7:48 UTC del 20 de octubre), cuando usuarios empezaron a reportar errores en la API de DynamoDB, el servicio de base de datos NoSQL de AWS, en la región US-EAST-1 de Virginia.
La raíz del caos fue una inesperada “condition race” en el sistema de gestión automatizada de DNS de DynamoDB. Este sistema consta de dos partes independientes para garantizar alta disponibilidad: un DNS Planner, que supervisa el estado de los balanceadores de carga y genera planes de DNS, y un DNS Enactor, que aplica los cambios a través de Amazon Route 53. Según el postmortem oficial de Amazon, la causa principal fue un “defecto latente” en esta automatización.
El desastre se desencadenó cuando un DNS Enactor experimentó retrasos inusualmente altos mientras el DNS Planner seguía generando nuevos planes. Un segundo DNS Enactor comenzó a aplicar los planes más recientes y ejecutó un proceso de limpieza justo cuando el primer Enactor finalizaba su tarea retrasada. Esta limpieza eliminó como “obsoletos” todos los planes antiguos, borrando instantáneamente todos los registros DNS del endpoint regional de DynamoDB y dejando el sistema en un estado inconsistente que impidió la aplicación de nuevas actualizaciones automatizadas.
El impacto fue inmediato y masivo. Tanto el tráfico de clientes como los servicios internos de AWS quedaron incomunicados. El DropletWorkflow Manager (DWFM), responsable de gestionar las instancias EC2, depende de DynamoDB para mantener el estado de los servidores físicos. Al fallar DNS, DWFM no pudo verificar ni asignar nuevos leases, lo que impidió lanzar o modificar instancias EC2. Cuando DynamoDB se recuperó, a las 2:25 PDT, el DWFM intentó reestablecer leases en toda la flota EC2, pero la escala fue tal que el proceso colapsó, requiriendo intervención manual hasta las 5:28 PDT.
El efecto dominó continuó: el Network Manager, encargado de propagar configuraciones de red, se vio desbordado por la acumulación de tareas retrasadas, lo que provocó demoras en la configuración de red de nuevas instancias EC2. Esto, a su vez, afectó al Network Load Balancer (NLB), cuyo subsistema de health checks eliminaba y restauraba instancias EC2 continuamente debido a los retrasos.
Servicios como Lambda, Elastic Container Service (ECS), Elastic Kubernetes Service (EKS) y Fargate —todos dependientes de EC2— también experimentaron interrupciones. La caída se extendió durante horas y afectó a grandes portales, servicios de gobierno y, según estimaciones, pudo causar daños económicos por cientos de miles de millones de dólares.
AWS ha desactivado temporalmente la automatización del DNS Planner y DNS Enactor en todo el mundo hasta que se implementen nuevas salvaguardas para evitar una repetición del incidente. En sus disculpas, Amazon aseguró que seguirá analizando el evento y buscará formas de reducir el impacto y el tiempo de recuperación en el futuro.
Este episodio subraya la fragilidad de la infraestructura crítica global ante fallos aparentemente menores en sistemas automatizados, y la dependencia de la economía digital en un puñado de proveedores de nube. La lección: ni siquiera los gigantes de la nube son inmunes a un simple error de sincronización.
, cuando usuarios empezaron a reportar errores en la API de DynamoDB, el servicio de base de datos NoSQL de AWS, en la región US-EAST-1 de Virginia.){kind=link}