🌐Arquitectura de red para Multi-Región en AWS: latencia, failover y coste.

🧠 Introducción

La mayoría de arquitecturas multi-región en AWS fallan por tres razones:

Subestiman la latencia entre regiones.
Sobreestiman el valor del active-active.
Descubren demasiado tarde el impacto del tráfico cross-region en la factura.

Diseñar multi-región no es replicar infraestructura.
Es tomar decisiones sobre:

Consistencia.
Routing global.
Recuperación.
Coste operativo.

Y en la práctica, no es un problema de compute…
👉 es un problema de red y datos.

🧭 ¿Cuándo realmente necesitas Multi-Region?
Primero, rompamos un mito:

Multi-AZ no es Multi-Region.

Muchas aplicaciones empresariales:

Cumplen SLA con Multi-AZ
Usan backups cross-region
No necesitan más complejidad

Multi-Region tiene sentido cuando:

Necesitas RTO cercano a cero
Tienes usuarios distribuidos globalmente
Hay requisitos regulatorios/geográficos
El downtime tiene impacto crítico en el negocio

👉 Si no tienes estos requisitos, probablemente no necesitas multi-región.

🌐 El verdadero desafío: la red
Cuando pasas a multi-región, aparecen problemas reales:
🔹 Latencia

RTT entre regiones: 50–200 ms
Impacta replicación, APIs y UX

🔹 Replicación de datos

Síncrona → prácticamente inviable
Asíncrona → introduce lag

🔹 DNS y routing

Failover dependiente de TTL
Nunca es instantáneo

🔹 Coste de red

Tráfico inter-región = $$$
Principal driver oculto de coste

👉 Insight clave:

Multi-Region es más un problema de red que de infraestructura.

🏗️ Patrones de arquitectura Multi-Region

🔵 Active-Passive (recomendado en la mayoría de casos)
Incluye:

Backup & Restore
Pilot Light
Warm Standby

✅ Ventajas:

Menor coste
Menor complejidad
Más fácil de operar

❌ Desventajas:

Mayor RTO
Requiere automatización de failover

👉 Ideal cuando el negocio tolera minutos de recuperación.

🟣 Active-Active
Ambas regiones sirven tráfico simultáneamente.

✅ Ventajas:

Latencia global baja
RTO cercano a cero

❌ Desventajas:

Complejidad extrema
Consistencia distribuida
Coste elevado

👉 Realidad:

Muchas arquitecturas active-active están sobredimensionadas para el problema que resuelven.

Y más importante:

Active-Active sin estrategia de consistencia no es resiliencia, es incertidumbre distribuida.

🌍 Routing Global: dónde se gana o se pierde la arquitectura
🔹 Route 53

Failover → DR
Latency-based → apps globales
Weighted → migraciones

🔹 AWS Global Accelerator

Anycast sobre backbone AWS
Failover rápido (<30s)
Ideal para TCP/UDP críticos

🔹 CloudFront

Edge caching (600+ PoPs)
Reduce necesidad de multi-región en muchos casos

👉 Insight senior:

Muchas arquitecturas multi-región deberían empezar por CloudFront, no por replicar regiones.

💡 El "Secreto" del Failover de <30s: Anycast vs. Caché DNS

Muchos arquitectos asumen que Route 53 y AWS Global Accelerator hacen lo mismo porque ambos manejan routing basado en latencia o failover. Error grave de diseño.

El problema de Route 53: Depende de registros DNS y del TTL (Time to Live). Si cambias el registro para apuntar a la región secundaria, tienes que esperar a que los resolvers de los ISPs del cliente borren su caché. Si un ISP ignora tu TTL bajo (lo cual pasa constantemente en producción), tus usuarios seguirán intentando ir a la región caída.

La ventaja de Global Accelerator: Te da 2 IPs estáticas Anycast globales. El tráfico entra a la red troncal de AWS en el Edge Location más cercano al usuario. Si una región falla, Global Accelerator desvía el tráfico a nivel de capa de transporte (TCP/UDP proxy) dentro de la propia red de AWS, redirigiéndolo instantáneamente a los ALBs saludables de la otra región. El cliente nunca cambia de IP, por ende, el caché del DNS no importa.

💸 Coste real de Multi-Región

Aquí es donde muchas arquitecturas fallan.
Costes ocultos:

Tráfico inter-región ($0.02–0.08/GB)
Replicación de bases de datos
Infraestructura duplicada
NAT Gateway por región
Health checks + observabilidad
Entornos idle (warm standby)

👉 Ejemplo real:

En una arquitectura LATAM, el tráfico inter-región incrementó el coste total en ~34% sin mejorar la latencia percibida significativamente.

👉 Conclusión:

Estrategias Multi-región ("con > 500 GB/mes de tráfico inter-región") mal diseñadas, pueden ser 3x–4x veces más costosas.

🧠 Estrategias de datos (el verdadero problema)

El compute escala fácil.
Los datos, no.

🔹 Comparativa rápida

_"Aurora parece 'peor' por el failover manual, pero su lag <1s la hace más predecible para cargas transaccionales que DynamoDB con escrituras concurrentes en ambas regiones."
_
Problemas reales:

Conflictos de escritura
Lag de replicación
Datos inconsistentes entre regiones

Cuando duplicas tu infraestructura en otra región para failover, la red es el problema fácil; el verdadero reto son tus bases de datos. Aquí hay dos patrones claros y sus trade-offs reales en AWS:

Active-Active con DynamoDB Global Tables: Proporciona replicación totalmente administrada con latencias de replicación típicamente sub-segundo. Sin embargo, opera bajo el modelo de consistencia eventual. Si tienes escrituras concurrentes en ambas regiones sobre el mismo ítem, aplica la regla Last-Writer-Wins. Si tu aplicación no es idempotente, vas a corromper datos de negocio.
Active-Passive con Aurora Global Database: Replica los datos a nivel del storage cluster físico con un lag menor a 1 segundo sin impactar el performance de la base de datos principal. Es ideal para estrategias de Warm Standby, pero ten en cuenta el RTO: en caso de failover, tu plano de control o aplicación debe promover explícitamente el clúster secundario a modo de Lectura/Escritura, lo que requiere automatización (vía AWS SDK o EventBridge).

🚨 Errores comunes (basado en producción)

TTL DNS demasiado alto
No probar el failover
Asumir que Multi-AZ es suficiente para DR
Ignorar replication lag
Diseñar active-active “por moda”
No definir RTO/RPO con negocio

👉 El peor:

Diseñar multi-región sin entender la operación diaria.

🚫 Anti-patterns que veo frecuentemente

Active-Active con bases de datos sin estrategia de conflicto.
Failover DNS con TTL > 300s.
Replicación global “porque sí”.
NAT Gateway como bottleneck multi-región.
Endpoints Regionales Hardcodeados.
Split-Brain por Health Checks Invertidos.

"Split-Brain por Health Checks Invertidos: si configuras un health check que marca la región secundaria como unhealthy cuando la primaria está caída (por dependencia cruzada), ambas regiones se desactivan simultáneamente. He visto esto en producción con Route 53 y ALBs que hacen health check a endpoints cross-region."

📈 Evolución recomendada
La mayoría de workloads deberían avanzar así: