AWS Secrets Manager passa a replicar segredos entre contas AWS sem KMS compartilhada

O que a AWS lançou

A AWS anunciou em 13 de novembro de 2026 que o AWS Secrets Manager agora suporta replicação cross-account. O recurso mantém uma cópia sincronizada de um segredo primário em uma conta AWS secundária, para acesso entre contas, backup e disaster recovery.

A novidade estende uma capacidade que já existia: a replicação multi-Region do Secrets Manager, que copia um segredo entre regiões dentro da mesma conta. Agora essa replicação atravessa a fronteira de conta, não só de região.

Como funciona na prática

O modelo resolve um problema conhecido de quem opera landing zone com AWS Organizations: como distribuir uma credencial (senha de banco, chave de API, token de terceiro) para várias contas sem compartilhar a chave KMS que criptografa o segredo nem desenhar policy de acesso cross-account no IAM.

Com a replicação cross-account, uma equipe de plataforma ou segurança possui e gira o segredo centralmente, em uma conta primária. Cada conta consumidora recebe uma cópia local, sempre atualizada, sem precisar de acesso direto à conta de origem. Os pontos centrais do modelo:

• A réplica é um recurso independente e completo, não um ponteiro para o segredo original.
• Ela é criptografada com uma chave KMS gerenciada pelo cliente, mas de propriedade da própria conta réplica — não da conta primária.
• O Secrets Manager atualiza a réplica automaticamente sempre que o valor do segredo primário muda, inclusive em rotações automáticas.
• A associação entre contas é feita pela API AssociateCrossAccountReplica, documentada no API Reference do Secrets Manager.

O recurso está disponível em todas as regiões onde o Secrets Manager já opera, conforme a tabela de regiões da AWS. Não há anúncio de preço específico para a replicação em si; o custo segue o modelo padrão de segredos do Secrets Manager, detalhado na página de preços do serviço.

O ganho real para quem opera ambientes multi-conta

Para arquitetos, DevOps e SRE que já desenham ambiente multi-conta como padrão de referência, o ponto relevante não é só o o que foi lançado, é o que deixa de ser necessário construir. Antes dessa capacidade, replicar um segredo entre contas de forma segura exigia um dos dois caminhos abaixo, ambos com atrito operacional:

Com a réplica nativa, cada conta consumidora fica com sua própria chave KMS e sua própria política de acesso, isolada da conta primária. Isso reduz o blast radius de um incidente: comprometer a conta de destino não dá acesso à chave que protege o segredo na origem, e vice-versa.

O cenário de disaster recovery citado pela AWS é direto: manter uma cópia viva de um segredo crítico em uma conta de recuperação dedicada, isolada de um ransomware ou de uma conta primária comprometida. Se a conta primária cair ou for comprometida, a réplica pode ser promovida a segredo autônomo e a aplicação segue operando a partir dela, sem depender da conta de origem estar saudável.

O que muda para quem responde por compliance e LGPD

Para times de compliance e privacidade, a separação de responsabilidades embutida no modelo é o detalhe que mais importa. Como cada réplica usa uma chave KMS própria, de propriedade da conta que a recebe, a segregação de funções entre quem administra a conta de origem e quem administra a conta de destino fica registrada na própria arquitetura, não apenas em um documento de política interna.

Isso facilita um argumento comum em auditoria sob a LGPD: provar que o acesso a uma credencial sensível (como a senha de um banco com dados pessoais) está limitado à conta que efetivamente precisa dela, sem que a equipe consumidora tenha visibilidade sobre a chave mestra usada na origem.

Vale registrar também o que o anúncio não detalha: não há menção a atraso de replicação (latência entre a rotação do segredo primário e a atualização da réplica), nem a limites de quantas contas podem receber réplicas de um mesmo segredo primário. Quem for desenhar o processo de rotação centralizada para múltiplas contas precisa validar esses pontos na documentação de referência ("Replicate secrets across AWS accounts", no User Guide do Secrets Manager) antes de tratar a réplica como garantia de consistência em tempo real.

O que ainda fica em aberto

A AWS não divulgou, no anúncio, valores de preço específicos para a replicação cross-account, apenas remeteu à página de preços padrão do Secrets Manager, onde cada segredo armazenado e cada chamada de API têm custo. Como a réplica é um recurso independente, é razoável assumir que ela é cobrada como um segredo adicional, mas isso precisa ser confirmado na calculadora de preços antes de qualquer decisão de arquitetura em escala.

Também não há, no material divulgado, detalhe sobre como a confiança entre contas é estabelecida (se via AWS Organizations, via resource policy explícita, ou ambos) além da existência da API AssociateCrossAccountReplica. Esse é o próximo ponto a checar na documentação para quem for implementar o padrão em uma landing zone com múltiplas contas de produção, staging e disaster recovery.

Fonte: AWS What's New