La caída de la mayor plataforma de infraestructuras en la nube del mundo ha provocado un blackout en muchas webs, aplicaciones y redes sociales que no cuentan con planes de contingencia. No tener un plan b puede producir una parálisis completa cuando suceden estos imprevistos y, lo que es aún más inquietante, invisibilidad, lo que puede multiplicar los riesgos de intrusiones en sus sistemas.
Cómo una caída de AWS paraliza gran parte de Internet
Se paró el motor. La mañana del lunes 20 de octubre de 2025 muchas webs, aplicaciones y redes sociales se han ido a negro debido a una caída a nivel global de Amazon Web Services (AWS), la mayor plataforma de infraestructuras en la nube del mundo. En Estados Unidos ha sido imposible acceder a Amazon, Amazon Alexa, PrimeVideo, Crunchyroll, Canva, Perplexity y Duolingo, a redes sociales como Snapchat o Goodreads y a videojuegos como Fortnite, Roblox o Clash Royale; y en Europa algunos servicios también han presentado los mismos fallos de accesibilidad.
Por qué el fallo de AWS afecta a servicios y aplicaciones
“Esto pasa, porque muchas piezas invisibles de internet viven en AWS”, explica Hervé Lambert, Global Consumer Operation Manager de Panda Security, “por eso”, continua, “cuando esta plataforma cae no se apaga sólo un servidor, sino que fallan servicios básicos de los que dependen webs, apps y redes sociales, propios o de terceros”. Hablando en plata, “dejan de funcionar porque comparten la misma infraestructura y servicios base, como el cómputo, el almacenamiento, DNS, autenticación y CDN en AWS o en terceros que dependen de AWS, y, si esas capas fallan y no hay arquitectura multiregión ni planes de contingencia, toda la experiencia de cargar, entrar, pagar o publicar, se cae en cascada”.
Cuando ocurre una caída de este calibre, “hay apps que no cuentan con cómputo para servir páginas, APIs o feeds, porque corren en EC2/EKS/Lambda y puede producirse un fallo en los nodos o el control plane; no hay dónde leer ni guardar los datos y, por tanto, la web o la app no puede cargar contenido ni autenticar; se rompe el login, porque autenticaciones con Cognito, STS/AssumeRole o SSO alojado en AWS dejan de emitir tokens; el tráfico no sabe dónde ir, porque si el DNS no resuelve o el CDN no puede tirar del origen los dominios no responden o lo hacen a trompicones; y, aunque una app no esté alojada en AWS, si sus proveedores sí lo están también sufre fallos, porque la cadena funciona como un castillo de naipes”, señala Lambert.
Riesgos de centralizar la infraestructura y cómo evitarlos
Pero, además, cuando cae o se degrada AWS “hay empresas que pueden quedarse a ciegas, porque su observabilidad depende de esta plataforma”, avisa el directivo de Panda Security. Esto pasa, por ejemplo, “si tienen en la misma nube, o en la misma región, cosas como CloudWatch, CloudTrail, GuardDuty, SIEM, dashboards, alertas por SNS/SES o su SSO”, enumera Lambert, quien, además, señala que “si esas piezas fallan o se retrasan, las webs pueden quedarse sin métricas, sin logs, y sin quién pueda entrar con credenciales válidas y, por tanto, expuestas”. Algo que es evitable, “si la monitorización, logs e identidad tienen salida de emergencia fuera de la misma zona de fallo”.
Pero, muchas compañías concentran todo en una región y en una cuenta, “incluidos backups y llaves KMS”, apostilla el experto de Panda Security, “y sin multi-region failover la indisponibilidad es total”. Además, “bajo presión, hay equipos que abren security groups, quitan AWF o amplían permisos IAM para que la cosa funcione, rompiendo, en ocasiones, mucho más o dejando a la app vulnerable”, advierte Lambert.
La importancia de contar con un ‘Plan B’
¿Y por qué no hay planes de contingencia si los riesgos de caída son tan importantes? “Porque no se incentiva, parece caro y da pereza técnica”, resume en tres razones básicas el experto de Panda Security. “Por ser breve, muchas webs, aplicaciones y redes sociales carecen de un Plan B, porque sus prioridades están mal alineadas y el negocio premia la inmediatez y muchas salen al mercado rápido y no se diseña para lo peor, además, existe la falsa sensación de seguridad y se cree que esas cosas no les van a pasar”, cuenta Lambert. “Además, la multiregión y la multicuenta, los datos replicados, identidades redundantes, runbooks y ensayos suenan a doblar costes, y se asume que AWS no se cae o que el SLA pagará el daño, cuando no es así”.
En este sentido entra en juego el papel del, todavía poco implantado security by design. “A estas alturas del partido, muchas organizaciones siguen sin integrar la ciberseguridad desde las fases más tempranas del desarrollo de sus productos, servicios o infraestructuras. No estamos diciendo que las empresas que están caídas hoy lo hayan hecho mal, pero es muy habitual que, en lugar de construir sistemas resilientes desde el origen, muchas organizaciones recurren aún con demasiada frecuencia a medidas reactivas, añadidas en fases finales del ciclo de vida.
En este sentido, hay que destacar que este enfoque de la seguridad reactiva además de ser mucho menos eficaz, a la larga es mucho más caro y difícil de mantener a largo plazo.
Para romper ese círculo se necesita “resiliencia en los KPIs, separar cuentas o regiones, automatizar copias y guardrails y ensayos”, indica Lambert, “porque esto siempre será menos costoso que explicar a miles de usuarios por qué tu servicio ha desaparecido”.