On 20 de octubre de 2025Amazon Web Services (AWS), el mayor proveedor de servicios en la nube del mundo, sufrió un interrupción importante en su región US-EAST-1 (norte de Virginia) que interrumpió los servicios a nivel mundial durante casi 24 horas. El evento subrayó la dependencia crítica de la infraestructura moderna de Internet de un único proveedor de nube y reavivó las discusiones sobre resiliencia, redundancia y estrategias multi-nube.
Resumen del incidente
Evento: Aumento de las tasas de error y las latencias
Provincia: EE. UU.-ESTE-1 (Norte de Virginia)
Duración: 19 de octubre, 11:49 – 20 de octubre, 3:01 (PDT)
Gravedad: Interrumpido
Causa raíz principal: Error de resolución DNS en el punto de conexión de DynamoDB
Servicios afectados: Más de 140 servicios de AWS, incluidos EC2, Lambda, S3, DynamoDB, CloudWatch, Redshift y más.
Cronología y análisis de la causa raíz
El apagón comenzó tarde 19 de octubre de 2025, cuando los ingenieros detectaron un aumento en las tasas de error en varios servicios de AWS. Las investigaciones iniciales apuntaban a Amazon DynamoDB, un servicio de base de datos central que impulsa numerosas aplicaciones internas y de clientes. Por 12: 26 AM PDTAWS identificó que el problema se debía a una Actualización DNS defectuosa lo cual interrumpió la resolución de los puntos finales, rompiendo efectivamente la “agenda telefónica” que dirige los servicios a sus destinos.
El fallo del DNS desencadenó una cascada de errores del sistema dependientes:
- Lanzamiento de instancias EC2 Se ha detenido debido a dependencias de DynamoDB.
- Comprobaciones del estado del balanceador de carga de red Falló, provocando la pérdida de conectividad en servicios como Lambda, SQS y CloudWatch.
- Actualizaciones de IAM y Tablas globales de DynamoDB También sufrió retrasos debido a su dependencia de la región afectada.
Los ingenieros de AWS aplicaron medidas de mitigación en paralelo: vaciaron las cachés DNS, limitaron el lanzamiento de instancias EC2 y restauraron gradualmente la conectividad de red. 2: 24 AM PDTEl problema principal de DNS se resolvió, pero los problemas de red y del subsistema EC2 persistieron durante la mañana. subsistema de estado del balanceador de carga de red se recuperó completamente por 9: 38 AM PDT, con la normalización final del servicio en 3:01 p.m. PDT.
Alcance del impacto
El impacto fue extenso, afectando tanto a servicios empresariales como a plataformas de consumo populares en todo el mundo. Más de 140 servicios de AWS se vieron afectados, entre otros:
- Computación y redes: EC2, ECS, EKS, Balanceo de carga elástico
- Datos y almacenamiento: DynamoDB, S3, RDS, Redshift, ElastiCache
- Sin servidor: Lambda, EventBridge, SQS, Step Functions
- Seguridad y gestión: IAM, AWS Organizations, CloudTrail, Configuración
- Herramientas de desarrollo: CodeBuild, Amplify, AppSync, CloudFormation
La interrupción tuvo un alcance que trascendió a los clientes de AWS. Plataformas globales como Snapchat, Fortnite, Roblox, Coinbase, Venmo, e incluso Los servicios Prime Video y Ring de Amazon. Experimentaron interrupciones. Instituciones financieras como Lloyds y Halifax reportaron problemas de inicio de sesión, y los portales gubernamentales quedaron temporalmente fuera de servicio. Con AWS manteniendo aproximadamente 33% de la cuota de mercado global de infraestructura en la nubeEl efecto dominó del evento no tuvo precedentes.
Lecciones sobre la dependencia de la nube
Este incidente demuestra un desafío clave en la arquitectura moderna de la nube: dependencia de una sola regiónA pesar del diseño de múltiples zonas de disponibilidad de AWS, muchos sistemas globales siguen anclados regionalmente, particularmente a EE. UU.-ESTE-1, que alberga numerosos puntos de conexión de plano de control y API globales.
Aunque no se trató de un ciberataque, el suceso reveló cómo un error de configuración interna en un único servicio fundamental (DNS en este caso) puede propagarse a través de sistemas dependientes, paralizando las operaciones globales.
RELIANOIDPerspectiva de: Lograr una alta disponibilidad real con GSLB
At RELIANOIDCreemos que la resiliencia en entornos de nube debe ir más allá de la redundancia dentro de un único proveedor. Equilibrio de carga global del servidor (GSLB) La solución garantiza la disponibilidad continua incluso cuando un proveedor de nube importante o una región experimenta una interrupción.
Cómo RELIANOID GSLB ayuda a prevenir este tipo de interrupciones.
- Continuidad multi-nube y multi-región: GSLB distribuye de forma inteligente el tráfico entre regiones o proveedores independientes (por ejemplo, AWS, Azure, GCP, local), garantizando la continuidad del servicio durante fallos regionales o a nivel de proveedor.
- Monitoreo de salud en tiempo real: Las comprobaciones continuas de los puntos de conexión permiten el redireccionamiento automático del tráfico a nodos en buen estado, minimizando el tiempo de inactividad durante eventos como fallos de DNS o de puntos de conexión de API.
- Balanceo de carga DNS inteligente: RELIANOIDEl GSLB basado en DNS de [Nombre de la empresa] resuelve dinámicamente las solicitudes de los clientes a los centros de datos óptimos, mitigando los riesgos relacionados con la mala configuración del DNS o los retrasos en la propagación.
- Conmutación por error y recuperación sin interrupciones: Con políticas como el round robin ponderado, el enrutamiento basado en la latencia y la geolocalización, GSLB mantiene la consistencia del servicio y minimiza las interrupciones incluso en implementaciones complejas en múltiples regiones.
Implementar GSLB como parte de una estrategia integral de alta disponibilidad permite desacoplar las aplicaciones críticas para el negocio de las dependencias operativas de un único proveedor. Ya sea que un problema se origine en la resolución DNS, las comprobaciones del estado de la red o las fallas de la API interna, GSLB proporciona un mecanismo transparente para la conmutación por error automática y una experiencia de usuario continua.
Conclusión
Los Interrupción del servidor AWS US-EAST-1 en octubre de 2025 Esto nos recuerda de forma contundente que incluso las infraestructuras en la nube más avanzadas pueden fallar. La verdadera resiliencia requiere independencia arquitectónica, mecanismos de conmutación por error proactivos y un equilibrio de carga global inteligente.
RELIANOIDGSLB proporciona esta resiliencia, ayudando a las organizaciones a garantizar el tiempo de actividad, la fiabilidad y la confianza, independientemente de dónde se origine la próxima interrupción.
Obtenga más información sobre GSLB y las estrategias de alta disponibilidad..
Blogs relacionados
