# ADR: Cognito Multi-Região para Autenticação Resiliente Este ADR analisa quando e como adotar replicação multi-região de User Pools no Amazon Cognito para reduzir indisponibilidade de autenticação em plataformas de identidade com requisitos de alta disponibilidade. São discutidos failover regional, chaves KMS gerenciadas pelo cliente, sincronização de usuários, impacto em sessões e tokens, domínios customizados e experiência do cliente, com raciocínio explícito sobre trade-offs operacionais e de custo. - URL: https://fernando.moretes.com/studies/adr-cognito-multiregion-authentication-resilience - Markdown: https://fernando.moretes.com/studies/adr-cognito-multiregion-authentication-resilience/study.md?lang=pt - Type: Decisão (ADR) - Company: Identity platform (cenário) - Domain: Identidade / Resiliência - Status: accepted - Date: 2026-06-05 - Tags: cognito, multi-region, identity, resilience, kms, failover, authentication, aws - Reading time: 9 min --- Autenticação é o portão de entrada de qualquer sistema. Quando o Amazon Cognito fica indisponível em uma região, usuários não conseguem fazer login — e nenhuma outra parte da arquitetura importa. Este ADR documenta a decisão de adotar replicação multi-região de User Pools para uma plataforma de identidade com SLA de 99,99%, detalhando as forças que tornaram a solução necessária, as opções avaliadas e as consequências reais da escolha. ## Contexto do Cenário - **Sistema:** Plataforma de identidade centralizada (cenário composto) - **Domínio:** Identidade / Resiliência - **Escala:** ~2 milhões de usuários ativos, pico de 8.000 logins/min - **Regiões primária / secundária:** us-east-1 (primária), us-west-2 (secundária) - **SLA contratual de autenticação:** 99,99% (≤ 52 min de downtime/ano) - **Gatilho para o ADR:** Incidente de 47 min em us-east-1 causou bloqueio total de login; SLA quase violado - **Stack de identidade:** Amazon Cognito User Pools, Lambda Triggers, KMS CMK, Route 53, ACM, API Gateway - **Modelo de autenticação:** OAuth 2.0 / OIDC, tokens JWT (ID + Access + Refresh), domínio customizado auth.example.com - **Recurso de replicação (GA):** Amazon Cognito multi-Region replication — disponível a partir de 2024 ## Contexto e Forças em Jogo 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. ## O Problema com Chaves KMS e Tokens em Cenários Multi-Região 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. ## Opções Avaliadas ### Opção A: Aceitar o risco regional (status quo) **Pros** - Zero custo adicional de infraestrutura - Sem complexidade operacional de sincronização - Configuração de domínio customizado simples **Cons** - SLA de 99,99% matematicamente inatingível sem failover - Incidente já demonstrou impacto de 47 min de downtime total - Risco de violação contratual com clientes B2B **Verdict:** Rejeitada. O incidente real tornou essa opção indefensável. ### Opção B: Dois User Pools independentes com sincronização manual via Lambda/EventBridge **Pros** - Disponível antes da feature nativa de replicação - Controle total sobre o que é sincronizado **Cons** - Senhas não podem ser replicadas (hashes com salt por usuário) - Tokens emitidos pelo primário são inválidos no secundário (JWKS diferentes) - Janela de inconsistência estrutural para usuários recém-criados - Alta complexidade operacional: triggers, DLQs, reconciliação, monitoramento duplo - Failover força relogin ou proxy de validação complexo **Verdict:** Rejeitada. Complexidade alta para resiliência incompleta — o pior dos dois mundos. ### Opção C: Replicação nativa multi-região do Cognito + MRK + Route 53 ARC **Pros** - Replicação completa de usuários, atributos, credenciais e chaves de assinatura JWT - Tokens emitidos no primário são válidos no secundário (mesmo issuer e JWKS) - MRKs garantem continuidade de criptografia sem exportação de material de chave - Failover de DNS automatizável via Route 53 ARC com health checks - Reduz complexidade operacional vs. sincronização manual **Cons** - Custo adicional: replicação e execução dual de User Pool (estimativa: +30-40% no custo Cognito) - Domínio customizado requer configuração independente por região + certificados ACM regionais - Lambda Triggers precisam ser replicados e mantidos em sincronia manualmente entre regiões - Sessões ativas no momento do failover podem exigir reautenticação se o refresh token não for honrado - Feature relativamente nova — comportamento em edge cases ainda sendo documentado pela comunidade **Verdict:** Aceita. Melhor equilíbrio entre resiliência real, segurança e complexidade operacional gerenciável. ### Opção D: Substituir Cognito por solução de identidade self-hosted multi-região (Keycloak, Auth0) **Pros** - Controle total sobre replicação, failover e modelo de dados - Portabilidade de provedor **Cons** - Custo de migração altíssimo: 2M usuários, integrações OAuth existentes, Lambda Triggers - Keycloak self-hosted exige infraestrutura, patching, HA próprios — TCO real muito maior - Auth0/Okta: custo por MAU proibitivo a 2M usuários - Não resolve o problema imediato; timeline de 12-18 meses mínimo **Verdict:** Rejeitada para o horizonte deste ADR. Pode ser reavaliada em revisão estratégica futura. ## Decisão Formal **Status:** accepted **Contexto** A plataforma de identidade opera com SLA de 99,99% e serve 2 milhões de usuários ativos. Um incidente regional de 47 minutos em us-east-1 quase violou o SLA contratual e bloqueou operações críticas de clientes B2B. A arquitetura existente não possuía mecanismo de failover de autenticação. A AWS lançou replicação nativa multi-região para Cognito User Pools, tornando viável uma solução estrutural. **Decisão** Adotar replicação nativa multi-região do Amazon Cognito User Pool entre us-east-1 (primária) e us-west-2 (secundária), com KMS Multi-Region Keys para continuidade de criptografia, Route 53 Application Recovery Controller (ARC) para failover de DNS automatizado, e domínios customizados configurados independentemente em cada região com certificados ACM regionais. Lambda Triggers serão gerenciados via IaC (Terraform) com deploy simultâneo em ambas as regiões. O RTO alvo é de 5 minutos; o RPO é próximo de zero para dados de usuário (replicação contínua). **Consequências** - POSITIVO: Tokens JWT emitidos na região primária são válidos na secundária sem reautenticação forçada, pois o issuer e as chaves de assinatura são compartilhados. - POSITIVO: Dados de usuário (atributos, credenciais, grupos) são replicados continuamente, eliminando a janela de inconsistência da abordagem manual. - POSITIVO: MRKs garantem que dados criptografados com a chave primária sejam decriptáveis na região secundária sem exportação de material de chave. - NEGATIVO: Sessões ativas com refresh tokens em voo no momento exato do failover podem exigir reautenticação — janela estimada de impacto < 1% das sessões ativas. - NEGATIVO: Lambda Triggers devem ser mantidos em sincronia entre regiões via pipeline CI/CD; drift de configuração é um risco operacional que requer monitoramento explícito. - NEGATIVO: Custo estimado adicional de 30-40% na linha Cognito do orçamento de identidade (estimativa baseada em modelo de preços público; validar com AWS Cost Calculator para escala real). ## Domínios Customizados, Sessões e Experiência do Cliente no Failover 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. ## Arquitetura de Failover Multi-Região — Fluxo de Autenticação Diagrama mostra o fluxo normal (us-east-1 ativo) e o caminho de failover para us-west-2, incluindo replicação de User Pool, MRKs e controle de DNS via Route 53 ARC. ### 👤 Client Layer - Browser / Mobile OAuth 2.0 + PKCE (user) - Application API Gateway + Lambda (frontend) ### 🌐 DNS & Routing - Route 53 auth.example.com Weighted CNAME (network) - Route 53 ARC Health Check /oauth2/token (network) ### 🔐 us-east-1 — Primary - CloudFront auth.example.com (Cognito-managed) (edge) - Cognito User Pool us-east-1 (Primary) OIDC Issuer (security) - Lambda Triggers Pre-Token / Post-Auth us-east-1 (compute) - KMS MRK us-east-1 mrk-xxxxxxxx (security) ### 🔐 us-west-2 — Secondary (Standby) - CloudFront auth.example.com (Cognito-managed) (edge) - Cognito User Pool us-west-2 (Replica) Same Issuer + JWKS (security) - Lambda Triggers Pre-Token / Post-Auth us-west-2 (compute) - KMS MRK Replica us-west-2 mrk-xxxxxxxx (same) (security) ### 📦 Shared / Control Plane - Cognito Replication Continuous Sync Users + Credentials (data) - Terraform IaC Dual-Region Deploy Triggers + Config (ci) - CloudWatch Alarms + Dashboards Both Regions (data) ### Fluxos - client -> r53: Resolve auth.example.com - r53 -> cf_primary: Weight 100 (normal) - r53 -> cf_secondary: Weight 0 → 100 (failover) - arc -> r53: Aciona failover automático - arc -> cf_primary: Health check /oauth2/token - arc -> cf_secondary: Health check /oauth2/token - cf_primary -> cognito_primary: Auth flow - cf_secondary -> cognito_secondary: Auth flow (failover) - cognito_primary -> lambda_primary: Triggers - cognito_secondary -> lambda_secondary: Triggers - cognito_primary -> kms_primary: Encrypt/Decrypt - cognito_secondary -> kms_secondary: Encrypt/Decrypt - kms_primary -> kms_secondary: MRK Sync (AWS-managed) - cognito_primary -> replication: Replicação contínua - replication -> cognito_secondary: Sync usuários/credenciais - terraform -> lambda_primary: Deploy simultâneo - terraform -> lambda_secondary: Deploy simultâneo - app_client -> client: Valida JWT (JWKS) - cognito_primary -> cloudwatch: Métricas/Logs - cognito_secondary -> cloudwatch: Métricas/Logs ## Avaliação Well-Architected - **security**: KMS Multi-Region Keys mantêm o modelo de segurança HSM sem exportação de material de chave. Atributos sensíveis de usuário permanecem criptografados em repouso em ambas as regiões. O princípio de menor privilégio é aplicado: Lambda Triggers têm roles IAM separadas por região, sem permissões cross-region desnecessárias. MFA e políticas de senha são replicadas junto com o User Pool. - **reliability**: RTO alvo de 5 minutos via Route 53 ARC com health checks de 30 segundos. RPO próximo de zero para dados de usuário com replicação contínua nativa. Game Days trimestrais validam o procedimento de failover. O design elimina o Cognito como SPOF regional para o fluxo de autenticação. ## Plano de Implementação 1. **Fase 1 — Fundação (Semanas 1-2)** — Criar KMS Multi-Region Key em us-east-1 e replicar para us-west-2. Atualizar User Pool primário para usar a MRK. Validar que dados existentes de usuário permanecem acessíveis. Configurar módulos Terraform para gerenciamento dual-região. 2. **Fase 2 — Replicação (Semanas 3-4)** — Habilitar replicação nativa multi-região do Cognito. Aguardar sincronização inicial (tempo proporcional ao volume de usuários). Validar integridade de amostra de usuários na região secundária. Replicar Lambda Triggers via pipeline CI/CD com deploy simultâneo. 3. **Fase 3 — Domínio e DNS (Semana 5)** — Provisionar certificado ACM em us-east-1 para auth.example.com (ou reutilizar o existente se o domínio for idêntico). Configurar domínio customizado no User Pool secundário. Criar registros Route 53 ponderados (100/0). Configurar Route 53 ARC com health checks contra /oauth2/token de ambas as regiões. 4. **Fase 4 — Validação e Game Day (Semana 6)** — Executar Game Day controlado: simular falha de us-east-1, medir RTO real, validar que tokens existentes são aceitos na secundária, validar fluxos OAuth completos (authorization code + PKCE), validar MFA. Documentar resultados e ajustar TTLs e thresholds de health check conforme necessário. > **Minha Perspectiva — O que eu faria e o que aprendi:** A replicação nativa multi-região do Cognito é uma adição genuinamente importante ao portfólio de resiliência da AWS — mas ela não resolve tudo automaticamente, e é fácil subestimar os pontos de fricção operacional. O ponto que mais me preocupa em implementações reais é o **drift de Lambda Triggers**. A replicação do Cognito sincroniza dados de usuário, não lógica de aplicação. Se você tem Pre-Token Generation triggers que adicionam claims customizados, ou Post-Authentication triggers que registram eventos em um SIEM, esses precisam existir e funcionar identicamente em ambas as regiões. Em organizações com pipelines de deploy menos maduros, vi casos onde a região secundária ficou semanas com triggers desatualizados — o que significa que, em um failover real, os tokens emitidos teriam claims diferentes dos esperados pelos serviços downstream. Isso é uma falha silenciosa que só aparece em produção, no pior momento possível. **Automatize o deploy de triggers como parte do mesmo pipeline que faz deploy do User Pool. Sem exceções.** Sobre KMS MRKs: a decisão de usar MRKs é correta e necessária, mas há um detalhe de segurança que precisa ser explicitado na política de chave. A réplica MRK em us-west-2 deve ter uma key policy que restringe o uso ao User Pool secundário específico — não uma policy permissiva que permite qualquer principal na conta. Em sistemas financeiros, auditores vão questionar isso, e a resposta precisa ser documentada. Por fim, sobre o trade-off de custo: o argumento de que 30-40% de aumento no custo Cognito é justificado pelo SLA é correto, mas incompleto. O custo real inclui também o tempo de engenharia para manter a paridade de configuração entre regiões, os Game Days trimestrais, e o monitoramento dual. Esse custo operacional recorrente é frequentemente subestimado nas análises de ROI. Para sistemas com menos de ~500k MAUs onde o custo Cognito é pequeno em termos absolutos, o overhead operacional pode dominar. Para 2M MAUs com SLA contratual, a conta fecha claramente — mas seja honesto sobre o custo total ao apresentar a decisão para stakeholders. ## Comparativo: Antes vs. Depois da Arquitetura Multi-Região | Critério | Dimensão | Antes (Single Region) | Depois (Multi-Region Nativo) | | --- | --- | --- | --- | | RTO de autenticação | ~47 min (observado no incidente) | ~5 min (alvo, via Route 53 ARC) | — | | RPO de dados de usuário | Horas (última exportação manual) | Próximo de zero (replicação contínua) | — | | Validade de tokens no failover | Inválidos (JWKS diferentes) | Válidos (mesmo issuer e JWKS) | — | | Consistência de credenciais | Parcial (senhas não replicáveis) | Completa (replicação nativa inclui credenciais) | — | | Complexidade operacional | Baixa (single region) | Média (dual region, IaC obrigatório) | — | | Custo relativo de identidade | Baseline | +30-40% estimado (Cognito + MRK + ARC) | — | ## Veredicto A replicação nativa multi-região do Amazon Cognito resolve um problema que, até recentemente, não tinha solução limpa na plataforma. Para sistemas com SLA de autenticação de 99,99% ou superior, com volume de usuários que torna a migração para alternativas proibitiva, e com requisitos de conformidade que exigem controle sobre replicação de dados de identidade, essa é a arquitetura correta — e este ADR documenta por quê. Os três pontos que definem o sucesso ou fracasso desta arquitetura são: **(1) MRKs corretamente configuradas** com key policies restritivas por região — sem isso, o failover pode decriptar dados ou, pior, falhar silenciosamente; **(2) Lambda Triggers em paridade garantida por pipeline CI/CD** — drift de lógica de token é uma falha que só aparece em produção sob pressão; **(3) Game Days trimestrais com failover real** — RTO de 5 minutos é um alvo, não uma garantia, até ser validado sob condições reais. O que este ADR não resolve: a complexidade de domínios customizados com múltiplos ambientes (staging, prod, sandbox) que compartilham o mesmo Cognito — nesses casos, a proliferação de User Pools replicados pode se tornar um problema de governança. E não resolve a questão estratégica de longo prazo sobre dependência de um único provedor de identidade gerenciado. Essas são decisões para ADRs futuros, mas devem estar no radar de qualquer arquiteto responsável por plataformas de identidade em escala. ## Referências - [Amazon Cognito multi-Region replication — AWS News Blog](https://aws.amazon.com/blogs/aws/) - [Amazon Cognito — Product Page](https://aws.amazon.com/cognito/) - [AWS Well-Architected Framework — Security Pillar](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html) - [AWS KMS Multi-Region Keys — Developer Guide](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html) - [Route 53 Application Recovery Controller — Developer Guide](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route-53-recovery.html) - [Amazon Cognito User Pools — Custom Domains](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-add-custom-domain.html) ## Fontes do caso - [AWS News Blog — Cognito multi-Region replication](https://aws.amazon.com/blogs/aws/) - [Amazon Cognito](https://aws.amazon.com/cognito/) - [AWS Well-Architected — Security Pillar](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)