La interrupción global de Amazon Web Services (AWS) del lunes 20 de octubre volvió a recordarnos lo frágil que puede ser el tejido digital cuando demasiadas piezas dependen de un mismo punto. En España, servicios tan dispares como Bizum, Ticketmaster, Canva, Alexa o varios videojuegos online sufrieron errores o quedaron inaccesibles durante horas. El epicentro estuvo en US-EAST-1 (N. Virginia): un problema de DNS hacia DynamoDB degeneró en fallos de EC2, Lambda y balanceadores, con un efecto dominó sobre decenas de servicios.
Más allá del incidente puntual, la fotografía deja un mensaje incómodo: seguimos concentrando riesgos en la misma región del mismo hiperescalador, y Europa carece de opciones planificadas cuando el gigante tropieza. “Muchas empresas en España y Europa confían toda su infraestructura a proveedores americanos y, además, no cuentan con un plan B ni cuando sus servicios son críticos”, resume David Carrero, cofundador de Stackscale (Grupo Aire). “Está muy bien tener alta disponibilidad (HA), pero si todo depende de algún elemento común, el HA fallará”.
Qué pasó (y por qué lo notamos desde aquí)
- Desencadenante: fallos de resolución DNS para DynamoDB en US-EAST-1.
- Cascada: errores al lanzar instancias EC2, problemas en Network Load Balancer y invocaciones Lambda, más colas y throttling en servicios dependientes.
- Efecto en Europa: aunque muchas cargas estén en regiones europeas, planos de control globales y dependencias internas (identidad, colas, orquestación) ancoran en N. Virginia, de ahí los logins fallidos, páginas 5xx y latencias en España.
“Lo vemos una y otra vez porque la arquitectura no es realmente multirregión”, añade Carrero. “Planos de control en una sola región, datos centralizados por comodidad y failovers que no se ensayan. Cuando hay un tropiezo grande, paramos todos”.
Lecciones técnicas que deja el incidente
- US-EAST-1 no puede ser un ‘todo en uno’: es cómoda y barata, pero concentra riesgo sistémico.
- Multi-AZ no equivale a resiliencia: si falla un componente transversal (DNS de un servicio core), todas las zonas sufren.
- El plan B se prueba: un runbook sin gamedays periódicos es papel mojado.
- Observabilidad y DNS importan: si tu monitorización y control de identidad también dependen de la región afectada, te quedas ciego justo cuando necesitas ver.
- Comunicación: partes claros y frecuentes reducen incertidumbre y coste de soporte.
¿Qué debería cambiar en las arquitecturas cloud-first?
1) Multirregión de verdad
Separar planos de control/datos y probar conmutaciones. “No todo necesita activo-activo, pero lo crítico sí”, apunta Carrero. “Define qué servicio no puede caer y diseña para ese RTO/RPO, no al revés”.
2) DNS/CDN con conmutación
Políticas de failover en DNS/GTM basadas en salud de servicio, y orígenes alternativos en CDN. Evitar anclas implícitas a una sola región.
3) Backups y restauración cronometrada
Copias inmutables / desconectadas y pruebas de restauración con tiempos reales. El backup existe cuando se restaura.
4) Dependencias globales bajo control
Identificar servicios “globales” que ancoran en US-EAST-1 (IAM, colas, catálogos, tablas globales) y preparar rutas alternativas o mitigaciones.
5) Multicloud… cuando tenga sentido
Para continuidad, soberanía o riesgo regulatorio, usar doble proveedor en el mínimo viable: identidad/registro, backups, DNS o un subconjunto crítico. “No se trata de abandonar a los hiperescalares”, matiza Carrero, “sino de reducir concentración de riesgo y ganar resiliencia”.
Europa sí tiene opciones: compleméntalas
La otra cara del debate es industrial. “En Europa hay muchas opciones ganadoras que a veces se menosprecian por la presión de ‘estar con los grandes’”, señala Carrero. “No solo Stackscale puede ser una alternativa o complemento: el ecosistema europeo y español —cloud privada, bare-metal, housing, conectividad, backup y servicios gestionados— es amplio y profesional, sin nada que envidiar a los hiperescalares para la gran mayoría de necesidades”.
En la práctica:
- Ubicar datos y apps críticas en infraestructura europea (privada/soberana) y enlazar con SaaS/hiperescalas donde aporte valor.
- Asegurar que capas de continuidad (backups, DNS, observabilidad) no comparten dominio de fallo con el proveedor principal.
- Apoyarse en partners locales para SLA reales y soporte de proximidad.
Qué hacer hoy (y qué tener listo para el próximo lunes)
Usuarios
- Consulta la página de estado del servicio afectado antes de reinstalar.
- Reintenta más tarde: las recuperaciones son graduales.
Equipos de TI (ahora)
- Evita cambios apresurados; conmutar solo si existe una ruta probada.
- Comunica estado y próximos pasos; recopila métricas para el post-mortem.
Equipos de TI (próximas semanas)
- Mapea RTO/RPO por servicio y ajusta arquitectura/presupuesto a esos objetivos.
- Ensaya conmutaciones (gamedays) y documenta resultados.
- Externaliza observabilidad/identidad de emergencia fuera del dominio de fallo principal.
- Desancla dependencias globales; revisa qué se rompe si US-EAST-1 deja de responder.
El fondo del asunto: dependencia y autonomía
La caída se resolvió en horas, pero el patrón se repite (2020, 2021, 2023 y ahora 2025). La moraleja no es “huir del cloud”, sino diseñar para fallar y diversificar. “La resiliencia no es un eslogan”, concluye Carrero. “Es ingeniería y disciplina. Si tu negocio vive de su plataforma, tiene que seguir aunque falle el proveedor principal. HA no es plan B; el plan B es otra ruta completa para llegar al mismo resultado”.
En dos líneas: en España y Europa seguimos sin plan B cuando un hiperescalador estornuda. Toca repartir la carga, probar la continuidad y activar el músculo europeo como complemento. La próxima incidencia no es una posibilidad remota; es cuándo. La diferencia entre un susto y una crisis la marcará, otra vez, la preparación.
