Cognito Multi-Region: Migrando Identidade para Alta Disponibilidade

Em sistemas financeiros, o Cognito User Pool carrega muito mais do que credenciais. Ele armazena atributos customizados que mapeiam para perfis de risco, grupos que controlam escopos de autorização downstream, e triggers Lambda que executam lógica de negócio, validação de CPF, enriquecimento de claims com dados de compliance, logging de auditoria para BACEN/LGPD. Quando esse pool falha em uma Região, o impacto não é apenas "usuários não conseguem logar": toda a cadeia de autorização quebra, APIs protegidas por Cognito Authorizer no API Gateway retornam 401, e fluxos de onboarding ficam presos em estados inconsistentes.

O padrão que eu via com frequência antes da replicação nativa era uma combinação de dois pools independentes com sincronização eventual via EventBridge e Lambda, o que chamávamos internamente de "Cognito Bridge". O problema é que esse padrão tem pelo menos três pontos cegos: race conditions durante a sincronização de senha (o hash bcrypt muda a cada reset), atributos customizados que divergem silenciosamente entre regiões, e triggers Lambda que precisam ser mantidos em sincronia manual. O custo operacional era alto e a confiança na consistência era baixa. A replicação nativa resolve exatamente essa camada de complexidade acidental.

A arquitetura alvo que emerge dessa migração tem três camadas distintas. A primeira é o plano de dados de identidade: Cognito User Pool primário em us-east-1 com réplica ativa em us-west-2, ambos usando a mesma MRK do KMS, com replicação síncrona de usuários, grupos e credenciais gerenciada pelo serviço. A segunda é o plano de execução de triggers: funções Lambda espelhadas em ambas as regiões, com acesso a DynamoDB Global Tables (configuradas com tabelas em ambas as regiões e replicação automática), Secrets Manager com replicação de secrets habilitada, e RDS Proxy apontando para Aurora Global Database com réplica de leitura promovível.

A terceira camada, frequentemente negligenciada, é o plano de observabilidade de identidade. Métricas críticas a monitorar em ambas as regiões: SignInSuccesses, SignInThrottles, TokenRefreshSuccesses, e o custom metric IdentityPlaneRPO que mede o lag de replicação em segundos. Esse último deve ter um SLO de < 30 segundos de RPO em condições normais, com alarme em 60 segundos e PagerDuty em 120 segundos. A observabilidade cross-region é implementada via CloudWatch Cross-Account Cross-Region dashboards, um único painel que agrega métricas de identidade de ambas as regiões, com anotações automáticas quando failover é detectado.

Um detalhe que frequentemente escapa nas discussões de migração multi-Region do Cognito é o comportamento dos tokens JWT após failover. Os tokens emitidos pelo pool primário são assinados com a chave RSA do pool primário, o JWKS endpoint do pool primário (https://cognito-idp.<region>.amazonaws.com/<pool-id>/.well-known/jwks.json) é a fonte de verdade para validação. Após failover para a réplica, o pool de réplica tem seu próprio JWKS endpoint.

Isso cria uma janela de transição: tokens emitidos antes do failover, ainda válidos por tempo de expiração (tipicamente 1h para access tokens), precisam ser validados contra o JWKS do pool primário, que pode estar indisponível exatamente porque estamos em failover. A solução correta é implementar validação de token com cache de JWKS em múltiplas camadas: o Lambda Authorizer do API Gateway deve cachear as chaves públicas de ambas as regiões e tentar validação contra ambos os JWKS antes de rejeitar o token. O cache deve ter TTL de 10 minutos com refresh assíncrono, nunca buscar o JWKS em tempo de requisição, pois isso cria dependência síncrona cross-region.

Para sistemas que usam tokens de longa duração (refresh tokens com validade de 30 dias são comuns em mobile banking), a estratégia de replicação de tokens é ainda mais crítica. O Cognito replica refresh tokens como parte da replicação de sessão, mas o app client ID e o client secret precisam ser idênticos em ambos os pools (ou gerenciados via Secrets Manager com replicação habilitada) para que o refresh flow funcione na região secundária sem re-autenticação forçada do usuário.

Em instituições financeiras reguladas no Brasil, sujeitas a BACEN, LGPD e, para open finance, à Resolução Conjunta 1, o plano de identidade tem requisitos de governança que vão além da disponibilidade técnica. O Cognito armazena dados pessoais (nome, email, CPF em atributo customizado) e dados de autenticação, ambos classificados como dados sensíveis sob LGPD. A replicação multi-Region levanta imediatamente a questão de residência de dados: se a réplica está em us-west-2 (Oregon), dados de cidadãos brasileiros estão sendo replicados para fora do Brasil.

A resposta arquitetural para isso não é evitar a replicação, mas documentá-la adequadamente no Registro de Operações de Tratamento de Dados (ROPA) e garantir que os controles de segurança sejam equivalentes em ambas as regiões. A criptografia com KMS MRK satisfaz o requisito de que dados em repouso sejam criptografados com chaves sob controle da organização, desde que a política de chave não permita acesso por terceiros. O CloudTrail com replicação para S3 em ambas as regiões (com Object Lock para imutabilidade) garante o trail de auditoria exigido pelo BACEN para sistemas de autenticação.

Um ponto frequentemente negligenciado: o trigger Pre-Token-Generation que adiciona claims ao JWT é, na prática, uma extensão do plano de autorização. Se esse trigger falha silenciosamente (timeout, throttle de Lambda), o token é emitido sem os claims de compliance, e downstream, APIs que dependem desses claims para decisões de autorização tomam decisões incorretas. Configure TokenValidityUnits e implemente validação de claims obrigatórios no Lambda Authorizer do API Gateway como linha de defesa adicional.