Aurora Global Database mantém autenticação IAM mesmo depois de um failover entre regiões

O endpoint de escrita global resolve o roteamento, mas não a autenticação

Quem desenha um Aurora Global Database para resiliência entre regiões já sabe que o writer endpoint do cluster global é um nome DNS único e estável: depois de um switchover planejado ou de um failover, a AWS repontua esse endpoint para o novo primary automaticamente, sem que a aplicação precise trocar a connection string. O post do AWS Database Blog mostra que isso resolve o roteamento, mas deixa em aberto um problema separado: o que acontece com a autenticação quando a aplicação usa IAM database authentication em vez de senha.

Dois problemas que o failover cria para quem usa IAM

A autenticação via IAM depende de um token SigV4 assinado para uma região específica e de uma permissão rds-db:connect escopada para o DbClusterResourceId do cluster que está servindo como writer. Um failover muda os dois ao mesmo tempo.

• Token assinado para a região errada. O token gerado por generate-db-auth-token carrega a região como um dos quatro parâmetros de assinatura (hostname, port, region, username). Depois da promoção, o primary está em outra região; um token assinado para a região antiga simplesmente não autentica mais.
• ARN de autorização aponta para o cluster errado. A permissão rds-db:connect é concedida para o ID de recurso (DbClusterResourceId) de um cluster específico. O cluster promovido é outro cluster, com outro resource ID, então a política antiga não cobre a nova situação.

Nenhum dos dois problemas é de rede ou de DNS: são de assinatura e de autorização, e o writer endpoint sozinho não resolve nenhum deles.

Três decisões de design fecham o ciclo

Para que a autenticação sem senha sobreviva ao failover sem reconfiguração manual, o padrão apresentado no blog combina três escolhas que, isoladamente, já são conhecidas, mas que raramente aparecem documentadas juntas, ponta a ponta.

Conectar sempre pelo Global writer endpoint

A connection string da aplicação nunca muda: ela aponta para o endpoint do cluster global, não para o endpoint de um cluster regional. É a Aurora que garante que esse nome resolve para o writer atual, seja ele qual for.

Assinar o token para a região primária descoberta em tempo real

O hostname do token continua sendo o Global writer endpoint, mas a região de assinatura precisa ser a do primary atual. O padrão descobre isso dinamicamente com aws rds describe-global-clusters, lendo o ARN do membro marcado como IsWriter==true no cluster global: o quarto campo do ARN (arn:aws:rds:<region>:...) dá a região certa no momento da conexão, sem hardcode.

Escopar o rds-db:connect para todos os clusters regionais, desde o início

Como o IAM database authentication ainda não suporta condition keys de política, não dá para escrever uma regra condicional que siga o writer automaticamente. A saída de menor privilégio é listar, na própria política, o ARN de rds-db:connect para o DbClusterResourceId de cada cluster regional que pode vir a ser primary:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "rds-db:connect",
      "Resource": [
        "arn:aws:rds-db:us-east-1:111122223333:dbuser:cluster-ABC123/app_user",
        "arn:aws:rds-db:us-west-2:111122223333:dbuser:cluster-DEF456/app_user"
      ]
    },
    {
      "Effect": "Allow",
      "Action": "rds:DescribeGlobalClusters",
      "Resource": "arn:aws:rds::111122223333:global-cluster:my-global-db"
    }
  ]
}

A segunda statement, com rds:DescribeGlobalClusters, é o que permite à aplicação descobrir a região do primary em tempo de conexão; sem ela, a chamada de descoberta falha com AccessDenied antes mesmo de chegar ao banco.

O usuário de banco replica, a política de IAM não

O usuário app_user é criado uma vez, no primary, com GRANT rds_iam TO app_user (PostgreSQL) ou CREATE USER 'app_user' IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS' (MySQL), e replica automaticamente para o cluster secundário como qualquer outro objeto do banco. A política IAM não replica sozinha: ela é escrita uma vez, cobrindo os DbClusterResourceId de todos os clusters desde o início, exatamente para que não precise ser editada quando o writer migra de região.

Testando o padrão: switchover ou failover

O blog valida a solução rodando os dois tipos de promoção de região com o mesmo endpoint, a mesma política e os mesmos comandos de conexão.

Depois de qualquer uma das duas operações, a mesma consulta de verificação (pg_is_in_recovery() no PostgreSQL, @@innodb_read_only no MySQL) confirma qual instância virou writer, sem que o cliente tenha trocado host, usuário ou política.

O que muda para quem desenha o ambiente

Para arquitetos e SREs que já rodam Aurora Global Database multirregião, o ganho prático não é só "a conexão não cai": é poder remover a reconfiguração manual de IAM da runbook de incidente. Hoje, em muitos desenhos, alguém precisa lembrar de atualizar a política ou o secret no momento do failover; aqui, isso é resolvido no design, antes do incidente acontecer, o que é exatamente o espírito do pilar de confiabilidade do Well-Architected Framework.

Isso também muda o checklist de quem cuida da política de identidade e acesso para esse ambiente: ao adicionar uma terceira região secundária ao Global Database, a política de rds-db:connect precisa ser atualizada com o novo DbClusterResourceId antes da promoção, não depois. Quem administra essas políticas ganha uma tarefa recorrente de IaC (atualizar a lista de resource IDs no Terraform ou CDK sempre que a topologia regional mudar), e não uma tarefa de emergência durante o failover.

Onde o padrão esbarra

O padrão pressupõe conectividade de rede cross-region do cliente para as duas regiões ao mesmo tempo, listada como pré-requisito na fonte, o que nem toda VPC com peering restritivo ou SCPs de Organizations permite sem ajuste prévio. Ele também exige que a aplicação implemente a descoberta de região a cada nova conexão, já que o token IAM expira em 15 minutos, o que é mais código de bootstrap do que um driver com usuário e senha fixos.

Para quem não usa Aurora Global Database, ou faz failover só dentro de uma única região, essa camada inteira de descoberta dinâmica de região não tem razão de existir: o padrão resolve um problema específico de topologia multirregião, não autenticação IAM em geral.

Fonte: AWS Database Blog