Activo-activo en varias ubicaciones con Global Tables y Route 53

Multi-Site Active-Active es el nivel más alto de recuperación ante desastres, en el que la aplicación se ejecuta a plena capacidad de producción en dos o más regiones de AWS simultáneamente. A diferencia de una configuración activa-pasiva, en la que un entorno en espera aguarda para tomar el control, en una configuración activa-activa ambas regiones atienden tráfico real de usuarios en todo momento. Cuando una región falla, la otra absorbe inmediatamente el 100 % del tráfico, sin retraso de failover. Este patrón también reduce la latencia para los usuarios distribuidos globalmente, ya que les atiende desde la región más cercana.

DynamoDB Global Tables es la base de datos de las arquitecturas activa-activa. Global Tables permite la replicación multi-primary y multirregional: las aplicaciones de cualquier región pueden leer y escribir en una tabla local de DynamoDB, y los cambios se replican en las demás regiones en aproximadamente 1 segundo. Para habilitar Global Tables, debe especificar en qué regiones debe existir la tabla. AWS gestiona automáticamente toda la replicación, la resolución de conflictos (gana la última escritura) y el failover.

Aurora Global Database proporciona lecturas activas-activa, pero escrituras activas-pasivas. Todas las regiones secundarias atienden lecturas con una latencia de replicación inferior a 1 segundo, mientras que solo la región primaria acepta escrituras. Esta opción es ideal para aplicaciones con muchas lecturas que desean lecturas de baja latencia a nivel global y una región primaria de escritura claramente definida. Durante un fallo regional de la región primaria, puede promover una secundaria a primaria en menos de 1 minuto y conseguir un RTO bajo para la capa de escritura. Compárelo con DynamoDB Global Tables, que admite escrituras activa-activa en todas las regiones.

Route 53 dirige el tráfico en las arquitecturas activa-activa multirregionales. Utilice el enrutamiento basado en latencia para enviar a cada usuario a la región con la menor latencia de red desde su ubicación. Asocie comprobaciones de estado a cada registro regional: cuando una región no supera su comprobación de estado, Route 53 la elimina automáticamente de las respuestas DNS y envía todo el tráfico a las regiones saludables restantes. Configure el TTL en 60 segundos o menos para minimizar el tiempo que tardan los usuarios en cambiar a la región saludable.

Cuando una región falla en una configuración activa-activa, la región superviviente debe gestionar el doble de su tráfico normal (o incluso más). Su Auto Scaling Group debe tener una capacidad máxima suficiente y políticas de escalado horizontal que reaccionen con rapidez. Configure el escalado basado en seguimiento de objetivos según el recuento de solicitudes del ALB por destino, de modo que el ASG añada instancias automáticamente cuando el tráfico se duplique. Considere también el precalentamiento: durante los simulacros de failover, observe con qué rapidez escala horizontalmente su ASG y asegúrese de que pueda alcanzar la capacidad necesaria dentro del objetivo de RTO.

En una arquitectura de una sola región, las sesiones de los usuarios pueden almacenarse localmente en los servidores de aplicaciones. En una arquitectura activa-activa multirregional, los usuarios pueden alternar entre regiones en solicitudes posteriores, lo que interrumpe las sesiones del lado del servidor. Soluciones: 1) Sesiones sin estado: almacene los datos de sesión en un JWT firmado o una cookie que cualquier servidor de cualquier región pueda validar. 2) DynamoDB Global Tables para sesiones: almacene las sesiones de forma centralizada, con acceso en milisegundos desde cualquier región. 3) ElastiCache con Global Datastore: replique Redis entre regiones para almacenar las sesiones.

El mayor desafío de una arquitectura activa-activa con escrituras multi-primary son los conflictos de escritura. Si dos usuarios de regiones diferentes actualizan simultáneamente el mismo registro, ¿qué actualización prevalece? DynamoDB Global Tables utiliza el criterio de gana la última escritura, según la marca de tiempo de la escritura. Esto funciona bien en la mayoría de los casos de uso, pero puede provocar la pérdida de datos en actualizaciones simultáneas (por ejemplo, si dos usuarios incrementan un contador al mismo tiempo). Diseñe el modelo de datos para evitar escrituras simultáneas en el mismo elemento desde distintas regiones mediante escrituras condicionales o asignando la propiedad de los datos por región.

Para el almacenamiento de objetos en una arquitectura activa-activa, utilice S3 Cross-Region Replication con replicación bidireccional (disponible en buckets con el versionado habilitado). A diferencia de la CRR unidireccional, la replicación bidireccional mantiene sincronizados los buckets de ambas regiones: los objetos escritos en cualquiera de las regiones se replican automáticamente en la otra. Esto es fundamental para las aplicaciones que escriben archivos cargados por los usuarios en el bucket de S3 de su región local, pero necesitan que esos archivos sean accesibles globalmente. Habilite Replication Time Control (RTC) de S3 para garantizar que el 99,99 % de los objetos se replique en un plazo de 15 minutos.

Utilice CloudFront con grupos de orígenes para crear una CDN activa-activa con failover automático. Configure un origen primario (ALB en us-east-1) y un origen secundario (ALB en eu-west-1). CloudFront cambia automáticamente al origen secundario cuando el origen primario devuelve errores 5xx. Para los recursos estáticos servidos desde S3, configure grupos de orígenes que apunten a buckets de S3 en varias regiones con replicación bidireccional. Esto añade una capa de resiliencia a nivel de CDN sobre el enrutamiento activa-activa de Route 53.

Las arquitecturas activa-activa requieren una supervisión sólida para garantizar que ambas regiones estén saludables y que el tráfico se distribuya según lo previsto. Métricas clave: Route 53 HealthCheckPercentageHealthy por región, DynamoDB ReplicationLatency para la latencia de Global Tables, ALB RequestCount por región para verificar la distribución del tráfico y CloudWatch cross-account/cross-region dashboards para obtener una vista unificada. Configure alarmas cuando la latencia de replicación supere su umbral de RPO o cuando la distribución del tráfico se desequilibre considerablemente.

Active-Active es adecuado cuando: los usuarios están distribuidos globalmente y la latencia hacia una única región resulta inaceptable. El RTO debe ser prácticamente cero: el negocio no puede tolerar ni siquiera unos minutos de interrupción. Un alto rendimiento de escritura requiere distribuir las escrituras entre regiones. Los requisitos normativos exigen procesar los datos dentro del país. El coste es considerablemente mayor que el de otros niveles de DR, por lo que solo debe elegir Active-Active cuando los requisitos del negocio y los aspectos económicos lo justifiquen claramente. Para muchas cargas de trabajo, Warm Standby es suficiente y mucho más económico.

Compruebe sus conocimientos sobre los conceptos de AWS Solutions Architect (SAA-C03) tratados en esta lección.

En esta lección ha aprendido que DynamoDB Global Tables permite escrituras multi-primary entre regiones para lograr una verdadera configuración activa-activa, que el enrutamiento por latencia de Route 53, junto con las comprobaciones de estado, dirige a los usuarios a la región saludable más cercana y que la gestión de sesiones debe ser sin estado o utilizar almacenamiento replicado globalmente en una arquitectura activa-activa. Active-Active ofrece un RTO y un RPO prácticamente nulos, pero con un coste considerablemente mayor. A continuación, exploraremos los pilares de Excelencia operativa y Seguridad del Well-Architected Framework.