Alta disponibilidad multi-zona y multi-región
Repartir una aplicación en varias zonas es barato y resuelve la falla más frecuente. Repartirla en varias regiones cuesta un orden de magnitud más y resuelve una falla rara. Saber cuál de las dos hace falta es la decisión, y casi siempre es la primera.
Para este tema conviene tener claro:Regiones, zonas de disponibilidad y ubicaciones de borde
Datos de proveedores verificados contra la documentación oficial el 19 de sept de 2026.
“Que no se caiga” no es un requisito: es un deseo. El requisito aparece cuando se contesta de qué falla hay que sobrevivir —una máquina, una zona, una región entera— y cuánto se está dispuesto a pagar por eso.
Y hay una asimetría que ordena toda la decisión: pasar de una zona a dos es casi gratis y elimina la causa más común de caída; pasar de una región a dos cambia la arquitectura entera y elimina una causa que ocurre cada varios años.
De qué falla se sobrevive
| Falla | Qué la resuelve | Costo relativo | Frecuencia |
|---|---|---|---|
| Una instancia | Varias instancias detrás de un balanceador | Bajo | Semanal |
| Una zona de disponibilidad | Réplicas en dos o tres zonas de la misma región | Bajo: el doble de cómputo | Cada varios meses |
| Una región | Copia completa en otra región | Alto: infraestructura, datos y operación duplicados | Cada varios años |
| El proveedor entero | Otra nube | Muy alto, y rara vez se justifica | Prácticamente nunca |
| Un error propio, como borrar datos | Respaldos y poder volver atrás | Bajo | La causa más común de todas |
Multi-zona: el estándar razonable
Las zonas de una región son centros de datos separados, con energía y refrigeración independientes, unidos por red de baja latencia —del orden de uno o dos milisegundos—. Esa latencia baja es lo que permite replicar de forma sincrónica sin que la aplicación lo note.
Qué implica en la práctica
- Cómputo en dos o tres zonas, con capacidad para absorber la caída de una: si dos zonas están al 80 %, perder una deja a la otra al 160 % y el sistema se cae igual.
- Base gestionada con réplica en espera en otra zona y conmutación automática.
- Almacenamiento de objetos, que ya es multi-zona por defecto en su clase estándar.
- Balanceador, que en los tres proveedores es un servicio regional y sobrevive a la caída de una zona por sí mismo.
- Cuidado con el tráfico entre zonas, que se cobra y, en sistemas conversadores, se nota.
Antes de seguir, predecí
Multi-región: qué se rompe cuando se intenta
Entre regiones la latencia pasa a decenas o cientos de milisegundos. Esa sola diferencia hace que la replicación sincrónica deje de ser viable para la mayoría de las cargas, y ahí aparece el problema real: los datos.
| Estrategia | Cómo funciona | Qué cuesta |
|---|---|---|
| Activo-pasivo con respaldo | La otra región se construye cuando hace falta | Recuperación de horas; lo más barato |
| Activo-pasivo tibio | Infraestructura mínima prendida y datos replicándose | Recuperación de minutos; costo moderado |
| Activo-pasivo caliente | Capacidad completa lista, sin tráfico | Recuperación de minutos; costo casi doble |
| Activo-activo | Las dos regiones atienden tráfico | Máxima disponibilidad; la complejidad de escribir en dos lados |
Antes de seguir, predecí
Cómo se decide, en una conversación
Cuatro preguntas, en este orden
- ¿Cuánto cuesta una hora de caída? En plata, en usuarios o en contratos. Sin este número, toda la discusión es estética.
- ¿Cuántos datos se pueden perder? Es la que define si alcanza con respaldos o hace falta replicación continua.
- ¿Qué tan rápido hay que volver? Define si la otra región puede construirse en el momento o tiene que estar prendida.
- ¿Quién opera esto un domingo? Una arquitectura multi-región mal operada es peor que una regional bien operada.
Más a fondo · nivel seniorLa conmutación que nunca se probó
Casi todas las arquitecturas multi-región que fallan lo hacen por lo mismo: la conmutación existe en el diagrama y nunca se ejecutó. Cuando llega el momento aparecen los detalles que nadie anotó: el certificado sólo estaba emitido en la región principal, la cuota de la región secundaria no alcanza para el tráfico real, el pipeline sólo sabe desplegar en una, los secretos no estaban replicados.
Lo que convierte el plan en una capacidad es ejercitarlo con calendario: una conmutación planificada por trimestre, con la aplicación sirviendo desde la región secundaria un rato de verdad. Es incómodo y es exactamente el punto. La variante barata para empezar, cuando el ejercicio completo todavía asusta, es mandar un porcentaje chico del tráfico real a la región secundaria de forma permanente: así nunca está fría, y la falta de cuota o de certificado aparece un martes a la mañana en vez de durante el incidente.
Cierre
Autoevaluación
¿Lo entendiste?
Práctica