ADR: Cognito Multi-Região para Autenticação Resiliente

Durante anos, o Amazon Cognito operou como um serviço regional sem mecanismo nativo de replicação de User Pools entre regiões. A estratégia de resiliência disponível era essencialmente manual: manter um segundo User Pool em outra região com usuários pré-provisionados via exportação/importação periódica, gerenciar o failover por DNS e aceitar que senhas não podiam ser replicadas (Cognito armazena apenas hashes com salt por usuário, não exportáveis). Isso criava uma janela de inconsistência estrutural, qualquer usuário criado ou que alterou senha após a última sincronização simplesmente não conseguiria autenticar na região secundária.

O incidente que gerou este ADR durou 47 minutos em us-east-1. Durante esse período, 100% dos fluxos de login falharam. Fluxos de refresh de token que dependiam de validação online também falharam para clientes que não tinham tokens válidos em cache. O impacto foi amplificado porque a plataforma serve tanto consumidores B2C quanto operadores B2B, para esses últimos, a indisponibilidade de login bloqueou operações críticas de negócio, não apenas conveniência.

As forças que moldaram a decisão foram: (1) SLA contratual de 99,99% que matematicamente não tolera incidentes regionais sem failover automático; (2) natureza do dado de identidade: senhas, MFA seeds e atributos de usuário são dados de alta sensibilidade que exigem controle rigoroso sobre onde e como são replicados; (3) complexidade de sessão: tokens JWT emitidos pela região primária precisam ser validáveis na secundária sem reemissão forçada; (4) domínios customizados: auth.example.com é resolvido por um CloudFront distribution gerenciado pelo Cognito, e o failover de DNS precisa ser coordenado sem quebrar o fluxo PKCE/redirect_uri dos clientes OAuth; (5) custo e complexidade operacional: manter dois User Pools sincronizados manualmente é frágil e caro em engenharia.

Um aspecto que frequentemente é subestimado em discussões sobre Cognito multi-região é o papel das chaves KMS. Quando você configura um User Pool com uma chave KMS gerenciada pelo cliente (CMK) para criptografar atributos sensíveis ou para assinar tokens avançados, essa chave é regional por padrão. Se o User Pool secundário usa uma CMK diferente, ou se a chave primária não está acessível na região secundária, qualquer dado criptografado com a chave primária se torna ilegível no failover.

A solução correta é usar KMS Multi-Region Keys (MRKs), disponíveis desde 2021. Uma MRK permite que a mesma chave lógica (mesmo key ID) exista em múltiplas regiões AWS, com material de chave sincronizado pela AWS. Isso significa que dados criptografados em us-east-1 com a MRK podem ser decriptados em us-west-2 com a réplica da mesma MRK, sem exportação de material de chave, mantendo o modelo de segurança do HSM. Para este cenário, configuramos MRKs em ambas as regiões e associamos cada User Pool à réplica regional correspondente.

Quanto aos tokens JWT: tokens emitidos pelo Cognito são assinados com chaves RSA gerenciadas internamente pelo serviço (expostas via JWKS endpoint). Com a replicação nativa multi-região do Cognito, o User Pool secundário compartilha o mesmo issuer (iss claim) e as mesmas chaves de assinatura do primário, o que é fundamental. Sem isso, um token emitido pelo User Pool primário seria rejeitado por qualquer validador que buscasse o JWKS do secundário, porque as chaves seriam diferentes. A replicação nativa resolve esse problema estruturalmente. Em arquiteturas manuais (dois User Pools independentes), esse problema não tem solução limpa: ou você força relogin no failover, ou implementa um proxy de validação que tenta ambos os JWKS endpoints, ambas as opções têm custo de experiência do usuário ou complexidade operacional significativos.

O domínio customizado é um dos aspectos mais delicados do failover do Cognito. Quando você configura auth.example.com como domínio customizado de um User Pool, o Cognito provisiona uma CloudFront distribution gerenciada pelo serviço e associa seu certificado ACM a ela. Esse certificado precisa estar na região us-east-1 independentemente de onde o User Pool está, porque CloudFront é global e valida certificados apenas de us-east-1. Na região secundária (us-west-2), você precisa de um segundo certificado ACM em us-east-1 (ou usar o mesmo, se o domínio for idêntico) e configurar um segundo domínio customizado no User Pool secundário.

A estratégia de failover de DNS que adotamos usa Route 53 com dois registros CNAME ponderados (weight 100/0 em operação normal) apontando para as CloudFront distributions de cada região. O Route 53 ARC monitora health checks contra o endpoint /oauth2/token de cada região. Quando o health check da primária falha por 3 períodos consecutivos de 10 segundos, o ARC executa o failover automaticamente, alterando o peso para 0/100. O TTL dos registros é configurado em 60 segundos, um trade-off consciente entre velocidade de failover e carga de resolução DNS.

Para a experiência do cliente, o impacto mais visível no failover é para usuários no meio de um fluxo de autorização (redirect OAuth em andamento). Esses fluxos são stateless do ponto de vista do Cognito, mas o state parameter e o code_verifier (PKCE) estão no cliente, então o redirect para a URL de callback funciona normalmente mesmo após o failover, desde que o redirect_uri esteja registrado no User Pool secundário. Isso exige que a lista de redirect_uris seja mantida idêntica em ambos os User Pools, um item de checklist operacional que precisa ser automatizado via IaC para evitar drift.