El lunes 20 de octubre de 2025 pasará a la historia como un día de sobresalto para la infraestructura de Internet global. Una interrupción de escala masiva en AWS provocó fallos generalizados en servicios, apps, bancos y gobiernos de todo el mundo. En este artículo para el blog de Kernel Reload analizamos qué ocurrió, por qué, qué se vio afectado, cuáles fueron las repercusiones y qué lecciones podemos extraer.
¿Qué sucedió?
-
A partir de alrededor de las 03:11 h (ET) / las primeras horas del lunes en EE.UU. (≈ 08:11 h BST) comenzaron a registrarse incrementos abruptos en los informes de fallos por parte de usuarios de múltiples apps y servicios, según rastreadores de incidencias.
-
AWS confirmó que estaba investigando “increased error rates and latencies” en diversos servicios dentro de la región US‐EAST‐1 (Virginia del Norte, EE.UU.).
Poco después, AWS detalló que “significant error rates for requests made to the DynamoDB endpoint in the US-EAST-1 Region” habían sido detectados.
-
Hacia la tarde/noche (UTC) la compañía informó que el “problema subyacente” había sido mitigado y que los servicios volvían a operar con normalidad.
-
No obstante, algunas operaciones siguieron experimentando efectos residuales por horas adicionales.
Origen y causas técnicas
Región crítica: US-EAST-1
La región US-EAST-1 (Virginia del Norte) es uno de los hubs más importantes de AWS —alojando una gran parte de la infraestructura que sustenta servicios globales— y fue el epicentro de este incidente.
Causa principal
-
AWS identificó que el fallo estaba ligado al servicio Amazon DynamoDB (una base de datos como servicio de AWS) en la región US-EAST-1, donde los endpoints de la API estaban experimentando fallos de resolución de DNS (Sistema de Nombres de Dominio).
-
En palabras simples: el “libro de teléfonos” de Internet (DNS) encargado de traducir nombres de servicios a direcciones de máquinas estaba fallando en esos endpoints clave, lo que bloqueó peticiones y generó latencias y errores elevados.
-
Además, AWS indicó que el origen del problema se encontraba “within the EC2 internal network”, refiriéndose a su servicio de instancias de cómputo alojadas en esa región.
Por qué la propagación fue tan amplia
-
Muchos servicios, apps y empresas dependen de AWS, directa o indirectamente. Cuando uno de sus centros críticos sufre un fallo, el efecto dominó es amplio.
-
La concentración de servicios en una región de AWS (o en uno de sus grandes proveedores) implica que, cuando ese nodo cede, los efectos se sienten a escala global.
Servicios y plataformas afectados
La lista de afectados es extensa. Aquí los principales tipos de servicios impactados:
Apps de consumo y juegos
-
Servicios como Snapchat, Fortnite, Duolingo, Canva sufrieron interrupciones o fallos significativos.
-
Plataformas de streaming / entretenimiento como Ring (cámaras inteligentes), servicios del ecosistema Amazon, etc., también experimentaron problemas.
Negocios, bancos y servicios gubernamentales
-
En Reino Unido, entidades como Lloyds Banking Group, HM Revenue & Customs (HMRC) vieron sus plataformas afectadas.
-
También servicios de empresas tecnológicas, financieras e infraestructuras críticas que utilizan AWS como parte de su backend sufrieron interrupciones.
Escala del impacto
-
Se registraron millones de usuarios afectados: por ejemplo, rastreadores como Downdetector mostraron picos de más de 6,5 millones de reportes de problemas a nivel global.
-
Más de 1.000 empresas pueden haber sido afectadas directa o indirectamente en este episodio.
Repercusiones
Inmediatas
-
Usuarios finales: apps que no respondían, servicios que se caían, imposibilidad de acceder a plataformas, autenticaciones fallidas.
-
Empresas: interrupciones en operaciones, pérdidas temporales de funcionalidad, posibles ingresos perdidos o percepción de inestabilidad.
-
Imagen pública de AWS: aunque la empresa es líder, este tipo de fallos vuelven a poner en evidencia los riesgos de la concentración.
A medio/largo plazo
-
Cuestiones de resiliencia en la nube: este suceso reforzará los debates sobre cómo distribuir cargas, redundar proveedores y minimizar puntos únicos de fallo.
-
Regulación e infraestructura crítica: se cuestionará si proveedores de nube deben considerarse “infraestructura crítica” y someterse a regulaciones más estrictas.
-
Costes ocultos: aunque AWS ofrece créditos de servicio según sus SLA, muchas empresas sufren pérdidas que van más allá de esos créditos —por ejemplo reputacionales o de negocio—.
-
La “economía de la nube” y el ecosistema digital quedan expuestos: cuando un gran proveedor falla, todo el ecosistema se tambalea.
Lecciones clave para entornos TI
-
No depender exclusivamente de una sola región o proveedor de nube para servicios críticos. Aunque AWS es robusto, como se ha visto, no es infalible.
-
Diseñar arquitecturas con redundancia geográfica y multi-proveedor cuando sea factible.
-
Tener procedimientos de contingencia ante fallos de proveedor: verificación de fail-over, monitoreo externo, planes de comunicación.
-
Considerar que los SLA estándar pueden no cubrir todos los tipos de pérdidas (ej., de reputación, de negocio) —las empresas deben evaluar sus propios riesgos más allá del crédito de servicio.
-
Reconocer que los fallos en la nube tienen efectos “en cascada”: un incidente de infraestructura puede traducirse en una crisis digital.
Conclusión
La caída del 20 de octubre de 2025 de AWS es un recordatorio contundente de que buena parte de nuestra vida digital depende de una infraestructura que, aunque gigante, es vulnerable. La escala del impacto —desde apps de ocio hasta bancos y servicios públicos— subraya que en la era de la nube, los problemas de uno pueden convertirse en problemas de todos.
Para Kernel Reload, este suceso no solo es una noticia tecnológica relevante, sino un caso de estudio sobre cómo diseñar sistemas más robustos, cómo pensar la arquitectura de servicios y cómo prepararse para lo inesperado en un mundo que gira cada vez más en torno a la nube.

0 Comentarios