Ativo-ativo em vários locais com Global Tables e Route 53

Multi-Site Active-Active é o nível mais alto de recuperação de desastres, no qual sua aplicação é executada em capacidade total de produção em duas ou mais regiões da AWS simultaneamente. Diferentemente do modo ativo-passivo, em que uma instância de espera aguarda para assumir o controle, no modo ativo-ativo as duas regiões atendem ao tráfego real dos usuários o tempo todo. Quando uma região falha, a outra absorve imediatamente 100% do tráfego, sem atraso de failover. Esse padrão também reduz a latência para usuários distribuídos globalmente, atendendo-os a partir da região mais próxima.

DynamoDB Global Tables é a base de dados das arquiteturas ativas-ativas. O Global Tables permite a replicação multi-master e entre várias regiões — as aplicações em qualquer região podem ler e Write em uma tabela local do DynamoDB, e as alterações são replicadas para todas as outras regiões em aproximadamente 1 segundo. Você habilita o Global Tables especificando em quais regiões a tabela deve existir. A AWS gerencia automaticamente toda a replicação, a resolução de conflitos (a última gravação vence) e o failover.

Aurora Global Database oferece leituras ativas-ativas, mas gravações ativas-passivas. Todas as regiões secundárias atendem às leituras com atraso de replicação inferior a 1 segundo, enquanto apenas a região Primary aceita gravações. Essa solução é ideal para aplicações com muitas leituras que desejam leituras de baixa latência globalmente e uma região Primary definida para gravações. Durante uma falha regional da região Primary, você pode promover uma região secundária a Primary em menos de 1 minuto, obtendo um RTO baixo para a camada de gravação. Compare essa solução com o DynamoDB Global Tables, que oferece gravações ativas-ativas em todas as regiões.

O Route 53 é o diretor de tráfego das arquiteturas Multi-Site Active-Active. Use o roteamento baseado em latência para enviar cada usuário à região com a menor latência de rede a partir de sua localização. Anexe verificações de integridade a cada registro regional — quando uma região falha na verificação de integridade, o Route 53 a remove automaticamente das respostas DNS, enviando todo o tráfego para as regiões saudáveis restantes. Defina o TTL do DNS como 60 segundos ou menos para minimizar o tempo necessário para que os usuários façam failover para a região saudável.

Quando uma região falha em uma configuração ativa-ativa, a região sobrevivente precisa lidar com o dobro (ou mais) do tráfego normal. Seu grupo de Auto Scaling deve ter capacidade máxima suficiente e políticas de expansão que reajam rapidamente. Configure a escalabilidade com rastreamento do destino com base na contagem de solicitações do ALB por destino, para que o ASG adicione instâncias automaticamente à medida que o tráfego dobra. Considere também o pré-aquecimento: durante os exercícios de failover, observe a rapidez com que seu ASG aumenta a capacidade e certifique-se de que ele consiga atingir a capacidade necessária dentro da meta de RTO.

Em uma arquitetura de região única, as sessões dos usuários podem ser armazenadas localmente nos servidores da aplicação. Em uma arquitetura ativa-ativa com várias regiões, os usuários podem alternar entre regiões em solicitações subsequentes, interrompendo as sessões mantidas no servidor. Soluções: 1) sessões sem estado — armazene os dados da sessão em um JWT assinado ou cookie que qualquer servidor, em qualquer região, possa validar. 2) DynamoDB Global Tables para sessões — armazene as sessões centralmente, com acesso em milissegundos a partir de qualquer região. 3) ElastiCache com Global Datastore — use a replicação do Redis entre regiões para armazenar as sessões.

O maior desafio das gravações multi-master em uma arquitetura ativa-ativa são os conflitos de gravação. Se dois usuários em regiões diferentes atualizarem o mesmo registro simultaneamente, qual atualização deverá prevalecer? O DynamoDB Global Tables usa a regra de que a última gravação vence, com base no carimbo de data e hora da gravação. Isso funciona bem na maioria dos casos de uso, mas pode causar perda de dados em atualizações concorrentes (por exemplo, quando dois usuários incrementam simultaneamente um contador). Projete seu modelo de dados para evitar gravações simultâneas no mesmo item por regiões diferentes, usando gravações condicionais ou particionando a propriedade dos dados por região.

Para armazenamento de objetos em uma arquitetura ativa-ativa, use a replicação entre regiões do S3 com replicação bidirecional (disponível em buckets com versionamento habilitado). Diferentemente da CRR unidirecional, a replicação bidirecional mantém os buckets de ambas as regiões sincronizados — os objetos gravados em qualquer região são replicados automaticamente para a outra. Isso é essencial para aplicações que gravam arquivos enviados pelos usuários no bucket S3 da região local, mas precisam que esses arquivos sejam acessíveis globalmente. Habilite o Replication Time Control (RTC) do S3 para garantir que 99,99% dos objetos sejam replicados em até 15 minutos.

Use o CloudFront com grupos de origem para criar uma CDN ativa-ativa com failover automático. Configure uma origem Primary (ALB em us-east-1) e uma origem Secondary (ALB em eu-west-1). O CloudFront fará failover automaticamente para a origem Secondary quando a origem Primary retornar erros 5xx. Para ativos estáticos fornecidos pelo S3, configure grupos de origem apontando para buckets do S3 em várias regiões, com replicação bidirecional. Isso adiciona uma camada de resiliência no nível da CDN sobre o roteamento ativo-ativo do Route 53.

As arquiteturas ativas-ativas exigem um monitoramento robusto para garantir que ambas as regiões estejam saudáveis e que o tráfego esteja equilibrado conforme o esperado. Principais métricas: Route 53 HealthCheckPercentageHealthy por região, DynamoDB ReplicationLatency para o atraso do Global Tables, ALB RequestCount por região para verificar a distribuição do tráfego e painéis do CloudWatch entre contas e regiões para uma visão unificada. Configure alarmes quando o atraso de replicação exceder seu limite de RPO ou quando a distribuição do tráfego ficar muito desequilibrada.

O modo ativo-ativo é apropriado quando: os usuários estão distribuídos globalmente e a latência até uma única região é inaceitável. O RTO precisa ser quase zero — a empresa não pode tolerar nem mesmo alguns minutos de indisponibilidade. Um alto volume de gravações exige a distribuição das gravações entre regiões. Requisitos regulatórios exigem o processamento de dados dentro do país. O custo é substancialmente maior que o de outros níveis de DR; portanto, escolha o modo ativo-ativo somente quando os requisitos comerciais e a economia justificarem claramente essa decisão. Para muitas cargas de trabalho, Warm Standby é suficiente e muito mais barato.

Teste sua compreensão dos conceitos de AWS Solutions Architect (SAA-C03) abordados nesta lição.

Nesta lição, você aprendeu que: DynamoDB Global Tables permite gravações multi-master entre regiões para um verdadeiro modo ativo-ativo; o roteamento por latência do Route 53, combinado com verificações de integridade, direciona os usuários para a região saudável mais próxima; e o gerenciamento de sessões precisa ser sem estado ou usar armazenamento replicado globalmente em uma arquitetura ativa-ativa. O modo ativo-ativo oferece RTO e RPO quase nulos, mas com um custo significativamente maior. A seguir, exploraremos os pilares Operational Excellence e Security do Well-Architected Framework.