Un proveedor de nube puede replicar su infraestructura en Virginia, Fráncfort y Singapur al mismo tiempo, y va a cobrarle por las tres. La pregunta que casi nunca se hace antes de firmar esa arquitectura es cuánto le cuesta a la empresa cada hora que el sistema está caído, porque ese número —y no el catálogo del proveedor— es el que determina cuánta redundancia tiene sentido pagar.
En proyectos de infraestructura para empresas medianas nos encontramos con las dos versiones del error. Están las que no tienen ningún esquema de recuperación y descubren el problema el día que un centro de datos falla, y están las que pagan una réplica activa en una segunda región geográfica para sostener un sistema que se usa de ocho de la mañana a seis de la tarde y que podría estar detenido tres horas sin que nadie fuera de la oficina lo notara. Dimensionar bien la redundancia empieza por medir el daño, no por revisar el catálogo.
El número que hay que calcular antes de dibujar la arquitectura
Hay dos métricas que definen todo lo demás. El RTO es el tiempo máximo que la operación puede estar detenida antes de que el daño deje de ser tolerable. El RPO es la cantidad de trabajo que la empresa puede permitirse perder, medida en tiempo: si el RPO es de una hora, se acepta que un incidente borre la última hora de transacciones registradas.
Ponerles número obliga a una conversación que suele postergarse, porque la respuesta sale de finanzas y de operaciones antes que de sistemas. Una plataforma de comercio electrónico que factura durante las veinticuatro horas puede calcular con bastante precisión lo que pierde por hora de indisponibilidad, y ese cálculo justifica una arquitectura cara. Un ERP que usan cuarenta personas en horario de oficina tiene un costo por hora mucho menor, y además tiene la opción de recuperarse de noche sin impacto en la operación. Son dos negocios distintos y merecen dos arquitecturas distintas, aunque el proveedor de nube les ofrezca exactamente el mismo menú.
Cuando ese número no existe, el diseño termina apoyado en la intuición del último incidente que alguien recuerda. Este trabajo previo es el mismo que sostiene un plan de disaster recovery que funcione, y conviene hacerlo antes de comparar precios de instancias.
Qué protege una zona de disponibilidad
Una región de nube está compuesta por varias zonas de disponibilidad, y cada zona es un centro de datos físicamente separado de los demás: edificio propio, alimentación eléctrica independiente, refrigeración independiente, conectados entre sí por fibra dedicada con latencias de uno o dos milisegundos. Esa separación física es la que hace que un incendio, un corte eléctrico o una falla de refrigeración en una zona no arrastre a las otras.
Distribuir la infraestructura entre dos o tres zonas de una misma región cubre la mayor parte de lo que efectivamente sale mal en producción. La latencia entre zonas es lo bastante baja para permitir replicación síncrona de bases de datos, lo que significa que un incidente en la zona primaria no pierde ni una transacción confirmada. El sobrecosto es real pero acotado: se paga la infraestructura duplicada y el tráfico entre zonas, que en la mayoría de proveedores es considerablemente más barato que el tráfico entre regiones.
Para una empresa mediana con un ERP, un CRM y un par de aplicaciones internas, este nivel resuelve el problema que tiene. Antes de subir un escalón vale la pena revisar si la arquitectura actual saca provecho siquiera de este, porque muchas instalaciones que se describen como “en la nube” siguen siendo un único servidor virtual sin ninguna redundancia detrás.
Lo que la segunda región no resuelve
Aquí está la parte que las presentaciones comerciales omiten. Los incidentes que tumban una región entera existen, pero son minoría dentro de las caídas que sufre una empresa. La mayoría de las interrupciones que hemos atendido tienen otro origen: un despliegue con un error que llegó a producción, un certificado que expiró sin que nadie lo estuviera monitoreando, una regla de firewall mal aplicada, una migración de base de datos que dejó una tabla bloqueada, o la caída de un servicio de terceros del que la aplicación depende sin haberlo previsto.
Ninguna de esas fallas se detiene con una segunda región, porque el despliegue defectuoso se replica a la región secundaria con la misma eficiencia con la que se replicó a la primaria. El certificado vencido lo está en las dos. La regla de firewall equivocada viaja en el mismo código de infraestructura. Pagar por duplicar geográficamente una plataforma sin haber resuelto antes el monitoreo, el proceso de despliegue y la gestión de credenciales es duplicar también todos esos puntos ciegos.
El segundo detalle incómodo aparece durante los eventos grandes de verdad. Cuando una región importante de un proveedor tiene problemas serios, su propio plano de control —la API con la que usted levantaría la infraestructura secundaria— suele estar saturado, y miles de clientes intentan hacer exactamente lo mismo al mismo tiempo. Los episodios recientes de caídas masivas dejaron esa lección para quien quisiera leerla, igual que el apagón de Cloudflare mostró cuánta infraestructura ajena hay debajo de lo que cada empresa considera “su” plataforma.
Cuándo la segunda región se justifica
Hay tres situaciones donde el cálculo cambia y la inversión se sostiene sola:
- Un compromiso contractual con penalización económica. Si un contrato con un cliente grande fija un nivel de disponibilidad y una multa por incumplirlo, el costo de la segunda región se compara contra la multa, no contra el presupuesto de infraestructura.
- Una exigencia regulatoria sobre dónde residen los datos. Algunos sectores obligan a mantener copias dentro de fronteras determinadas o fuera de ellas, y eso define la geografía antes que cualquier consideración de costo.
- Usuarios repartidos en continentes distintos. Cuando parte de la base de clientes accede desde el otro lado de un océano, la segunda región deja de ser un seguro contra desastres y pasa a ser una decisión de rendimiento que se paga con la experiencia de uso todos los días, no solo el día del incidente.
Fuera de estos tres casos, mantener una réplica activa y sincronizada en otra región rara vez sobrevive a un análisis financiero honesto. La replicación entre regiones distantes tampoco puede ser síncrona sin castigar la latencia de cada escritura, así que en la práctica se trabaja con replicación asíncrona y se asume un RPO de segundos o minutos. Es decir que se paga el doble de infraestructura y aun así hay pérdida de datos posible.
El esquema activa-pasiva y su costo real
Entre no tener nada y mantener dos regiones encendidas hay un punto intermedio que se ajusta bien al perfil de la mayoría de las empresas medianas. En un esquema activa-pasiva se mantiene en la segunda región lo indispensable —la réplica de la base de datos recibiendo cambios, las imágenes de máquina listas, la infraestructura descrita en código— y se deja el cómputo apagado hasta que haga falta. El gasto permanente se reduce al almacenamiento y a la replicación, que es una fracción de lo que cuesta sostener servidores encendidos sin tráfico.
A cambio se acepta un tiempo de recuperación mayor, medido en decenas de minutos en lugar de segundos, porque hay que levantar el cómputo, promover la réplica a primaria y redirigir el tráfico. Para un ERP interno, para una plataforma de gestión documental o para la mayoría de los sistemas de una empresa mediana, esa diferencia entre segundos y media hora no cambia nada material, y la diferencia en la factura mensual sí.
Conviene además mirar el modelo de servicio antes de decidir. Sobre una plataforma gestionada, buena parte de este trabajo viene resuelto por el proveedor, mientras que sobre infraestructura pura queda del lado de la empresa; la comparación entre SaaS, PaaS e IaaS y entre los modelos on-premise, cloud e híbrido cambia bastante el alcance de lo que hay que construir.
Por qué el respaldo no es un plan de continuidad
Muchas empresas creen tener resuelta la continuidad porque hacen copias de seguridad todas las noches. La copia resuelve la pérdida de información, y es imprescindible, pero no dice nada sobre cuánto tiempo tomará volver a estar operando.
Vale la pena hacer el ejercicio completo alguna vez. Restaurar una base de datos de doscientos gigabytes desde un respaldo frío toma su tiempo, pero lo que realmente alarga la recuperación es todo lo que hay alrededor: reconstruir las redes y los grupos de seguridad, reponer las variables de entorno y los secretos, volver a levantar las colas de mensajes, reapuntar los registros DNS y esperar a que expire su TTL, revisar que las integraciones con terceros vuelvan a autenticarse. Una empresa que nunca cronometró ese proceso completo no conoce su RTO; tiene una estimación optimista.
Ese inventario empieza por saber qué información es realmente crítica dentro de la organización y sigue con los pasos preventivos sobre la infraestructura que reducen la probabilidad de llegar a usar el plan.
Un plan que nunca se ejecutó es una hipótesis
El componente que más se descuida no es tecnológico. Es la prueba. Una arquitectura redundante que nunca se sometió a un simulacro de conmutación tiene el mismo valor que un extintor sin revisar: probablemente funcione, y nadie lo sabe con certeza.
Dos veces al año, en una ventana acordada, conviene ejecutar el procedimiento real: declarar la contingencia, promover la réplica, redirigir el tráfico, verificar que la aplicación opera y cronometrar cuánto tardó cada paso. De ahí salen siempre las mismas sorpresas —un secreto que solo existía en la región primaria, un registro DNS con un TTL de veinticuatro horas, un servicio de terceros que tiene la IP antigua en una lista blanca— y es mejor encontrarlas un martes por la tarde con todo el equipo disponible que a las tres de la mañana durante un incidente real.
Conclusión
Para la mayoría de las empresas medianas, distribuir la infraestructura entre las zonas de disponibilidad de una misma región, sumar un esquema activa-pasiva hacia una segunda región para los sistemas verdaderamente críticos, y probar la conmutación dos veces al año, cubre el riesgo que la organización enfrenta en la realidad a un costo que el negocio puede sostener. La redundancia multi-región activa y permanente pertenece a un puñado de casos con justificación contractual, regulatoria o de rendimiento, y fuera de ellos suele ser una decisión que se defiende mejor en una presentación que en una hoja de cálculo.
Antes de comparar arquitecturas, calcule lo que cuesta una hora de indisponibilidad en su operación. Ese número ordena todas las demás decisiones, y es también el punto donde suele descubrirse que una interrupción cuesta bastante más de lo que se creía.
Preguntas frecuentes
¿Cuánto encarece pasar de una zona a dos zonas de disponibilidad?
Depende de qué se duplique. El cómputo y el almacenamiento redundante se pagan completos, y se agrega el tráfico entre zonas. Como referencia de diseño, es el escalón más barato de toda la escala de redundancia y el que más incidentes cubre por peso invertido.
¿Sirve una segunda región en otro proveedor en lugar de otra región del mismo?
Protege también contra fallas del proveedor, que es un riesgo real, pero multiplica el trabajo: dos consolas, dos modelos de red, dos formas de gestionar identidades y una capa de compatibilidad que hay que mantener. Para una empresa mediana, rara vez compensa; tiene más sentido para quien ya opera con equipos de infraestructura dedicados.
¿Con qué frecuencia hay que probar la conmutación?
Dos veces al año como mínimo, y siempre después de un cambio estructural en la arquitectura. Una prueba anual suele llegar cuando ya cambiaron demasiadas cosas desde la anterior como para que el resultado signifique algo.
