El incidente de AWS del 20 de octubre volvió a recordarnos lo de siempre: la resiliencia no se improvisa. La alta disponibilidad (HA) dentro de una región ayuda, pero no sustituye un plan B capaz de mantener el servicio cuando falla el elemento común del que dependen demasiadas piezas (región, plano de control, DNS, colas, identidad, etc.).
En esta guía compartimos un enfoque práctico para pasar de “HA” a continuidad de negocio, con patrones que vemos funcionar en producción y que en Stackscale implementamos con dos centros de datos en activo-activo. Y, cuando el negocio lo requiere, se combinan sin fricciones con otros proveedores. Todo empieza por lo básico: definir RTO/RPO y ensayar la conmutación.
David Carrero (cofundador de Stackscale): “La HA es necesaria, pero si todo depende de un punto común, HA falla. La diferencia entre un susto y una crisis la decide un plan B ensayado”.
1) Alinear negocio y tecnología: RTO/RPO y mapa de dependencias
- RTO (Recovery Time Objective): cuánto tiempo puede estar parado un servicio.
- RPO (Recovery Point Objective): cuántos datos puedes perder (en tiempo) al recuperar.
Con esos objetivos firmados por negocio, dibuja el mapa de dependencias: ¿qué rompe a qué?, ¿dónde “ancoran” identidad, DNS, colas, catálogos o tablas globales? La salida de ese análisis es tu lista de servicios que no pueden caer y de qué dependen.
2) Patrones de continuidad que sí funcionan
Activo-activo en dos centros de datos (RTO=0 / RPO=0)
Para pagos, identidad o transacciones core:
- Replicación síncrona de almacenamiento entre los dos CPDs → RTO=0 / RPO=0.
- BBDD distribuidas o con quórum, con contención de conflictos (CRDTs / sagas).
- DNS/GTM con health checks de servicio real (no pings).
- Modos degradados definidos (lectura-solo, feature flags).
En Stackscale ofrecemos activo-activo en dos centros de datos de Europa con replicación síncrona como base de misión crítica. Ese núcleo puede complementarse con terceros (hiperescalares u otros CPD) si necesitas una tercera vía de continuidad o requisitos de soberanía/localización.
Espera caliente multisitio (activo-pasivo “caliente”)
Para la mayoría de cargas importantes:
- Replicación asíncrona de datos a un segundo site.
- Infra preaprovisionada (plantillas / IaC) para elevar el site B en minutos.
- Failover automático vía DNS/GTM y runbooks ensayados.
Encendido mínimo en proveedor alterno (antes “pilot-light”)
Cuando quieres reducir concentración de riesgo con coste controlado:
- Mantén lo mínimo encendido fuera del proveedor principal (p. ej., DNS, observabilidad, backups inmutables, identidad de emergencia, status page).
- Eleva a activo-pasivo o activo-activo solo lo crítico, según RTO/RPO.
Carrero: “No se trata de abandonar a los hiperescalares, sino de equilibrar. El ecosistema europeo —incluida España— es maduro y complementa muy bien para resiliencia y soberanía”.
3) Tres capas que mueven la aguja (y cómo tratarlas)
Datos
- Transaccional: distribución por quórums + control de conflictos.
- Objetos: versionado + replicación entre sites, inmutabilidad (bloqueo WORM) y, si aplica, air-gap.
- Catálogos/colas: evita servicios “globales” anclados en una única región externa si tu RTO/RPO no lo tolera.
Red / DNS / CDN
- Dos proveedores de DNS y GTM con pruebas de negocio (una transacción de salud, no un simple ping).
- Multi-CDN y orígenes alternos (A/A o A/P) con origin shielding.
- Conectividad privada redundante (overlay SD-WAN) entre nube y CPD.
Identidad y acceso
- IdP con caché de claves (JWKS) y re-autenticación contextual.
- Cuentas “break-glass” fuera del dominio de fallo con MFA fuerte (llaves hardware).
- App governance para frenar consent phishing y abusos de OAuth.
4) Observabilidad, copias y ensayo: sin esto no hay plan B
- Observabilidad fuera del mismo fallo: al menos un mirror de métricas/logs y una status page que no dependan del proveedor principal.
- Backups inmutables y restauración cronometrada (con éxito reciente).
- Gamedays trimestrales: caída de región/IdP/DNS/colas/BBDD. Mide RTO real, dwell time y MTTR.
5) Dos arquitecturas de referencia (y cómo encajan con Stackscale)
Continuidad “todo Stackscale”
- CPD A + CPD B (Stackscale) en activo-activo con replicación síncrona (RTO=0/RPO=0).
- Backups inmutables en un tercer dominio (otro CPD u object storage aislado).
- DNS/DNSSEC multi-proveedor + GTM con health checks de negocio.
- Observabilidad replicada fuera (proveedor dedicado o segundo Stackscale).
- Runbooks y gamedays regulares con soporte de proximidad.
Continuidad híbrida (Stackscale + otra ubicación/proveedor)
- CPD A + CPD B (Stackscale) activo-activo para lo core.
- Encendido mínimo en otro proveedor para DNS, status, logs/SIEM y objeto inmutable (o a la inversa).
- Workloads no críticos en la otra ubicación, con DR de vuelta a Stackscale si exige soberanía o coste.
- Conectividad privada y políticas portables (identidad, logging, backup).
Qué aporta Stackscale:
- Dos centros de datos en Europa con latencia baja, redes y energía redundantes, y soporte 24/7 cercano.
- Replicación síncrona para aplicaciones de misión crítica (RTO=0/RPO=0).
- Almacenamiento de alto rendimiento (bloque/objeto) con versionado y bloqueo WORM (Object Lock) para copias inmutables.
- Bare-metal y cloud privado para consolidar cargas, y conectividad dedicada con operadores y nubes públicas a través de socios.
- Integración sencilla con proveedores externos (DNS, CDN, observabilidad, hiperescalas) para estrategias híbridas o multicloud selectivas.
6) Hoja de ruta 30-60-90 días (realista y accionable)
Día 1–30
- Aprobación RTO/RPO por servicio.
- Mapa de dependencias y anclas globales.
- Backups inmutables y primer restore cronometrado.
Día 31–60
- DNS/GTM multi-proveedor, multi-CDN y observabilidad fuera del mismo dominio de fallo.
- Encendido mínimo (identidad de emergencia, status, SIEM).
- Primer gameday (DNS + BBDD/colas).
Día 61–90
- Despliegue activo-activo o espera caliente entre los dos CPDs de Stackscale.
- Integraciones con terceros (si aplican).
- Gameday de caída de región completa y revisión de métricas.
7) Métricas ejecutivas que sí dicen algo
- % de servicios con RTO/RPO firmados y cumplidos en ensayo.
- Restore OK (últimos 30 días) y tiempo medio de restauración.
- Tiempo de conmutación (gamedays) y dwell time por escenario.
- Cobertura de observabilidad “fuera” del fallo (sí/no por dominio).
- Dependencias “globales” con alternativa (sí/no).
Cierre: resiliencia con cabeza (y sin atarse las manos)
La lección no es “huir del cloud”, sino diseñar para fallar y desconcentrar puntos únicos de ruptura. La HA es necesaria, pero no basta: hace falta otra ruta completa hacia el mismo resultado. Con dos CPDs en activo-activo (RTO=0/RPO=0) como base y capas de continuidad —DNS, copias inmutables, observabilidad e identidad de emergencia— fuera del mismo dominio de fallo, tu plataforma seguirá en pie cuando un proveedor o una región tropiece.
En Stackscale acompañamos esa transición todos los días. Y, cuando lo piden los objetivos de continuidad o la regulación, combinamos nuestra infraestructura en dos centros de datos con otros proveedores. Así el plan B deja de ser un PDF en un cajón y pasa a ser un camino ya transitado.
