La interrupción global de AWS del 20 de octubre volvió a poner contra las cuerdas a medio Internet: Bizum, Ticketmaster, Canva, Alexa, videojuegos online… y muchas aplicaciones empresariales que, sin estar en Estados Unidos, dependen de US-EAST-1 para funciones de identidad, colas, bases de datos o planos de control. Se resolvió en horas, sí, pero dejó al descubierto una realidad incómoda: abunda la alta disponibilidad (HA) y escasea el plan B.
David Carrero, cofundador de Stackscale (Grupo Aire): “Muchas empresas en España y Europa confían toda su infraestructura a un hiperescalador y no tienen un plan B ni en servicios críticos. La HA es necesaria, pero si todo depende de un elemento común, el HA falla”.
Más allá del diagnóstico, esta es una guía práctica —con foco “misión crítica”— para reforzar la resiliencia y recortar el tiempo de caída la próxima vez.
Qué significa “misión crítica” (de verdad)
Antes de hablar de arquitectura, dos números obligatorios:
- RTO (Recovery Time Objective): cuánto tiempo te puedes permitir estar caído.
- RPO (Recovery Point Objective): cuántos datos puedes perder (en tiempo) al recuperar.
Sin RTO/RPO claros, todo es decoración. Carrero lo resume así: “Diseña para tu RTO/RPO real. Si un servicio no puede caer, no basta un Multi-AZ con el plano de control en US-EAST-1”.
Patrones de resiliencia que funcionan
1) Activa/Activa multirregión (dentro del mismo hiperescalador)
- Cuándo: pagos, identidad de clientes, core transaccional.
- Cómo: datos replicados síncronos (o cuasi-síncronos) donde el latency budget lo permita; quórums en BBDD distribuidas; conflict-free para contadores/estados (CRDTs, sagas).
- DNS/GTM: salud orientada a servicio, health checks que prueban funciones reales, no pings.
- Riesgos: coste y complejidad; pero es el patrón con mejor RTO/RPO.
2) Warm Standby multirregión (activo/pasivo caliente)
- Cuándo: la mayor parte de cargas “importantes” pero no core.
- Cómo: datos replicados asíncronos, infra preaprovisionada en la región “B”, runbooks de elevación en minutos.
- DNS: failover automático con políticas de degradación (leer-solo, modos limitados).
- Riesgos: aceptas un RPO>0 (pérdida acotada de datos).
3) Multicloud selectivo (cuando hay riesgo regulatorio o de concentración)
- Patrones:
- Pilot-light (lo mínimo encendido en el 2.º cloud: identidad, DNS, observability, backups).
- Hot-Hot sólo para un subconjunto muy crítico (por coste y complejidad).
- Qué mover: continuidad (DNS, logging/SIEM, status page, break-glass IdP), backups e inmutabilidad en proveedor alterno.
- Meta: no “abandonar” al hiperescalador, reducir concentración de riesgo.
4) Datos y replicación
- Transaccional: BBDD distribuida con quórums regionales; sagas y event sourcing para operaciones complejas.
- Objetos: versión + replicación cross-region; bloqueos legales (“inmutables”) y air-gap.
- Catálogos/colas: evalúa dónde anclan (muchos “globales” apuntan a US-EAST-1); usa alternativas locales si tu RTO/RPO lo exige.
5) Red y DNS
- Doble proveedor DNS y GTM con pruebas de servicio (no sólo TCP/443).
- Multi-CDN con origin shielding y orígenes alternos (activa/activa o activa/pasiva).
- Enlaces privados redundantes (overlay SD-WAN) entre cloud y privado.
6) Identidad y control de acceso
- IdP resistente a caídas (caché de JWKS con TTL y reglas de re-autenticación por contexto).
- Break-glass: cuentas fuera del dominio de fallo con MFA fuerte (hardware keys).
- App governance para evitar consent phishing y abusos de OAuth.
7) Observabilidad fuera del mismo fallo
- Telemetry en otra región o otro proveedor (al menos un mirror).
- Runbooks con dashboards y status pages que no dependan de la región caída.
8) Backups que se restauran
- Inmutables / desconectados (objetos bloqueados, retención legal).
- Restore cronometrado: pasar de “tenemos copias” a “restauramos en X minutos”.
9) Arquitectura de aplicación
- Idempotencia + reintentos con jitter; circuit breakers y bulkheads para que un fallo no “arrastre” todo.
- Desacoplar por colas/eventos; limitar estado en sesión; caches con TTL diseñado para degradación.
- Modos degradados: lectura-solo, feature flags para desactivar funciones caras.
10) Chaos engineering y gamedays
- Ensayar caídas de región, IdP, DNS, colas y BBDD.
- Medir RTO real, dwell time del fallo y MTTR de conmutación.
Soberanía y “complemento europeo”
Carrero: “No hace falta renunciar a los hiperescalares, pero sí equilibrar. En Europa hay proveedores muy competitivos en cloud privada, bare-metal, housing, conectividad, backup y servicios gestionados. Para el 90 % de las necesidades no críticas de IA a gran escala, no hay nada que envidiar”.
Estrategia práctica:
- Aloja datos y apps críticas en infraestructura europea (privada o soberana) y conéctalos a SaaS/hiperescalas donde aporten valor.
- Mantén capas de continuidad (observabilidad, DNS, backups, identidad de emergencia) fuera del mismo dominio de fallo.
- Exige SLA, soporte 24/7 y contratos de salida (portabilidad de logs, datos y copias).
Checklist de resiliencia
- RTO/RPO por servicio firmados por negocio.
- Mapa de dependencias (qué rompe a qué) y anclas globales (US-EAST-1).
- Failover documentado y ensayado (gamedays trimestrales).
- Backups inmutables + restore cronometrado reciente.
- DNS/GTM multi-proveedor y multi-CDN con orígenes alternos.
- IdP con break-glass y caché de claves; App governance.
- Observabilidad fuera del mismo cloud/región.
- Feature flags para degradación controlada y circuit breakers.
- Contrato con proveedor(es) local(es) para continuidad (DR, housing, bare-metal, soporte).
- Métricas al comité: % MFA fuerte, TTR, tiempo a parchear activos expuestos, tasa de restores OK.
Conclusión
La caída de AWS no es un meteorito imprevisible; es un riesgo operativo recurrente. La respuesta no es “huir del cloud”, sino diseñar para fallar y desconcentrar los puntos únicos de ruptura. Como dice Carrero, “HA no es plan B; el plan B es otra ruta completa hacia el mismo resultado”. España y Europa tienen músculo técnico para complementarlo: repartir cargas, probar la continuidad y elevar el listón de misión crítica. La próxima incidencia no es si, sino cuándo. La diferencia entre un susto y una crisis la marcará —otra vez— la preparación.
