Multirregión y multinube

«Multirregión» y «multinube» suenan parecido y se mezclan en las reuniones. Detrás hay tres problemas distintos, con costos muy distintos. Antes de elegir un patrón, nombra cuál de los tres estás resolviendo.

Tres problemas que se confunden

Cada nivel se apoya en el anterior. Una arquitectura en dos regiones donde cada región depende de una sola AZ está mal armada desde el principio. Empieza por alta disponibilidad; las estrategias clásicas para perder una región están en recuperación ante desastres.

Por qué ir a varias regiones, y por qué cuesta

Hay cuatro razones sólidas:

• Recuperación ante desastres: seguir operando si una región tiene problemas serios.
• Latencia: atender a usuarios de otro continente desde una región cercana.
• Residencia de datos: ciertas leyes exigen que los datos de sus ciudadanos se queden en el país.
• Radio de impacto: si despliegas región por región, un cambio malo afecta solo a una. La segunda región también te protege de ti mismo.

Y tres costos que siempre llegan:

• Replicar datos: la transferencia entre regiones se cobra, y la replicación agrega retraso y casos raros. Más en costos de datos.
• Operación duplicada: cuotas, despliegues, alarmas, parches y certificados en dos lugares.
• Complejidad: consistencia de datos, decisiones de failover y pruebas que antes no existían.

Los patrones, de menos a más activo

Todos son variantes de activo-pasivo (una región principal y otra de respaldo) salvo el último. La diferencia entre espera activa y en caliente es que la segunda no depende de escalar durante la crisis: la capacidad ya está ahí. AWS llama a eso estabilidad estática. Escalar es una operación del plano de control, y en un desastre conviene depender solo del plano de datos.

Hay dos patrones más que se usan mucho en la práctica:

• Activo-activo selectivo: solo algunos componentes atienden en las dos regiones. Por ejemplo, el inicio de sesión y el catálogo responden desde ambas, mientras los pagos escriben en una sola región y la otra espera.
• Capacidades repartidas entre proveedores: el DNS o la CDN en un proveedor externo, la identidad en otro, una copia de los respaldos en otra nube. No duplicas todo: eliges qué pieza no puede depender de un solo proveedor.

Cuando varias regiones aceptan escrituras, aparece la pregunta difícil: qué pasa si dos regiones cambian el mismo dato a la vez. AWS describe tres estrategias: escribir global (todas las escrituras van a una región), escribir local (cada región escribe y gana la última escritura) y escritura particionada (cada usuario tiene una región dueña). Las verás a fondo en replicación y consistencia.

Un patrón por componente, no uno para todo

La idea central: no todo tiene que estar activo en todas partes. Cada componente recibe el patrón más barato que cumple su objetivo.

1. 1

   Clasifica por criticidad

   ¿Qué deja de facturar o de cumplir la ley si falla? El checkout no pesa lo mismo que el reporte mensual.
2. 2

   Fija RTO y RPO por componente

   Los define el negocio, no el equipo técnico. Cómo descomponerlos y medirlos está en RPO y RTO a fondo.
3. 3

   Decide qué consistencia necesita el dato

   Un carrito tolera que gane la última escritura. Un saldo bancario, no. Eso define si puede escribirse en dos regiones.
4. 4

   Mide tu capacidad operativa

   ¿Quién opera dos regiones a las 3 de la mañana? Un activo-activo que el equipo no entiende es más frágil que un buen activo-pasivo.
5. 5

   Elige, documenta y prueba

   Registra la decisión y ensaya el cambio de región con simulacros. Un patrón sin ensayo es solo una intención.

Dirigir el tráfico entre regiones y proveedores

Tener una segunda región no sirve si los usuarios no llegan a ella. Route 53 ofrece políticas de enrutamiento de failover (activo-pasivo), por latencia, por geolocalización, por geoproximidad, ponderado, por IP y de respuesta multivalor, todas combinables con chequeos de salud. Los chequeos de salud pueden vigilar cualquier dirección pública, también fuera de AWS.

Un detalle importa: el failover por chequeo de salud ocurre en el plano de datos y es muy fiable; cambiar los pesos de un registro a mano es una operación del plano de control, menos resistente en plena crisis. Para un cambio manual pero seguro, los controles de enrutamiento de ARC funcionan como interruptores. Lo verás en failover, failback y split-brain.

Si usas dos proveedores, el DNS no debería vivir solo en uno de ellos. Una opción es un DNS global de un tercero que revisa la salud de ambos lados. Agregas un proveedor más, pero ninguna de las dos nubes queda como punto único de falla.

• 

  Aurora Global Database

  El archivo central con copias vivas en otras ciudades

  Una región principal que escribe y hasta 10 regiones secundarias de solo lectura. Replica con retraso típico de menos de un segundo. Soporta cambio planeado (switchover) y failover.
• 

  DynamoDB global tables

  Cada réplica acepta lecturas y escrituras. Por defecto la consistencia entre regiones es eventual; también hay un modo de consistencia fuerte entre regiones con RPO cero.
• 

  Replicación de S3

  Copia objetos a otro bucket, en otra región o cuenta. Con S3 Replication Time Control, el tiempo de replicación queda respaldado por un SLA.
• 

  Replicación de ECR

  Copia las imágenes de contenedor a otras regiones o cuentas al subirlas, para que la región secundaria no dependa del registro de la principal.
• 

  Amazon Application Recovery Controller

  El tablero de emergencia

  Region switch orquesta planes de cambio de región entre cuentas; los controles de enrutamiento mueven el tráfico con reglas de seguridad.
• 

  AWS Global Accelerator

  Dos IPs estáticas anycast que llevan el tráfico por la red de AWS hasta la región sana más cercana, sin depender de cachés de DNS.

Multinube, con honestidad

Hay razones reales para usar más de un proveedor:

• Regulación: algunos reguladores financieros piden planes de salida y evaluar el riesgo de depender de un solo proveedor.
• Riesgo de concentración: el negocio no acepta que una sola empresa pueda detenerlo.
• Fusiones y adquisiciones: compraste una empresa que vive en otra nube y migrarla no se justifica todavía.
• Capacidades específicas: un servicio que solo existe, o es claramente mejor, en otro proveedor.

Y razones flojas: «por si acaso», sin un RTO que lo justifique; «evitar el lock-in» en abstracto; o usar solo lo que existe en todas las nubes y renunciar a lo mejor de cada una. Negociar precios puede ser válido, pero rara vez compensa operar dos plataformas completas.

Lo que lo hace difícil:

• Identidad: dos modelos de permisos distintos que hay que mantener alineados.
• Red: interconexión privada, planes de direcciones IP que no choquen, DNS compartido.
• Gravedad de los datos: las aplicaciones van donde están los datos, no al revés.
• Observabilidad: métricas, logs y trazas en un solo lugar, con nombres comparables.
• Habilidades: el equipo necesita saber operar las dos plataformas bajo presión.
• Egreso: sacar datos de una nube hacia otra se cobra, y la replicación continua lo hace todos los días.

Lo más difícil son los datos, no el cómputo. Un contenedor arranca en cualquier parte en segundos. Una base de datos de varios terabytes, replicada de forma consistente entre dos proveedores, no. Más sobre esto en portabilidad y dependencia del proveedor.