Roteamento regional para portais de acesso AWS: como implementar domínios personalizados no IAM Identity Center

O problema: múltiplas URLs para um único portal

O AWS IAM Identity Center oferece um portal de acesso web que centraliza o acesso dos colaboradores às contas AWS e aplicações corporativas. Com o lançamento da replicação multi-região do IAM Identity Center, as organizações passaram a ter instâncias do serviço em múltiplas regiões AWS — o que é ótimo para resiliência e latência, mas cria um desafio prático: cada região gera sua própria URL de acesso ao portal.

Gerenciar uma lista crescente de URLs regionais, comunicar aos usuários qual delas usar e ainda garantir failover em caso de incidente regional é uma dor de cabeça operacional real. A AWS publicou um guia técnico que resolve exatamente isso: criar um domínio personalizado único (por exemplo, aws.minhaempresa.com) que funciona como ponto de entrada consistente, redirecionando automaticamente cada usuário para o endpoint regional mais saudável e de menor latência.

Formatos de URL suportados pelo IAM Identity Center

Antes de entender a solução, vale conhecer os formatos de URL disponíveis na partição padrão da AWS. O formato recomendado pela AWS é https://{idcInstanceId}.portal.{region}.app.aws — ele suporta dual-stack (IPv4 e IPv6) e é compatível com replicação multi-região. Os formatos baseados em awsapps.com não estão sempre disponíveis em regiões mais novas e não suportam as capacidades multi-região. Em regiões replicadas adicionais, o alias personalizado não é suportado e o domínio pai awsapps.com não está disponível.

Um ponto importante: cada URL regional resolve apenas para a instância daquela região específica — não há failover automático entre regiões pelo próprio serviço. Para rotear usuários entre regiões de forma dinâmica, é necessário implementar a abordagem de domínio personalizado descrita no guia.

A solução: uma camada de roteamento e redirecionamento

A arquitetura proposta constrói uma camada leve de roteamento na frente dos endpoints regionais do IAM Identity Center. Os componentes envolvidos são:

• IAM Identity Center — a instância existente do serviço
• Amazon Route 53 — gerencia a zona hospedada do domínio personalizado, a política de roteamento por latência e os health checks
• Gerenciador de Certificados da AWS (ACM) — emite e renova automaticamente certificados TLS para o domínio personalizado em cada região
• Balanceador de Carga de Aplicação (ALB) — processa o tráfego HTTP e HTTPS, emitindo redirecionamentos 302 para o endpoint regional correto do IAM Identity Center
• Controlador de Recuperação de Aplicações da Amazon (ARC) — Region switch — orquestra failovers regionais controlando os estados dos health checks do Route 53

O fluxo de funcionamento é direto: quando um usuário acessa aws.minhaempresa.com, o Route 53 avalia os registros de latência e encaminha o tráfego para o ALB na região saudável de menor latência. O ALB encerra o TLS usando um certificado gerenciado pelo ACM e emite um redirecionamento 302 para a URL do portal do Identity Center naquela região. O navegador do usuário segue o redirecionamento e carrega o portal diretamente — o ALB não fica no caminho do tráfego de autenticação subsequente.

Vale destacar: o domínio personalizado em si não aparece na barra de endereços do navegador após o redirecionamento. A solução opera fora do Identity Center — na camada de DNS e balanceador de carga.

Três fases progressivas de implementação

O guia é estruturado em três fases independentes, que podem ser adotadas de acordo com a maturidade e necessidade de cada organização.

Fase 1: Redirecionamento para um único endpoint regional

A primeira fase estabelece a infraestrutura base: uma zona hospedada no Route 53, um certificado TLS gerenciado pelo ACM e um ALB voltado para a internet que emite redirecionamentos 302 para a URL do portal regional do Identity Center.

Os passos principais são: criar uma zona hospedada pública no Route 53 para o domínio personalizado (ex: aws.minhaempresa.com); delegar o subdomínio a partir do domínio pai adicionando um registro NS; solicitar um certificado ACM para o domínio na região primária do IAM Identity Center; criar um grupo de segurança para o ALB permitindo tráfego HTTP e HTTPS de entrada em IPv4 e IPv6; criar o ALB com listeners nas portas 80 e 443, configurando redirecionamentos 302 — sendo o listener HTTPS apontando para a URL do portal regional do Identity Center; e por fim criar registros DNS no Route 53 apontando para o ALB com política de roteamento por latência.

Um detalhe técnico importante destacado no guia: é obrigatório usar o código de status 302 – Found (e não 301). Usar 301 faz com que o navegador armazene em cache a URL de redirecionamento, o que impediria que failovers funcionassem corretamente até o cache expirar.

Para validar a configuração, basta executar:

curl -I https://aws.minhaempresa.com

A resposta esperada é um HTTP/2 302 com o cabeçalho location apontando para a URL do portal do Identity Center na região configurada.

Fase 2: Roteamento automático para o endpoint regional mais próximo

A segunda fase estende a solução para suportar a replicação multi-região do IAM Identity Center. O objetivo é que usuários em diferentes partes do mundo sejam automaticamente direcionados ao portal da região com menor latência de rede a partir de sua localização.

Para isso, é necessário repetir os passos da Fase 1 em cada região adicional onde o IAM Identity Center foi replicado: solicitar um certificado ACM na nova região, criar o grupo de segurança e o ALB (com a regra de redirecionamento apontando para o endpoint daquela região específica) e criar os registros DNS regionais e de roteamento por latência no Route 53 para cada região adicional.

Com isso, o Route 53 passa a ter registros de latência para todas as regiões ativas, e cada usuário é automaticamente direcionado ao ALB mais próximo, que por sua vez redireciona para o portal do Identity Center correspondente.

Fase 3: Failover regional gerenciado com ARC Region switch

A terceira fase introduz o Controlador de Recuperação de Aplicações da Amazon (ARC) para orquestrar failovers regionais de forma gerenciada, ensaiável e controlada. Sem essa fase, uma impairment regional exigiria atualizações manuais de DNS para redirecionar o tráfego.

O ARC Region switch fornece health checks do Route 53 diretamente como parte de um plano de Region switch. Esses health checks gerados são associados aos registros de latência do Route 53, e o ARC controla o estado (saudável ou não saudável) deles durante a execução do plano.

O processo envolve: criar um plano de Region switch no console do ARC com abordagem de recuperação ativa-ativa, selecionando as regiões onde o IAM Identity Center está replicado; configurar os workflows de Ativação e Desativação para cada região, associando os registros DNS do Route 53 com seus respectivos identificadores; e por fim associar os health checks gerados pelo ARC aos registros de latência A e AAAA no Route 53.

Para validar o setup, o guia orienta a executar um failover controlado: desativar a região primária via ARC e confirmar via curl que o redirecionamento passou a apontar para a região secundária. Para o failback, basta ativar novamente a região primária no plano do ARC.

Deploy automatizado com CloudFormation

Como alternativa aos passos manuais, a AWS disponibiliza templates do CloudFormation para cada fase, além de um script bash (deploy.sh) que automatiza o deploy das três fases em sequência. Os templates estão disponíveis para download:

• Fase 1 — Redirecionamento para região única: phase1-single-region-redirect.yaml
• Fase 2 — Roteamento por latência multi-região: phase2-multi-region-latency.yaml
• Fase 3 — Failover com ARC Region switch: phase3-arc-region-switch.yaml

Para usar o script de deploy unificado, o pacote de deployment deve ser baixado e descompactado. Antes de executar, é necessário configurar os parâmetros do ambiente no arquivo deploy.sh: domínio de nível superior (TLD), ID da zona hospedada do TLD, subdomínio do Identity Center, ID da instância do IAM Identity Center, região primária e regiões adicionais.

wget https://aws-security-blog-content.s3.us-east-1.amazonaws.com/public/sample/3536-regional-routing-for-aws-access-portals/Vanity-domains-cfn.zip
unzip Vanity-domains-cfn.zip
cd Vanity-domains-cfn

./deploy.sh

Integração com provedores de identidade externos

Após a configuração, o domínio personalizado pode ser integrado diretamente ao provedor de identidade da organização — como Okta ou Microsoft Entra ID — como uma aplicação de bookmark ou URL de chiclet. Dessa forma, usuários que acessam o painel do provedor de identidade são sempre redirecionados ao endpoint do IAM Identity Center mais próximo via roteamento por latência. Em caso de impairment regional, administradores executam um Region switch no ARC e os usuários são automaticamente redirecionados ao endpoint ativo, sem nenhuma alteração na URL do bookmark ou na experiência do usuário final.

Pré-requisitos para implementação

Antes de iniciar, a AWS lista os seguintes requisitos: um domínio de nível superior existente (ex: minhaempresa.com); uma instância organizacional do AWS IAM Identity Center configurada; para as Fases 2 e 3, a replicação multi-região do IAM Identity Center configurada com pelo menos duas regiões; e permissões de Gerenciamento de Identidade e Acesso da AWS (IAM) em uma conta de rede dedicada ou de serviços compartilhados para gerenciar Route 53, ACM, Amazon EC2, ALB e ARC.

Recursos adicionais

• Guia do Usuário do IAM Identity Center — Replicação Multi-Região
• Amazon Route 53 — Roteamento Baseado em Latência
• Amazon Application Recovery Controller — Region switch
• AWS Certificate Manager — Solicitando um Certificado Público
• Posts do Blog de Arquitetura AWS sobre Resiliência

Fonte

Regional routing for AWS access portals: Implementing custom vanity domains for IAM Identity Center (https://aws.amazon.com/blogs/security/regional-routing-for-aws-access-portals-implementing-custom-vanity-domains-for-iam-identity-center/)