Cómo separamos central de regional sin duplicar todo.
Multi-región no es 'un stack copiado N veces'. Tres capas, cada una con un trabajo claro, y una sola regla sobre quién depende de quién.
La visión naive de multi-región es copiar tu stack N veces y poner load-balancing. Funciona para apps stateless sin identidad compartida. Falla en el momento que tenés usuarios que existen entre regiones, billing que tiene que ser único, o un catálogo de marca que es el mismo en todos lados.
El split que aguanta son tres capas, no un stack repetido.
Las tres capas
Global, existe una vez, sin concepto de región. Cosas como la zona DNS, los registries de containers, el provider OIDC para deploys de CI, los roles IAM compartidos entre el fleet, el certificado TLS wildcard para el dominio principal. Estos recursos no tienen sabor regional; son el tejido conectivo de la cuenta misma.
Central, existe una vez, en la región primaria. El control plane. Autenticación, billing, datos de registro que necesitan una única fuente de verdad. Todo lo que "dos de esto es una contradicción" vive acá. Usuarios, sesiones, estado de subscripción, el registro de en qué regiones vive un tenant.
Regional, existe por región, replicado por composición. El data plane. App servers, base regional, bucket de storage, queues, distribución de CDN. Cada región tiene su propia versión de todo esto, aislada de las otras. El contenido del usuario vive en su región; no se distribuye.
La regla que hace esto funcionar: el código regional nunca alcanza recursos regionales de otra región. Puede hablar para arriba con central. Central puede hablar para abajo con cualquier región. Pero la app de region-A nunca lee la base de region-B directamente.
Por qué esto le gana a "copiar-pegar el stack"
Empecemos con el costo. Si hacés cada recurso regional, provisionás N copias de identidad y billing, y en el momento que un usuario se registra en región A y paga en región B, tenés un problema de coordinación que no pediste. Dos tablas de billing significan dos verdades sobre lo que debe. Sacá la autenticación a central y la pregunta desaparece: hay un solo lugar para preguntar "quién es este usuario", y vive en una región con un schema.
Después está la residencia de datos. Algunas regiones tienen requisitos legales sobre dónde se sienta físicamente la data del cliente. Buckets regionales y bases regionales te dejan decir "la data del cliente EU vive en EU" y probarlo con el IAM y la topología. Si todo es central, eso es más difícil, tendrías que particionar filas adentro de una base por tag de región y confiar en el predicado. Los reviewers de compliance no aman el "confiá en el predicado".
Y el blast radius. Una caída central detiene operaciones cross-región, registro, pago, creación de marca. Eso es malo. Una caída regional detiene solo esa región. Eso es peor para los usuarios de esa región pero no se lleva al resto del mundo. El split limita el peor caso.
Cómo funciona la base regional concretamente
Mismo nombre de base en cada cluster regional, clusters físicos distintos, data distinta. El cluster app_data de region-A tiene las tablas de region-A; el cluster app_data de region-B tiene las de region-B. El código de la aplicación se conecta vía una variable de entorno DATABASE_URL_REGIONAL que se resuelve en boot, el binario es idéntico entre regiones, solo el env apunta a otro lado.
Por un período transicional, la base regional puede vivir como una base lógica adentro del cluster central. La app no se entera. Mismo nombre, mismo schema, misma forma de connection string. Cuando el tráfico justifica un cluster regional dedicado, lo provisionás, cambiás la env var, y el binario de la aplicación no cambia.
Eso es el leverage. El split vive en la topología y el IAM, no en el código de la aplicación. Splitear después no requiere refactor.
Lo que cuesta
Escribís composiciones de Terraform que instancian el mismo módulo regional varias veces, cada una apuntando a un alias distinto del provider AWS. El módulo en sí no le importa en qué región está, la región es una variable de entrada. La composición decide.
Pensás más al principio sobre qué es central y qué es regional. Algunos llamados son obvios (auth = central, media = regional). Otros no (¿analytics? ¿caching? ¿tagging?). El default para casos ambiguos es regional, pasar de regional a central después es más difícil que al revés, porque regional significa que la data tiene afinidad regional, y unificar data región-afín en una tabla central es destructivo de una manera que regionalizar data central no es.
Aceptás que central es un single point of failure para operaciones cross-región. O lo corrés en alta disponibilidad (multi-AZ adentro de la región primaria, failover automático) o aceptás que algunos flows del producto pausan brevemente durante incidentes centrales.
Lo que te da
Un deployment multi-región que suma regiones barato. Sumar eu es una entrada en una composición de Terraform, un set de parámetros SSM, una distribución de CDN siguiendo el patrón regional. No un fork del stack entero con todas sus variables para duplicar.
Una respuesta clara a "dónde vive esta data". Si es central, en cualquier lado. Si es regional, en la región del cliente. Si es global, es la misma en todos lados.
Un control plane que no está gateado por la carga regional. La identidad sigue rápida aunque una base regional esté bajo presión. El billing sigue reconciliando.
Cuándo es overkill
Productos single-región. Si no sos multi-región, tenés un solo regional. No pre-construyas el split central/regional para un futuro que capaz nunca llega. El split vale la pena cuando tu topología está forzando la pregunta. Hasta entonces, monolito. La migración es finita cuando la pregunta llega; el costo de mantenimiento de un split prematuro es para siempre.
Lo que sobrevive a la migración
Cuando hagas el split, ya sea que pasás de una región a dos, o de un monolito a capas, el movimiento que importa es nombrar el límite. "Esta data es regional. Esta data es central. Esta data es global". Una vez que eso está nombrado, el resto del trabajo es plomería.
El error que veo más seguido es equipos que multi-regionalizan la topología pero no el schema. Corren dos bases regionales que contienen toda la data, incluida la parte global. Después se pasan un año reconciliando entre ellas. El split tiene que aterrizar en la capa de data, no solo en la capa de deployment.
Elegí el límite, codificalo en el schema, y dejá que la topología siga.