Por que autenticação multi-região importa
O sistema de Gerenciamento de Identidade e Acesso do Consumidor (CIAM) é a base da experiência do cliente: é por ele que usuários fazem login, acessam serviços e interagem com aplicações. À medida que negócios crescem em múltiplas geografias, garantir que a autenticação esteja sempre disponível deixa de ser diferencial e passa a ser requisito arquitetural.
Historicamente, construir autenticação multi-região exigia soluções de replicação customizadas e complexas, que precisavam sincronizar dados de usuários, gerenciar consistência e orquestrar failover — tudo com alto custo operacional. A AWS endereça esse problema com o recurso de Replicação Multi-Região (MRR) do Amazon Cognito, que replica user pools entre regiões AWS automaticamente, com sincronização em tempo quase real e failover integrado.
Como o Cognito MRR funciona
O MRR cria um user pool réplica em outra região AWS, compartilhando o mesmo ID do user pool primário. O user pool primário permanece autoritativo: suas configurações (IDs de app client, client secrets), dados de usuários (atributos, credenciais com hash, memberships de grupos) e configurações de provedores de identidade externos (IdP) são replicados para a réplica com consistência eventual.
O user pool réplica suporta operações de autenticação — como login, geração e revogação de tokens — e operações de leitura sobre configurações e atributos. Operações de escrita, como atualização de atributos ou configurações do user pool, não são permitidas na réplica e devem ser feitas exclusivamente no user pool primário. Ao tentar realizar essas operações na réplica, o Cognito retorna o erro Action temporarily unavailable no managed login, ou OperationNotEnabledException via SDK. A lista completa de operações de API suportadas em regiões secundárias está disponível na documentação.
Um ponto importante: tokens JWT (Tokens Web JSON) e sessões ativas são interoperáveis entre regiões. Por exemplo, um refresh token emitido pela região primária é aceito na réplica para obter novos tokens de ID e acesso.
Preparação para o MRR
Chave gerenciada pelo cliente multi-região (KMS)
Antes de habilitar o MRR, é necessário configurar o user pool para usar uma chave gerenciada pelo cliente. Essa chave deve ser uma chave simétrica multi-região do AWS Key Management Service (AWS KMS). Sem o MRR, os dados são criptografados em repouso com uma chave gerenciada pela AWS e em trânsito com TLS 1.2/1.3 com troca de chaves pós-quântica híbrida.
Algumas considerações arquiteturais importantes sobre a chave KMS:
- Você precisa de apenas uma chave multi-região réplica, pois o MRR do Cognito suporta somente uma região réplica adicional.
- A administração da chave — políticas, rotação e exclusão — é responsabilidade do cliente.
- Aplique o princípio do menor privilégio na política da chave KMS, limitando o escopo ao seu user pool com a condição
kms:EncryptionContext:aws:cognito-idp:<userpool-arn>. A seção de criptografia de dados no guia do desenvolvedor traz um exemplo completo de política.
Emissor OIDC multi-região
Cada token de ID e acesso emitido pelo Cognito inclui a claim iss (issuer), que identifica o provedor de identidade emissor. A especificação OpenID Connect (OIDC) exige que esse valor seja uma URL HTTPS que publique um documento de metadados.
O formato original do issuer é regional: https://cognito-idp.<region>.amazonaws.com/<userpool_id>. Com o MRR, a AWS introduz um novo tipo de issuer multi-região, no formato https://issuer-cognito-idp.<region>.amazonaws.com/<userpool_id>. Esse novo tipo mantém os endpoints de descoberta OIDC e de Conjunto de Chaves Web JSON (JWKS) disponíveis independentemente do estado da região primária ou réplica.
A recomendação é adotar o issuer atualizado. Com ele, as aplicações conseguem buscar chaves de assinatura para verificação de tokens mesmo durante uma falha regional. Para adotá-lo, atualize suas aplicações e dependências para validar contra o novo valor de iss. Se você usa a biblioteca aws-jwt-verify, atualize para a versão v5.2.1 ou posterior.
Se não for possível migrar imediatamente — por exemplo, porque serviços de terceiros validam o iss contra o formato original fixo — é possível habilitar o MRR mantendo o issuer original. Nesse caso, implemente uma estratégia de cache do JWKS para que suas aplicações continuem validando tokens com chaves em cache quando o endpoint estiver inacessível. Mais detalhes na seção Amazon Cognito user pools como emissor OIDC do guia do desenvolvedor.
Dependências de serviços regionais
O Cognito integra com vários serviços regionais da AWS para funcionalidades de customização. Todos eles precisam ser configurados de forma independente na região réplica:
- AWS Lambda: Os triggers Lambda (pré-autenticação, pré-geração de token, etc.) devem ser implantados e associados ao user pool réplica. É possível usar a mesma lógica para ambas as regiões ou definir comportamentos distintos para a réplica.
- AWS WAF: As listas de controle de acesso web (web ACLs) devem ser criadas na região réplica para proteger o user pool réplica.
- Amazon Simple Notification Service (Amazon SNS): Para envio de SMS (MFA por SMS, autenticação sem senha), configure o SNS na região réplica. O tempo de registro de identidades de origem depende de vários fatores.
- Amazon Simple Email Service (Amazon SES): Verifique domínios e endereços de e-mail na região réplica e configure o user pool réplica adequadamente.
- Amazon CloudWatch: Configure alarmes e análises para exportação de logs e monitoramento de cotas na região réplica.
Use ferramentas de infraestrutura como código como AWS CloudFormation ou AWS Cloud Development Kit (AWS CDK) para manter configurações consistentes entre regiões e monitorar desvios de configuração.
Failover automático de domínio
Para casos de uso que dependem de managed login e endpoints OAuth 2.0, o Cognito suporta failover automático para a região réplica usando um health check do Amazon Route 53. O Cognito usa o status do health check para controlar se o tráfego vai para o user pool primário ou réplica. Tanto o domínio prefixado do Cognito quanto domínios customizados suportam esse failover automático.
Com isso, é possível usar um único domínio para servir configurações de IdPs externos, incluindo URIs de redirecionamento e URLs de consumidor de asserção SAML — sem precisar contatar administradores de IdPs externos ao habilitar o MRR.
Alternativas ao MFA por TOTP e cotas
O MFA baseado em Senha de Uso Único Baseada em Tempo (TOTP) não é suportado em user pools réplica. Usuários configurados com TOTP precisam autenticar pela região primária. Se sua aplicação depende de TOTP como segundo fator, planeje habilitar alternativas como OTP por SMS, OTP por e-mail ou passkey.
Ao ativar um user pool réplica, você ganha um conjunto separado de cotas padrão na região réplica — cotas reservadas previamente na região primária não são transferidas. Ao selecionar a região réplica, considere também os requisitos de soberania e residência de dados da sua organização. O post Soberania digital prática: navegando pelos pilares de conformidade, continuidade e controle oferece orientações relevantes.
Arquiteturas de referência
Managed login e federação
O managed login do Cognito oferece uma interface de autenticação gerenciada que cuida dos fluxos de login, cadastro e federação. Com o MRR, os endpoints do managed login são servidos pelo user pool saudável com base no health check do Route 53. O fluxo funciona assim:
- O usuário acessa a aplicação e é redirecionado para o managed login.
- O managed login usa o health check do Route 53 para controlar o roteamento.
- Se o health check retornar status saudável, todo o tráfego flui para o user pool da região primária.
- Para usuários federados, o user pool primário redireciona para o IdP externo ou social.
- Se o health check retornar status não saudável, o tráfego flui para o user pool réplica. Criação de usuários e atualizações de atributos falharão até o health check se recuperar.
Arquitetura M2M (Máquina a Máquina)
Em uma arquitetura M2M, serviços autenticam usando o grant de credenciais de cliente do OAuth 2.0. Esse fluxo não envolve usuários humanos — serviços de backend trocam credenciais de cliente por tokens de acesso.
O fluxo de autenticação é:
- Clientes de aplicação enviam uma requisição POST ao endpoint
/tokendo Cognito com as credenciais de cliente. - O Route 53 determina se o tráfego deve fluir para o user pool primário ou réplica com base no health check.
- Se saudável, o tráfego vai para a região primária; se não saudável, para a réplica. Ao recuperar, o tráfego retorna para o user pool primário.
Arquitetura baseada em SDK
Para aplicações que usam o AWS SDK ou as APIs do Amazon Cognito diretamente — em vez do managed login — o fluxo de autenticação fica embutido no código da aplicação, oferecendo mais controle sobre a experiência do usuário, mas exigindo considerações adicionais para failover.
O fluxo é:
- O usuário acessa a aplicação e faz login por uma interface customizada via APIs ou SDKs.
- Um health check do Route 53 (opcional) monitora os endpoints proxy regionais para determinar o roteamento.
- Se saudável, o tráfego flui para o proxy da região primária, que repassa as requisições ao endpoint regional do Cognito via Amazon API Gateway.
- Se não saudável, o tráfego flui para o proxy da região réplica até o health check se recuperar.
Nessa arquitetura, também é possível configurar roteamento customizado para balancear requisições de autenticação, direcionando leituras para ambas as regiões e mantendo escritas apenas na primária. A AWS recomenda configurar um endpoint customizado para simplificar a orquestração de failover.
Estratégias de failover
Monitoramento com health checks do Route 53
O failover para managed login e todos os fluxos OAuth 2.0 é acionado por health checks do Amazon Route 53 associados ao domínio do Cognito. Uma abordagem prática para começar:
- Crie um canary sintético com o Amazon CloudWatch Synthetics para exercitar periodicamente um fluxo real de autenticação — por exemplo, uma requisição de token de credenciais de cliente contra o endpoint
/oauth2/tokenou uma chamada à API AdminInitiateAuth com credenciais de teste. - Associe o canary a um alarme do CloudWatch na métrica
SuccessPercent, com um threshold que considere erros transitórios (por exemplo, alarmar quando o sucesso cair abaixo de 90% por três períodos consecutivos). - Conecte o alarme ao health check do Route 53 para failover automático. Se preferir intervenção humana, configure o alarme para notificar a equipe de operações, que inverte o health check manualmente.
Após configurar o health check, associe-o ao domínio do Cognito usando a API UpdateUserPoolDomain ou o console do Cognito.
Failover apenas de autenticação vs. failover completo
Antes de implementar o failover, é importante entender como a camada de autenticação se relaciona com o restante da aplicação. Existem dois padrões comuns:
- Failover apenas de autenticação: A aplicação permanece em uma única região, mas o tráfego de autenticação falha para a réplica se apenas o serviço de autenticação da região primária estiver comprometido. Funciona quando a aplicação consegue operar com tokens já emitidos e as APIs downstream não dependem da mesma região do user pool.
- Failover completo de stack: Toda a aplicação — computação, armazenamento, APIs e autenticação — falha para a região réplica. Nesse modelo, o MRR do Cognito é um componente de uma arquitetura multi-região mais ampla, onde os fluxos de autenticação têm dependências regionais (como triggers Lambda chamando tabelas do Amazon DynamoDB regionais) que precisam estar co-localizadas com o user pool.
Para o failover completo, a AWS recomenda usar o Amazon Application Recovery Controller (ARC) para coordenar o failover de todos os componentes com uma única ação. O ARC oferece três capacidades relevantes para arquiteturas de autenticação multi-região:
- Controles de roteamento: Controles de plano de dados extremamente confiáveis para mudar tráfego DNS entre regiões, com regras de segurança que evitam failovers parciais ou não intencionais.
- Verificações de prontidão: Monitoramento contínuo de cotas de recursos, capacidade e políticas de roteamento de rede na região secundária.
- Region switch: Orquestração de recuperação multi-região centralizada, automatizada e observável em múltiplas contas e recursos AWS.
Saiba mais sobre o ARC no post Apresentando o Amazon Route 53 Application Recovery Controller.
Quando acionar o failover
Acionar failover cedo demais gera interrupções desnecessárias; tarde demais compromete a disponibilidade. Os fatores a balancear incluem: monitorar a saúde dos fluxos de autenticação críticos, usar health checks compostos combinando múltiplos sinais, definir thresholds apropriados para distinguir erros transitórios de falhas reais, e considerar dependências como triggers Lambda e IdPs externos. Para arquiteturas baseadas em SDK com SPAs (Aplicações de Página Única), considere implementar lógica de retry no lado do cliente com failover de região.
Entender e definir os objetivos de tempo de recuperação (RTO) e ponto de recuperação (RPO) também são fatores determinantes. O post Estabelecendo metas de RPO e RTO para aplicações em nuvem oferece orientações adicionais.
Testando a prontidão do failover
Se você usa health check do Route 53, comece invertendo-o manualmente durante uma janela de manutenção — no console do Route 53, habilite Invert health check status para forçar o estado de falha e acionar o failover para a região réplica sem mudanças de infraestrutura. Valide os fluxos críticos (login, refresh de token, federação) e desabilite a inversão para restaurar o tráfego.
Para simulações mais realistas, use o AWS Fault Injection Service (FIS) criando templates de experimento que perturbam as dependências do Cognito na região primária. Use condições de parada para interromper automaticamente experimentos se impactos inesperados forem detectados. A AWS recomenda realizar testes de failover em cadência regular e após mudanças significativas na arquitetura de autenticação.
Próximos passos
Para começar com o MRR do Cognito, certifique-se de que seu user pool está no plano de recursos Essentials ou Plus, configure a chave KMS multi-região e o issuer OIDC, e crie sua primeira réplica. As instruções passo a passo estão disponíveis em Replicação Multi-Região para user pools. Para dúvidas, a AWS sugere abrir um tópico no Amazon Cognito re:Post ou contatar o suporte AWS.
Fonte
Architecting resilient authentication with Amazon Cognito multi-Region replication (https://aws.amazon.com/blogs/security/architecting-resilient-authentication-with-amazon-cognito-multi-region-replication/)
Leave a Reply