Criptografia em Repouso no Aurora: Tipos de Chave e Como Migrar um Cluster Já Existente

Criptografia em Repouso no Aurora: Tipos de Chave e Como Migrar um Cluster Já Existente

Criptografia em repouso costuma entrar na conversa em dois momentos: numa auditoria de compliance ou depois que alguém pergunta "nosso banco de produção está criptografado?" e a resposta demora mais do que deveria. No Aurora, a resposta técnica é simples de entender, mas a migração de um cluster que já existe sem criptografia não é trivial — não existe um "botão" para ligar. Este post resume os tipos de criptografia disponíveis e detalha o procedimento real para migrar um cluster Aurora existente para um cluster criptografado, com os comandos exatos.

Tipos de criptografia no Aurora

O Aurora protege dados em dois momentos: em repouso (o dado parado no storage) e em trânsito (o dado se movendo entre cliente e cluster, ou entre instâncias/regiões). Este post foca em repouso.

Para criptografia em repouso, o Aurora usa AES-256 com envelope encryption via AWS KMS: cada instância recebe uma data encryption key (DEK) única de 256 bits, e uma cópia dessa DEK — cifrada pela chave KMS — fica guardada para uso em snapshots futuros. Isso cobre instâncias, logs, backups automatizados e snapshots do cluster.

Existem três tipos de chave KMS que podem ser usadas:

AWS owned key (SSE-RDS) — chave totalmente controlada pela AWS, você não visualiza nem gerencia. É o padrão usado automaticamente pelo Aurora.

AWS managed key (AMK) — criada e gerenciada pela AWS, mas visível na sua conta. Não tem mensalidade, mas cobra por chamada de API do KMS. É considerada uma opção legada, mantida por compatibilidade.

Customer managed key (CMK) — a chave fica na sua conta, criada e controlada por você (rotação, política de acesso, revogação). Você paga as tarifas normais do KMS. É a opção recomendada quando há exigência de auditoria ou controle total sobre a chave.

Um ponto que mudou recentemente e vale registrar: a partir de 18 de fevereiro de 2026, todo cluster Aurora novo passou a ser criptografado por padrão com uma AWS owned key, mesmo sem nenhuma configuração explícita. Isso só vale para clusters criados a partir dessa data — quem tem cluster anterior sem criptografia continua sem, e snapshots, clones e réplicas Aurora tirados desse cluster antigo também nascem sem criptografia.

Por que não dá para simplesmente "ligar" a criptografia

Segundo a documentação oficial da AWS, não é possível converter um DB cluster já existente sem criptografia em um cluster criptografado in-place. A única forma é restaurar um snapshot desse cluster especificando uma chave KMS no momento da restauração — o que sempre resulta em um cluster novo, com endpoint novo.

Duas variações desse caminho, ambas documentadas oficialmente:

• Restaurar diretamente o snapshot (sem criptografia) especificando a chave KMS na própria operação de restore — o cluster restaurado já sai criptografado.

• Copiar o snapshot especificando uma customer managed key durante a cópia (gerando um snapshot criptografado) e, só depois, restaurar esse snapshot copiado.

Na prática, a primeira opção é mais direta e é o caminho que detalho abaixo.

Outras restrições importantes documentadas pela AWS:

• Depois que um cluster é criado com uma chave KMS, essa chave não pode ser trocada — se for preciso mudar de chave depois, o caminho é o mesmo: snapshot + restore especificando a nova chave.

• Não existe caminho de volta: não dá para descriptografar um cluster criptografado in-place. Só exportando os dados e importando em um cluster sem criptografia.

• Criptografia do Aurora não está disponível para a classe de instância db.tX.micro.

  
  

Procedimento passo a passo

Pré-requisito: decidir qual chave KMS será usada (AWS managed key ou customer managed key). Se for CMK, ela precisa existir antes do restore.

1. Criar um snapshot manual do cluster atual (sem criptografia)

aws rds create-db-cluster-snapshot \
  --db-cluster-identifier meu-cluster-atual \
  --db-cluster-snapshot-identifier meu-cluster-snapshot-pre-encryption

2. Restaurar o snapshot especificando a chave KMS

aws rds restore-db-cluster-from-snapshot \
  --db-cluster-identifier meu-cluster-criptografado \
  --snapshot-identifier meu-cluster-snapshot-pre-encryption \
  --engine aurora-mysql \
  --kms-key-id <arn-ou-id-da-chave-kms>

Ajuste --engine para o motor real do cluster (aurora-mysql, aurora-postgresql etc). Esse comando cria um cluster novo; ele não modifica o original.

Depois do restore-db-cluster-from-snapshot, é preciso criar as instâncias (writer/readers) desse novo cluster via create-db-instance — via CLI, o restore não cria a instância primária automaticamente (isso só acontece se a restauração for feita pelo console). Sem essa etapa, o endpoint do cluster fica parado em status creating.

3. Validar que a criptografia está ativa

aws rds describe-db-clusters \
  --db-cluster-identifier meu-cluster-criptografado \
  --query "*[].{StorageEncrypted:StorageEncrypted}" \
  --output text

O retorno esperado é True.

4. Cutover

Como o restore gera um cluster com endpoint novo, a migração exige uma janela de corte: apontar a aplicação para o novo endpoint e, dependendo da tolerância a perda de dados entre o snapshot e o cutover, reconciliar ou reprocessar as escritas feitas nesse intervalo. Para cenários que não toleram downtime na troca, a AWS documenta uma abordagem alternativa baseada em AWS DMS para migrar dados de um cluster sem criptografia para um cluster criptografado com janela reduzida — mas é um projeto à parte, fora do escopo deste procedimento de snapshot/restore.

5. Descomissionar o cluster antigo

Só depois de validar a aplicação rodando de ponta a ponta contra o cluster novo, encerrar o cluster antigo (mantendo snapshot final, se a política de retenção exigir).

Checklist rápido

• Definir o tipo de chave (AWS managed key vs. customer managed key) antes de restaurar — não dá para trocar depois sem repetir o processo.

• Confirmar que a classe de instância usada não é db.t2.micro/db.t3.micro.

• Medir a janela de cutover e o volume de escrita nesse intervalo antes de decidir entre snapshot/restore direto ou uma abordagem com DMS.

• Validar StorageEncrypted: True via describe-db-clusters antes de liberar produção no cluster novo.

• Manter backups automatizados ativados durante toda a migração.