El gigante tecnológico Amazon revela que una condición de carrera en su sistema DNS desencadenó el extenso apagón de Amazon Web Services (AWS) que paralizó numerosas plataformas y servicios online a principios de esta semana.

El incidente técnico, iniciado el lunes en un centro de datos crítico ubicado en Virginia del Norte dentro de la región US-EAST-1, generó interrupciones de servicio durante más de 14 horas, con impactos notables en Estados Unidos y Europa.

En un análisis post-incidente detallado publicado el jueves, Amazon explicó que la causa raíz fue identificada como una condición de carrera latente en su infraestructura. Específicamente, el problema ocurrió dentro del sistema de gestión DNS de Amazon DynamoDB, responsable de dirigir las solicitudes de los usuarios a servidores operativos. Este mal funcionamiento resultó en la eliminación involuntaria de todas las direcciones IP del punto de acceso regional del servicio.

«Hemos determinado que la causa raíz fue una condición de carrera latente en el sistema de gestión DNS de DynamoDB», afirmó Amazon en su informe. «Esto resultó en un registro DNS vacío incorrecto para el punto de acceso del servicio regional (dynamodb.us-east-1.amazonaws.com), que nuestros sistemas de automatización no pudieron reparar».

El fallo técnico ocurrió a las 23:48 PDT, afectando inmediatamente a todos los sistemas que intentaban conectarse al servicio DynamoDB en la región de Virginia del Norte a través del punto de acceso público. El impacto fue integral, interrumpiendo tanto el tráfico de clientes externos como los servicios internos de AWS que dependen de la funcionalidad de DynamoDB.

Este fallo inicial de DNS desencadenó problemas en cascada a través de la infraestructura de AWS. El sistema DNS de DynamoDB quedó bloqueado en un estado inconsistente que los mecanismos de recuperación automatizados no pudieron resolver, requiriendo finalmente la intervención manual directa de operadores técnicos para restaurar los servicios.

La naturaleza integral del apagón destacó las interdependencias críticas dentro de la infraestructura en la nube. A medida que los servicios primarios fallaban, los sistemas secundarios dependientes de esos recursos también comenzaron a experimentar interrupciones, amplificando el impacto general. El incidente demostró cómo un único punto de fallo en un componente crucial del sistema puede escalar rápidamente y afectar a un amplio espectro de servicios online.

Tras el incidente, Amazon ha implementado varias medidas técnicas para prevenir ocurrencias similares en el futuro. Estas acciones incluyen la desactivación global del sistema de automatización DNS defectuoso y la mejora de las salvaguardas protectoras contra fallos similares. La compañía ha introducido mecanismos de limitación mejorados y ha desarrollado protocolos de prueba adicionales específicamente diseñados para detectar errores comparables antes de que afecten a entornos de producción.

El incidente subraya los complejos desafíos que enfrentan los principales proveedores de servicios en la nube para mantener la estabilidad del sistema mientras evolucionan continuamente su infraestructura. Aunque las plataformas en la nube están diseñadas con múltiples redundancias, este apagón demuestra cómo entornos técnicos sofisticados aún pueden experimentar interrupciones significativas debido a condiciones de software sutiles que se manifiestan solo bajo circunstancias específicas.

Para los usuarios de servicios AWS, particularmente aquellos con aplicaciones alojadas en la región US-EAST-1 afectada, el apagón sirvió como recordatorio de la importancia de estrategias de implementación multi-región y planificación robusta de recuperación ante desastres. Muchas organizaciones con arquitecturas diversificadas por región pudieron mantener operaciones parciales o completas mediante la conmutación a regiones AWS alternativas que no se vieron afectadas por el incidente.

A medida que la adopción de la nube continúa acelerándose en todas las industrias, los detalles técnicos de este apagón probablemente informarán las mejores prácticas tanto para proveedores de nube como para sus clientes. La comunicación transparente de Amazon sobre la causa y los esfuerzos de remediación refleja el creciente reconocimiento de la industria sobre la necesidad de análisis post-incidente detallados para construir sistemas más resilientes.

Los equipos de ingeniería de la compañía continúan implementando mejoras arquitectónicas destinadas a aislar posibles fallos y mejorar los mecanismos de recuperación para minimizar la duración y el alcance de cualquier interrupción futura del servicio.

Dentro de minutos del inicio del incidente a las 23:48 PDT, el tráfico destinado al servicio DynamoDB en la región US-EAST-1 no pudo ser enrutado, según el análisis post-mortem de Amazon. La interrupción se propagó rápidamente, rompiendo redundancias incorporadas y dejando a clientes de todo el mundo incapaces de acceder a servicios alojados en la región más utilizada del gigante de la nube.

AWS reveló la causa raíz en un informe detallado publicado el jueves, cuatro días después del fallo, indicando que «una condición de carrera latente» en el sistema de gestión DNS de DynamoDB borró todas las direcciones IP del punto de acceso público. Como resultado, las solicitudes de los usuarios devolvían registros DNS vacíos, un escenario que las herramientas automatizadas de auto-reparación de la compañía no pudieron detectar ni solucionar.

La amplitud del apagón subrayó cuán profundamente la vida moderna depende de un puñado de proveedores de nube. Plataformas «desde Netflix hasta Zoom» brevemente se oscurecieron, reportó The Guardian en su relato del episodio y la explicación de eventos por parte de Amazon link. Las startups nativas en la nube, grandes empresas e incluso servicios internos de AWS que dependen de DynamoDB sintieron los efectos dominó de la avería DNS, demostrando cuán rápidamente los problemas en un solo subsistema pueden cascadear a través de infraestructuras multiusuario.

A pesar de la arquitectura multi-región de AWS, US-EAST-1 está tan fuertemente integrada en las cargas de trabajo de los clientes que la pérdida de un solo servicio allí puede repercutir globalmente. Durante 14 horas, los desarrolladores se apresuraron a redirigir el tráfico o conmutar bases de datos a otras regiones; algunos tuvieron éxito, mientras que otros eligieron esperar que pasara el tiempo de inactividad cuando la capacidad alternativa no estaba disponible.

Amazon dice que la crisis comenzó cuando dos procesos concurrentes dentro del gestor DNS de DynamoDB ejecutaron un orden de operaciones que nunca antes se había superpuesto. En esa «condición de carrera», un proceso eliminó las direcciones IP del punto de acceso mientras que el otro todavía esperaba que existieran. La respuesta DNS vacía resultante se propagó rápidamente porque AWS utiliza un almacenamiento en caché agresivo para acelerar las búsquedas, dejando a los clientes atrapados en el estado fallido hasta que los ingenieros pudieron intervenir.

Para muchos clientes, el incidente sirvió como una prueba de estrés no deseada de la planificación de recuperación ante desastres. Las organizaciones que habían arquitecturado sus cargas de trabajo para conmutación multi-región a menudo pudieron trasladar el tráfico a Europa o la costa oeste de EE.UU. en cuestión de minutos. Otras descubrieron configuraciones de región codificadas o limitaciones de recursos que impedían una migración rápida, ilustrando el costo operacional de depender demasiado de una sola zona de disponibilidad de AWS.

Fuentes

  • https://www.theguardian.com/technology/2025/oct/24/amazon-reveals-cause-of-aws-outage
  • https://www.virtualizationhowto.com/community/cloud-forum/aws-outage-october-2025-explained-in-detail-as-to-why-things-went-down-due-to-dns/
  • https://ine.com/blog/aws-october-2025-outage-multi-region-and-cloud-lessons-learned

Tags