# Cognito Multi-Region: Migrando Identidade para Alta Disponibilidade

Autenticação é infraestrutura crítica — uma falha regional no Cognito derruba toda a jornada do usuário. Com a replicação multi-Region do Cognito agora disponível, existe um caminho concreto para elevar o plano de identidade ao mesmo nível de resiliência que já exigimos de bancos de dados e filas. Neste artigo, documento a jornada de migração, as decisões de arquitetura e os riscos que precisam ser gerenciados ativamente.

- URL: https://fernando.moretes.com/blog/cognito-multi-region-autenticacao-resiliente

- Markdown: https://fernando.moretes.com/blog/cognito-multi-region-autenticacao-resiliente/article.md?lang=pt

- Published: 2026-05-31T11:47:00.000Z

- Category: Segurança & Resiliência

- Tags: cognito, multi-region, identity, resilience, kms, migration, financial-grade, zero-trust

- Reading time: 10 min

- Source: [Amazon Cognito multi-Region replication](https://aws.amazon.com/blogs/aws/)

---

Durante anos, aceitamos uma assimetria silenciosa em nossas arquiteturas: bancos de dados com replicação multi-Region, filas com replicação cross-Region, mas o plano de identidade — o Cognito User Pool — rodando em uma única Região, sem failover automatizado. Quando a replicação multi-Region do Amazon Cognito foi anunciada, minha primeira reação não foi entusiasmo, mas alívio: finalmente podemos fechar essa lacuna sem construir uma solução caseira frágil. A jornada para chegar lá, porém, é mais cirúrgica do que parece.

## O Ponto de Partida: Identidade como Ponto Único de Falha

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 Jornada de Migração: Seis Decisões em Sequência

1. **1. Auditoria do Pool Existente** — Antes de qualquer movimento, inventarie tudo que o pool atual carrega: atributos customizados (schema imutável após criação), grupos e suas permissões, triggers Lambda e suas dependências de VPC/IAM, app clients e seus OAuth flows, domínio customizado e certificados ACM associados. Qualquer atributo customizado não mapeado agora será uma surpresa dolorosa depois — o schema de um User Pool não pode ser alterado após a criação, então a replicação precisa partir de um pool com o schema correto.

2. **2. Estratégia de KMS Cross-Region** — A replicação multi-Region do Cognito usa KMS para criptografia de dados em repouso. A decisão crítica aqui é: KMS Multi-Region Keys (mrk-) versus chaves independentes por região. Recomendo fortemente MRKs — elas compartilham o mesmo material de chave criptográfica replicado pelo KMS entre regiões, o que significa que tokens e dados criptografados pelo pool primário podem ser descriptografados pelo pool de réplica sem re-encriptação. Com chaves independentes, você precisaria de uma camada adicional de re-wrapping que adiciona latência e complexidade. Configure a política de chave MRK para permitir apenas o principal do serviço Cognito (`cognito-idp.amazonaws.com`) com condição `aws:SourceAccount` restrita à sua conta — nunca permissão wildcard.

3. **3. Replicação do Pool e Sincronização de Schema** — Com a replicação nativa habilitada, o Cognito replica automaticamente usuários, grupos, atributos e credenciais (hashes de senha incluídos) para a região secundária. O ponto de atenção é o estado de replicação inicial: para pools com milhões de usuários, a replicação inicial pode levar horas. Durante esse período, o pool de réplica existe mas não está pronto para receber tráfego de autenticação. Monitore o CloudWatch metric `UserPoolReplicationStatus` e só mova tráfego após confirmação de sincronização completa. Configure um alarme com threshold de 0 em `ReplicationLag` antes de qualquer teste de failover.

4. **4. Lambda Triggers: O Problema Mais Subestimado** — Lambda triggers associados ao pool primário não são replicados automaticamente — eles precisam existir na região secundária com a mesma lógica e as mesmas dependências. Isso significa: funções Lambda deployadas na região secundária, permissões de resource-based policy atualizadas para o pool de réplica, e variáveis de ambiente que apontam para endpoints regionais (DynamoDB, Secrets Manager, RDS Proxy) corretamente configuradas para a região secundária. Um trigger de Pre-Token-Generation que enriquece claims com dados de um DynamoDB Global Table deve apontar para o endpoint regional correto — não para o endpoint da região primária, o que criaria dependência cross-region e anularia o benefício do failover.

5. **5. Roteamento com Route 53 e Health Checks** — O Cognito expõe endpoints regionais distintos para o pool primário e a réplica. A estratégia de roteamento que recomendo é Route 53 com Failover Routing Policy: o registro primário aponta para o endpoint Cognito da região principal, com um health check ativo que monitora `https://<domain>.auth.<region>.amazoncognito.com/health`. O TTL deve ser 60 segundos — não menos, para evitar flood de DNS, não mais, para garantir failover rápido. Para aplicações que usam o Cognito SDK diretamente (não via domínio customizado), é necessário uma camada de abstração — um API Gateway regional com Lambda proxy que resolve o endpoint correto baseado em lógica de health check, ou uso do AWS Global Accelerator para endpoints customizados.

6. **6. Teste de Failover e Runbook Operacional** — Failover não testado é failover que não existe. O teste deve simular falha real: bloqueie o tráfego para a região primária via Security Group ou NACLs, observe o health check do Route 53 falhar (tipicamente 3 checks consecutivos com intervalo de 10s = 30s de detecção), e meça o tempo até o primeiro login bem-sucedido na região secundária. Documente no runbook: o ARN do pool de réplica, as credenciais de app client na região secundária, o procedimento para promover a réplica a primária se necessário, e o processo de re-sincronização após recuperação da região primária. Esse runbook deve ser executado em GameDay trimestral — não apenas revisado.

## Arquitetura Alvo: O Plano de Identidade Resiliente

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.

## Arquitetura de Identidade Multi-Region com Cognito

Fluxo de autenticação ativo-ativo com failover automático via Route 53, replicação de identidade Cognito, triggers Lambda espelhados e observabilidade unificada.

### 🌐 DNS & Routing

- Route 53 Failover Policy TTL=60s (network)
- Health Check /health endpoint (network)

### 🟧 AWS — us-east-1 (Primary)

- Cognito User Pool Primary (mrk-kms-1) (security)
- Lambda Triggers Pre-Token / Pre-Auth (compute)
- DynamoDB Global Table (us-east-1) (data)
- API Gateway Cognito Authorizer (edge)

### 🟦 AWS — us-west-2 (Replica)

- Cognito User Pool Replica (mrk-kms-1) (security)
- Lambda Triggers Mirrored (regional env vars) (compute)
- DynamoDB Global Table (us-west-2) (data)
- API Gateway Cognito Authorizer (edge)

### 🔐 Security & Key Management

- KMS Multi-Region Key mrk- shared material (security)

### 📊 Observability

- CloudWatch Cross-Region Dashboard (ai)

### Fluxos

- client -> r53: Requisição DNS
- r53 -> hc: Monitora saúde
- r53 -> cognito_p: Rota primária
- r53 -> cognito_r: Failover automático
- cognito_p -> cognito_r: Replicação nativa
- cognito_p -> lambda_p: Trigger invocation
- cognito_r -> lambda_r: Trigger invocation
- lambda_p -> ddb_p: Leitura regional
- lambda_r -> ddb_r: Leitura regional
- ddb_p -> ddb_r: Global Table sync
- cognito_p -> mrk: Encrypt/Decrypt
- cognito_r -> mrk: Encrypt/Decrypt
- cognito_p -> apigw_p: Token validation
- cognito_r -> apigw_r: Token validation
- cognito_p -> cw: Métricas + RPO lag
- cognito_r -> cw: Métricas + RPO lag

## Antes e Depois: Impacto Mensurável da Migração

- **~4h → <2min** — RTO de Autenticação. De restauração manual de pool (export/import de usuários) para failover automático via Route 53 com health check de 30s
- **~24h → <30s** — RPO de Dados de Identidade. De backups diários do pool (último snapshot) para replicação síncrona contínua com lag monitorado em tempo real
- **~40% redução** — Custo Operacional de Identidade. Eliminação do Cognito Bridge (4 Lambdas + EventBridge + DLQ + runbooks de reconciliação) substituído por replicação nativa gerenciada

## Tokens JWT e o Problema da Validação Cross-Region

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.

> **Riscos Críticos que Precisam de Gestão Ativa:** **1. Schema imutável:** O schema de atributos customizados de um User Pool não pode ser alterado após criação. Se o pool primário tem atributos legados mal nomeados ou com tipos incorretos, a réplica herda esses problemas. Corrija o schema antes de habilitar replicação — o que pode exigir uma migração de pool completa como pré-requisito.

**2. App Clients não replicados automaticamente:** App clients (client IDs e secrets) precisam ser recriados manualmente na réplica ou via IaC (CloudFormation/Terraform). Um app client ausente na réplica significa que o fluxo OAuth falha silenciosamente após failover — sem erro claro, apenas 401.

**3. Domínio customizado e certificados ACM:** O domínio customizado do Cognito (`auth.empresa.com`) precisa de um certificado ACM em `us-east-1` (requisito do Cognito para domínios customizados) mesmo que a réplica esteja em outra região. Isso é um requisito de serviço que não muda com a replicação multi-Region.

**4. Limites de taxa por região:** O Cognito tem quotas de taxa de requisição por região (ex: 120 RPS para `InitiateAuth` por padrão). Em um cenário de failover, 100% do tráfego de autenticação vai para a região secundária — verifique se a quota está ajustada via Service Quotas antes do failover, não durante.

## Governança, Compliance e o Plano de Identidade em Sistemas Regulados

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.

## Estratégias de Resiliência de Identidade: Comparação
| Critério | Critério | Cognito Bridge (Homegrown) | Replicação Nativa Multi-Region | Pool Independente + Sync Manual |
| --- | --- | --- | --- | --- |
| RTO | 5-15 min (propagação EventBridge) | < 2 min (Route 53 health check) | 30-60 min (processo manual) | — |
| RPO | Minutos (lag eventual) | < 30s (replicação síncrona) | Horas (último sync manual) | — |
| Complexidade Operacional | Alta (4+ Lambdas, DLQ, reconciliação) | Baixa (gerenciado pelo serviço) | Muito Alta (runbooks extensos) | — |
| Consistência de Senha | Race condition em resets | Garantida (hash replicado) | Não garantida | — |
| Custo Adicional | ~$200-500/mês (infra de sync) | ~$50-150/mês (pool réplica + KMS MRK) | Custo de engenharia dominante | — |

## Alinhamento com AWS Well-Architected Framework

- **security**: KMS Multi-Region Keys com política restrita por `aws:SourceAccount` e `aws:SourceService`. Nenhum dado de identidade em trânsito sem TLS 1.2+. CloudTrail habilitado em ambas as regiões com S3 Object Lock para imutabilidade de auditoria. Lambda triggers com IAM roles de menor privilégio e VPC endpoints para acesso a DynamoDB e Secrets Manager.
- **reliability**: Replicação multi-Region elimina o SPOF do plano de identidade. RTO < 2 min e RPO < 30s atendem SLAs de sistemas financeiros críticos (Tier-1). Health checks ativos com Route 53 Failover Policy garantem detecção automática sem intervenção humana.

> **Nota do Arquiteto:** Se eu fosse iniciar essa migração hoje, começaria pelo inventário de triggers Lambda — não pelo pool em si. Em todos os projetos que participei, os triggers são o componente com mais dependências ocultas: VPC configs, IAM roles com ARNs hardcoded, variáveis de ambiente apontando para endpoints regionais sem abstração. A replicação nativa do Cognito resolve o problema de dados de identidade de forma elegante, mas se os triggers não estiverem prontos na região secundária, o failover vai parecer funcionar no DNS e quebrar silenciosamente no fluxo de autenticação real. A lição aprendida da forma difícil: teste o fluxo completo de autenticação — incluindo Pre-Token-Generation — na região secundária antes de considerar a migração concluída.

## Anti-Padrões a Evitar Nessa Migração

- Habilitar replicação multi-Region sem antes auditar e corrigir o schema de atributos customizados — o schema imutável vai congelar problemas legados na réplica permanentemente.
- Usar chaves KMS independentes por região em vez de MRKs — isso cria necessidade de re-wrapping de dados e adiciona latência e complexidade desnecessárias ao fluxo de failover.
- Configurar TTL de DNS acima de 60 segundos para o registro do Cognito — isso aumenta o tempo de failover percebido pelo cliente além do tempo de detecção do health check.
- Buscar o JWKS endpoint em tempo de requisição no Lambda Authorizer — isso cria dependência síncrona cross-region que pode derrubar a validação de tokens exatamente quando a região primária está degradada.
- Não ajustar as Service Quotas de `InitiateAuth` na região secundária antes do failover — em um evento de failover real, o spike de tráfego vai atingir o limite padrão de 120 RPS e causar throttling massivo.

## Veredicto: Migre, Mas Faça com Disciplina de Engenharia

A replicação multi-Region nativa do Amazon Cognito é uma mudança de patamar para sistemas que tratam autenticação como infraestrutura crítica — e todo sistema financeiro deveria tratar. A funcionalidade resolve o problema mais difícil (consistência de credenciais e dados de usuário entre regiões) de forma gerenciada, eliminando a necessidade de soluções homegrown frágeis e caras. Minha recomendação é clara: migre para replicação nativa se você ainda não fez isso.

Mas a migração exige disciplina. Os pré-requisitos não são opcionais: schema auditado e correto, KMS MRKs configuradas com políticas restritivas, Lambda triggers espelhados com dependências regionais corretas, app clients replicados via IaC, Service Quotas ajustadas na região secundária, e — mais importante — um teste de failover completo com fluxo de autenticação end-to-end antes de declarar a migração concluída. Sem esses elementos, você terá a falsa sensação de resiliência: o DNS vai para a região secundária, mas o login falha silenciosamente porque o trigger não encontra o DynamoDB correto ou o app client não existe.

Para sistemas financeiros brasileiros, adicione a camada de governança: documente a replicação no ROPA, garanta que os controles de segurança (KMS, CloudTrail, VPC) sejam equivalentes em ambas as regiões, e implemente validação de claims obrigatórios no Lambda Authorizer como defesa contra falhas silenciosas de trigger. Identidade resiliente não é um projeto de um sprint — é uma capacidade de plataforma que precisa ser construída com a mesma seriedade que qualquer outro componente Tier-1.

**Rating:** Recomendado com Pré-Requisitos / Recomme

## Referências e Leitura Adicional

- [Amazon Cognito multi-Region replication – AWS News Blog](https://aws.amazon.com/blogs/aws/)
- [Amazon Cognito Developer Guide – User Pool Replication](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-multi-region.html)
- [AWS KMS Multi-Region Keys](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)
- [Route 53 Health Checks and DNS Failover](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html)
- [Amazon Cognito Service Quotas](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html)
- [AWS Well-Architected Framework – Reliability Pillar](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)
- [DynamoDB Global Tables](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
- [AWS Secrets Manager Cross-Region Replication](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create-manage-multi-region-secrets.html)