La caída global de Amazon Web Services (AWS) dejó fuera de juego, en la mañana del lunes 20 de octubre, a servicios tan dispares como Bizum, Ticketmaster, Canva, Alexa o videojuegos online. El epicentro estuvo en US-EAST-1 (N. Virginia): un problema de resolución de DynamoDB derivó en errores en cadena que afectaron a EC2, Lambda, Load Balancers y decenas de servicios aguas arriba. Aunque todo quedó restaurado horas después, el incidente volvió a evidenciar dos cosas: concentramos demasiado riesgo en una única región de un único proveedor y Europa carece de un plan B propio cuando falla un hiperescalador.
Para entender qué ha pasado y qué se puede hacer, pedimos una lectura a David Carrero, cofundador de Stackscale – Grupo Aire (infraestructura cloud y bare-metal española).
Qué pasó (y por qué “nos cae Internet” desde Virginia)
- Origen: errores de DNS hacia DynamoDB en US-EAST-1; al degradarse este pilar, fallaron lanzamientos de instancias, comprobaciones de salud de balanceadores y las invocaciones en Lambda.
- Efecto dominó: muchos planos de control y servicios globales dependen de endpoints de esa región, de ahí que Europa viera logins fallidos, cargas parciales, picos de latencia y colas acumuladas incluso sin tener cargas en N. Virginia.
- Por qué España lo notó: gran parte del SaaS que usamos aquí (pagos, entradas, diseño, asistentes, juegos) vive sobre AWS o depende de servicios globales que tiran de US-EAST-1.
La lectura de los expertos: HA no es plan B
David Carrero (Stackscale): “Muchas empresas en España y Europa confían toda su infraestructura a proveedores americanos como AWS y, además, no cuentan con un plan B ni cuando sus servicios son realmente críticos. Está muy bien tener alta disponibilidad (HA), pero si todo depende de algún elemento común, el HA fallará.”
“Seguimos sin practicas multirregión reales: planos de control monorregión, datos centralizados en US-EAST-1 y pruebas de failover que no se ensayan. El resultado es siempre el mismo: cuando hay un tropiezo grande, paramos todos.”
“En Europa hay muchas opciones ganadoras que se menosprecian por la presión de ‘estar con los grandes’ hiperescalares. No solo Stackscale puede ser alternativa o complemento; el ecosistema europeo y español es amplio y profesional, sin nada que envidiar para la gran mayoría de necesidades.”
Qué podemos hacer hoy (y qué deberíamos tener listo mañana)
Para usuarios
- Revisa las páginas de estado de las apps que usas.
- Evita reinstalar o borrar datos si el problema es del proveedor.
- Reintenta más tarde: en estos incidentes la recuperación suele ser gradual.
Para equipos de TI
Ahora mismo
- No toques configuración crítica salvo que tengas una ruta de mitigación clara (conmutar a otra región ya preparada).
- Comunica: estado, alcance, pasos temporales y próximos avisos.
- Registra métricas y errores para el post-mortem (qué falló, dónde y cuánto tiempo).
Para el siguiente lunes a las 9:00
- Multirregión de verdad
- Planos de control y datos desacoplados de US-EAST-1 (u otra región única).
- Replicación y cut-over probados; gamedays trimestrales.
- RTO/RPO por servicio
- Define objetivos realistas: qué puede estar X minutos caído y qué no; qué datos puedes perder (si es que puedes).
- Alinea arquitectura y presupuesto con esos objetivos.
- Dependencias globales
- Si usas servicios “globales”, verifica dónde anclan (IAM, colas, catálogos) y ofrece rutas alternativas.
- Evita “todo a Virginia” por inercia (coste, catálogo o histórico).
- Backups y restauración
- Copias inmutables y desconectadas; prueba de restauración cronometrada.
- Runbooks operativos, no PDFs olvidados.
- DNS/CDN con conmutación
- Políticas de failover en DNS/GTM y orígenes alternativos en CDN; salud basada en servicio, no solo en pings.
- Multicloud donde tenga sentido
- Para servicios críticos o por soberanía, valora doble proveedor.
- Mantén controles portables (identidad, logging, backups) para no multiplicar la complejidad.
¿Y Europa? Alternativas que ya existen
Carrero: “No se trata de ‘abandonar’ a los hiperescalares, sino de reducir concentración de riesgo y ganar resiliencia. En Europa hay proveedores de primer nivel para cloud privada, bare-metal, housing, conectividad, backup y servicios gestionados que complementan a los grandes. En la mayoría de casos, no necesitas un superclúster de IA para servir a tus clientes: necesitas continuidad.”
Ideas prácticas:
- Datos y aplicaciones críticas en infraestructura europea (privada o soberana), con enlaces dedicados hacia el SaaS/hiperescala donde sea necesario.
- Capas de continuidad (backup, DR, DNS, observabilidad) fuera del mismo dominio de fallo.
- Partners locales para 24/7 y soporte de proximidad; es más fácil corregir rápido cuando el equipo está cerca.
Lecciones de este incidente
- US-EAST-1 no puede ser un “todo en uno”: cómodo y barato, sí; riesgo sistémico, también.
- Multi-AZ no siempre basta: cuando cae un componente transversal, te arrastra igual.
- El plan B se ensaya: si no practicas el failover, no tienes failover.
- Transparencia: partes y comunicación temprana reducen incertidumbre y soporte.
Carrero (cierre): “La resiliencia no es un eslogan, es ingeniería y disciplina. Si la empresa vive de su plataforma, debe poder seguir aun cuando falle su proveedor principal. HA no es plan B; el plan B es otra vía completa para llegar al mismo resultado.”
En dos líneas: la caída de AWS no es una rareza, es un riesgo operativo que ya conocemos. España y Europa necesitan redundar regiones, diversificar proveedores y activar la industria local como complemento. La diferencia entre un susto y una crisis la marcará, otra vez, el plan B.
