Replicação de backup entre diferentes regiões e contas da AWS

18/06/2025 Arthur Nycael

Como replicar dados entre regiões e contas sem complicação

Quem já mexeu com AWS sabe: backup não é só “tirar uma cópia” e pronto. A real é que, quando bate um problema mais sério, tipo uma falha regional ou até mesmo um desastre mais pesado, é aí que a gente descobre se a estratégia de proteção de dados estava bem pensada ou não. E isso é mais comum que você imagina.

Neste artigo, vou mostrar uma solução prática de replicação de backups entre contas e regiões diferentes da AWS. A ideia é garantir que, mesmo se o ambiente principal cair, você ainda tenha como restaurar seus dados e manter o negócio rodando. Nada de teoria complicada: aqui é mão na massa, direto ao ponto

Arquitetura

Pré-requisitos

Duas contas AWS diferentes:

Conta PRD: Norte Virginia
Conta DR: São Paulo

Procedimento Técnico

Etapa 01 – Criar a CMK Multi-Region (conta DR)

Entre na conta de DR (região São Paulo)

Na barra de pesquisa, procure pelo serviço KMS

Acesse o serviço KMS e cloque em Create key

Preencha as seguintes informações:

Tipo: Symmetric
Uso: Encrypt and decrypt
Marque: Multi-Region key

Dê um nome e uma descrição para a chave de criptografia

Em Key administrators encontre e selecione o seu usuário/role administrativo da conta DR (São Paulo)

Em Key usage permissions: encontre e selecione novamente o seu usuário/role

Já especifique o ID da conta de PRD aqui e clique em Next.

Não altere a política da chave, que foi gerada automaticamente e clique em Next

Na tela re revisão, ao final da tela clique em Finish

Finalize a criação

Etapa 02 – Criar réplica da chave de criptografia (CMK) com a região de N. Virginia

Ainda na conta de DR (São Paulo) e no serviço KMS, abra a chave criada

Selecione na Aba Regional replicas e clique em Create replica key

Selecione a Região: US East (N. Virginia) e clique em next.

Clique em “Skip to Review” para chegar a tela final, não será necessário alterar nenhuma informação a mais.

Na tela da chave, agora você pode observar que a réplica da chave está sendo criada na outra região

Etapa 03 – Ajustar política da chave de criptografia (CMK)

Ainda com a chave de criptografia (CMK) aberta, na aba Key policy e clique no botão Switch to policy view

Vamos conferir que a política tenha as permissões para

Conta DR (admin)
Conta PRD
Serviço: backup.amazonaws.com

Aqui vou deixar um exemplo mínimo da política, mas não se limitanto a ela, ok?

{
  "Version": "2012-10-17",
  "Id": "key-consolepolicy-3",
  "Statement": [
    {
      "Sid": "Enable IAM User Permissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::10xxxxxx2434:root"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "Allow access for Key Administrators",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::10xxxxxx2434:user/ar7-lab-dr"
      },
      "Action": [
        "kms:Create*",
        "kms:Describe*",
        "kms:Enable*",
        "kms:List*",
        "kms:Put*",
        "kms:Update*",
        "kms:Revoke*",
        "kms:Disable*",
        "kms:Get*",
        "kms:Delete*",
        "kms:TagResource",
        "kms:UntagResource",
        "kms:ScheduleKeyDeletion",
        "kms:CancelKeyDeletion",
        "kms:ReplicateKey",
        "kms:UpdatePrimaryRegion",
        "kms:RotateKeyOnDemand"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowUseOfKeyByDRAndPRDAccounts",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::29xxxxxx3379:root",
          "arn:aws:iam::10xxxxxx2434:user/ar7-lab-dr"
        ]
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowGrantsForAWSBackupServiceFromPRD",
      "Effect": "Allow",
      "Principal": {
        "Service": "backup.amazonaws.com"
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:CreateGrant",
        "kms:DescribeKey"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "29xxxxxx3379"
        }
      }
    },
    {
      "Sid": "AllowAttachmentOfPersistentResources",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::29xxxxxx3379:root",
          "arn:aws:iam::10xxxxxx2434:user/ar7-lab-dr"
        ]
      },
      "Action": [
        "kms:CreateGrant",
        "kms:ListGrants",
        "kms:RevokeGrant"
      ],
      "Resource": "*",
      "Condition": {
        "Bool": {
          "kms:GrantIsForAWSResource": "true"
        }
      }
    }
  ]
}

O print representa um trecho da política criada automaticamente. Confira se este trecho esta bem similar a esta (do print).

Observação: Sem isso o backup copia, mas o restore falha.

Etapa 04 – Criar Backup Vault (conta DR São Paulo)

Ainda na conta de DR (São Paulo), na barra de pesquisa, procure pelo serviço AWS Backup

No menu esquedo, selecione a opção Vaults e cloque em Create logically air-gapeed vault

Insira um novo para o Vault, no meu caso aqui foi dr-airgapped-vault e também selecionei ao tipo do cofre como Logically air-gapped vault

Selecione a chave de crptografia customizada do KMS (criado na etapa anterior)

Clique em Create loagically air-gapped vaul para criar o cofre

Etapa 05 – Compartilhar o vault com a conta PRD (via AWS RAM)

Ainda na conta AWS DR (São Paulo), na barra de pesquisa procure pelo serviço RAM

Clique em Create resource share

Preencha:

Nome do compartilhamento do recurso: share-dr-backup-vault
Tipo do recurso: Backup vault
Selecione o recurso (vault): dr-airgapped-vault

As permissões padrão irão nos atender super bem, neste caso clique em Next.

Preencha:

Principals type: AWS Account
Insira o Account ID da conta PRD e clque em Add
Selecione o principal ID (que é o ID da conta de PRD Norte Virginia)

Clique em Next.

Revise e clique “Create resource share” para criar o compartilhamento do recurso.

Etapa 07 – Valiar o vault compartilhado dentro da conta PRD (Norte Virginia)

Na conta PRD, vamos aceitar o convite do recurso compartilhado através do AWS RAM

Na barra de pesquisa, procure por RAM

No menu esquedo, na sessão Shared witg me, selecione a opção Resource shares e clique no recurso

Seleciona a opção Accespt resource share e depois clique no botão Accept

Agora é possível ver que o cofre de backup esta compartilhado corretamente com a conta PRD (Norte Virginia)

Etapa 08 – Criação de instancia EC2

Nesta etapa vamos criar uma instancia EC2, vinculando a chave de criptografia criada na conta de DR ao volune EBS

Ainda na conta de PRD (Norte Virginia), na barra de pesquisa, procure pelo serviço EC2

Sub-etapas sumarizadas:

Launch instance
AMI: Amazon Linux 2
Instance type: t3.micro (laboratório)
Storage
- Volume root:
  - Encryption: Enabled
  - KMS key: Selecione alias/dr-backup-mrk (especificar o ARN da chave de criptografia manualmente, exemplo: arn:aws:kms:us-east-1:10xxxxxx2434:key/mrk-fec55f0d30f648edb6b5d0800ea06cdb)
Finalize a criação da instância

Observação: Não use a chave de criptografia padrão da so serviço vinculado a conta PRD. Ela tem um alias “aws/ebs”

Etapa 09 – Criar um plano de backup na conta PRD

Na barra de pesquisa, procure pelo serviço AWS Backup

No menu esquerdo, selecione a opção Backup plans e depois clique no botão Create backup plan

Selecione a opção Build a new plan e dê um nome para o plano de backup. Eu utilizei aqui o nome prd-to-dr-backup-plan

Agora vamos configurar a regra principal do backup, preenchendo as seguintes informações:

Rule name: daily-backup
Backup vault: Default ou um vault local
Schedule: Daily
Lifecycle: Conforme desejar

Na opção Copy to destination, vamos selecionar a região de São Paulo, marcar a opção que permite a cópia para outra conta AWS e por último insira o ARN do vaul de backup da conta AWS DR (que criamos em etapas anteriores)

Clique em Salvar.

Acesse para ver os detalhes do Plano de backup “daily-backup”, e você pode observar que tem a configuração de cópia do backup para outra região e conta AWS.

Etapa 10 – Associar a instancia EC2 ao plano de backup

No Backup plan, selecione a opção Assing resources

Utilize o método de seleção que melhor enteder, seja por ID do recurso ou por alguma tag específica.

Selecione a instancia EC2, se escolheu por ID do recurso e clique em concluir.

Etapa 11 – Valiação

Aguarde o job de backup executar automaticamente, para que a cópia secundária aconteça. Nos meus testes aqui, quando eu gero um backup sob demanda (on-demand backup), por algum motivo que ainda naõ descobri, a cópia do backup para a conta AWS de DR (São Paulo) não inicia. Se souver o motivo, deixe ai nos comentários.

De qualquer forma, a expectativa é que a rotina de backup completa com sucesso.

Conclusão

No fim das contas, backup é aquele tipo de coisa que a gente só lembra quando dá problema. E é justamente por isso que pensar em replicação entre regiões e contas faz toda a diferença: você não fica refém de uma falha regional e garante que seus dados estejam sempre seguros. Essa estratégia é como ter um plano B guardado na manga, simples de implementar e capaz de salvar o dia quando o inesperado acontece. Afinal, dormir tranquilo sabendo que seus dados estão protegidos não tem preço.

Despedida e agradecimentos.

Espero ter ajudado. Deixe seu feedback nos comentários logo abaixo, não esqueça de se inscrever, compartilhe nas redes sociais e fique ligado nas novidades. Abraços!

Ar7 Technology