--- title: "De la alta disponibilidad al plan B real: aprendizajes del último apagón de AWS y una guía práctica" description: "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..." url: https://www.stackscale.com/es/blog/de-la-alta-disponibilidad-al-plan-b-real/ date: 2025-10-21 modified: 2025-10-21 author: "Marketing Stackscale" image: https://www.stackscale.com/wp-content/uploads/2022/03/what-is-a-data-center-Stackscale.jpg categories: ["Computación", "Continuidad del negocio"] tags: ["alta disponibilidad", "Infraestructura", "nube"] type: post lang: es --- # De la alta disponibilidad al plan B real: aprendizajes del último apagón de AWS y una guía práctica 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](https://www.stackscale.com/es/productos/almacenamiento-georeplicacion-sincrona/) 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**. Request information form ES Updates NombreEmailTeléfonoEstoy interesado/a en:Soluciones cloudSoluciones Bare MetalServicios gestionadosSoluciones de Disaster Recovery y backupServicios de housingSoluciones de CDNCuéntanos más sobre tus necesidades Acepto el envío de comunicaciones comerciales personalizadas sobre los productos y servicios de Stackscale (incluida la newsletter), por cualquier medio, incluidos los electrónicos. He leído y acepto la [política de privacidad](/es/politica-privacidad/). Enviar El Grupo Stackscale trata la información que nos facilita con el fin de dar respuesta a la solicitud realizada en relación con los servicios que prestamos y los productos que suministramos. Los datos proporcionados se conservarán mientras se mantenga el contacto siendo eliminados una vez finalizada la solicitud, a no ser que consienta el envío de comunicaciones comerciales, donde sus datos se conservarán hasta la revocación del consentimiento previamente otorgado. En el marco del Grupo al que pertenece Stackscale, se le informa de que sus datos serán comunicados a las empresas de Grupo Aire por motivos corporativos. Puede consultar las empresas que forman parte del Grupo Aire en: [https://grupoaire.es](https://grupoaire.es). Usted puede ejercitar sus derechos de acceso, rectificación, supresión, oposición, limitación del tratamiento y, cuando legalmente proceda, portabilidad, mediante el envío a Stackscale de una solicitud a la dirección dp*@********le.com, indicando el derecho que ejercita y aportando una fotocopia por las dos caras de su DNI o documento legal de identificación de su identidad. Igualmente, podrá presentar una reclamación ante la Agencia Española de Protección de Datos, especialmente cuando no haya obtenido la satisfacción en el ejercicio de sus derechos, a través de la sede electrónica en [www.aepd.es](https://www.aepd.es/).