1. Introdução

Manter os backups atualizados é muito importante para garantir a recuperação de dados e a continuidade dos serviços nos ambientes. Porém, configurar uma rotina de backup não é suficiente, também é importante acompanhar sua execução e identificar possíveis falhas.

Neste artigo, será implementada uma solução utilizando o AWS Backup para gerenciar os backups de recursos na AWS e integrar o processo a um fluxo de notificações por e-mail. A solução permite automatizar o acompanhamento das operações de backup, reduzindo a necessidade de verificações manuais.

2. Arquitetura da solução

Execução do backup: o AWS Backup utiliza o Backup plan para executar as tarefas programadas e armazena os pontos de recuperação no Backup vault.
Identificação dos eventos: o EventBridge identifica eventos relacionados às tarefas de backup e aplica filtros para selecionar os status que devem gerar notificações.
Envio do e-mail: o evento selecionado aciona o SNS, que encaminha a notificação para o endereço de e-mail inscrito no tópico.

3. Implementação

Pré-requisitos

Para acompanhar a implementação, é necessário ter:

Uma conta AWS com permissões para configurar os serviços utilizados.
Um recurso (neste caso, serão criados uma instância EC2 e uma tabela no banco de dados DynamoDB) para ser utilizado como teste, que seja compatível com o AWS Backup.
Um plano de backup configurado para definir a frequência e as regras de retenção.
Um cofre de backup para armazenar os pontos de recuperação.
Permissões para configurar regras de eventos no EventBridge.
Um tópico do SNS configurado com uma assinatura de e-mail confirmada.

Com esses recursos disponíveis, será possível configurar o fluxo de backup e as notificações.

3.1. Criação dos recursos

O objetivo é preparar os recursos que serão utilizados na solução de backup.

1.Criar uma instância EC2, em “Instances” e “Launch instances” (ex: srv-backup-test):

2.Criar uma tabela do banco de dados (DynamoDB), em “Tables” (ex: db-backup-test):

Deixar o restante como padrão e clicar em “Create table”:

A tabela foi criada com sucesso:

3.2. Configuração do AWS Backup

Opção 1: criação de um plano de backup diário com recursos específicos manualmente, filtrados por ID do recurso.

1.Para criar um cofre, acessar a aba “Vaults” e clicar em “Create new vault”:

2.Definir o nome (ex: bkp-vault-test). Como teste, será utilizada a chave de criptografia padrão da AWS “(default) aws/backup”, em seguida, clicar em “Create vault”:

OBS: em ambientes corporativos, o ideal é criar uma chave de criptografia gerenciada pelo cliente, no AWS KMS, em vez de usar a chave padrão “(default) aws/backup”. Essa chave padrão é gerenciada pela AWS e não pode ser compartilhada com outras contas, por isso não permite copiar backups para outra conta. Com uma chave própria, também é possível controlar quem pode usá-la, por meio da key policy, e auditar o uso dela. Também é recomendado adicionar tags ao cofre para facilitar a organização e o controle de custos do ambiente.

3.O cofre foi criado com sucesso:

4.Em seguida, será necessário criar o plano de backup. Para isso, acessar a aba “Backup plans” e clicar em “Create backup plan”:

5.Na próxima tela, clicar em “Build a new plan”, definir nome do plano (ex: bkp-daily-plan), regra de backup (ex: bkp-daily-rule) e selecionar o cofre criado acima “bkp-vault-test”. Em seguida, definir a frequência diária para este teste (em ambientes corporativos isso varia entre diário, semanal, mensal ou por hora):

6.Em seguida, definir o horário para iniciar o teste e concluir o backup:

7.Neste teste, o tempo de retenção de backup foi definido como 7 dias, mas isso pode variar em ambientes corporativos:

OBS: a opção “Move backups from warm to cold storage” move os backups para uma camada de armazenamento de menor custo, indicada para retenções longas. Os backups precisam permanecer no mínimo 90 dias nessa camada, por isso ela não se aplica neste teste, que usa retenção de 7 dias.

8.Deixar as demais configurações como padrão e clicar em “Create plan”:

O plano foi criado com sucesso:

9.Na etapa seguinte, será necessário associar a instância EC2 (srv-backup-test), a tabela do banco DynamoDB (db-backup-test) e clicar em “Assign resources”.

Instância EC2:

Tabela do banco de dados (DynamoDB):

Os recursos foram adicionados com sucesso:

Os jobs de backup foram realizados com sucesso:

Abaixo, vault:

Opção 2: seleção de recursos por tags (será testado no mesmo plano de backup existente)

Além da seleção manual, também é possível incluir recursos no backup usando tags. Neste exemplo, a instância EC2 e a tabela do DynamoDB recebem a tag “Backup” com o valor “Daily”. O AWS Backup inclui automaticamente qualquer recurso que tenha a tag configurada. Em seguida, o resource assignment “bkp-tag-daily” é adicionado ao mesmo plano criado anteriormente “bkp-daily-plan”.

Por que no mesmo plano? O backup plan define quando o backup acontece e por quanto tempo ele fica guardado. O resource assignment define quais recursos entram nesse backup. Como este é um ambiente de teste e o backup por tag usa a mesma frequência diária e a mesma retenção de 7 dias, não faz sentido criar outro plano, pois muda apenas a forma de selecionar os recursos.

Se a necessidade fosse diferente, por exemplo, um backup semanal ou mensal com retenção maior, o ideal seria criar um novo backup plan com essa política (ex: “bkp-weekly-plan” associado à tag “Backup=Weekly”). Assim cada tag aponta para a política certa.

OBS: quando um mesmo recurso aparece em mais de um backup plan, os planos podem gerar jobs de backup independentes. Por exemplo, uma instância com a tag “Backup=Daily” também incluída manualmente em outro plano diário pode receber dois backups por dia, dois recovery points e possível custo adicional. Por isso, antes de criar um novo plano ou um novo assignment por tag, vale verificar se os recursos já estão protegidos por outro plano. Neste teste isso não acontece, as seleções manuais e por tag estão dentro do mesmo “bkp-daily-plan”, e o recurso é protegido apenas uma vez por regra. Em ambiente corporativo, uma boa prática é que cada recurso pertença a um único plano por política de backup, para evitar sobreposição desnecessária. As tags diferenciam maiúsculas de minúsculas, então, para o AWS Backup, “Backup=Daily” é diferente de “backup=daily” ou “Backup=daily”. Se a tag no recurso não for idêntica à configurada no resource assignment, o recurso fica fora do backup. Por isso, é importante padronizar as tags e conferir com cuidado.

1.Acessar o serviço EC2, instância “srv-backup-test”, na aba “Tags”, clicar em “Manage tags”, “Add new tag” e adicionar a chave “Backup” e valor “Daily”, indicando que será realizado um backup diário neste recurso:

2.Em seguida, repetir o mesmo processo com a tabela “db-backup-test”, no DynamoDB:

3.Para adicionar os recursos via tag, será necessário clicar na opção “Assign resources”, no AWS Backup, definir o nome “bkp-tag-daily”, selecionar todos os recursos de EC2 e DynamoDB e a tag:

Criado com sucesso:

3.3. Configuração do SNS para envio de notificações por e-mail

1.Acessar o SNS e criar um tópico com o e-mail que receberá as notificações. Na aba “Topics”, clicar em “Create topic:

2.Definir um nome (ex: backup-notifications-topic), preencher as informações abaixo, deixar o restante como padrão e clicar em “Create topic”:

3.Após concluir a criação do tópico, clicar em ”Create subscription” para definir o e-mail que irá receber as notificações:

OBS: normalmente, nas empresas, as notificações de backup são enviadas para um e-mail genérico da equipe de infraestrutura. Se o monitoramento for feito por uma empresa terceirizada de NOC, também é possível cadastrar o e-mail da equipe responsável no tópico SNS, para que possa receber as notificações e analisar o ambiente, caso ocorra algum problema.

4.Em seguida, a subscription ficará como pendente, então, será necessário acessar o e-mail cadastrado para confirmar:

Confirmado com sucesso:

3.4. Configuração do EventBridge

1.Acessar o EventBridge para iniciar a configuração:

2.Para criar uma nova regra será necessário clicar em “Create rule”, selecionar a opção “Advanced builder”, definir o nome (ex: BackupsAlerts) e prosseguir:

3.Na tela seguinte, manter as configurações iniciais no padrão, em “Event pattern”, selecionar o método “Use pattern form” e as opções abaixo:

4.Na documentação oficial, é possível visualizar as opções de estado dos jobs de backup. Neste caso, será necessário editar o JSON, clicando em “Edit pattern” e adicionar as opções para filtrar:

COMPLETED: o backup foi concluído com sucesso.
ABORTED: o backup foi cancelado antes de terminar, normalmente por alguém (Stop no console ou StopBackupJob). Se a interrupção vier de um erro, o status costuma ser FAILED.
FAILED: o processo de backup falhou por algum erro, como permissão no IAM, recurso indisponível ou erro no serviço de origem.
EXPIRED: o backup não aconteceu dentro das janelas configuradas na regra. Isso ocorre em dois casos:

1.Janela de início (Start within): o backup não começou a tempo. Por exemplo, em uma rotina agendada às 05h00 com janela de início de 1h, se o backup não tiver começado até às 06h00, ele fica como expirado.

2.Janela de conclusão (Complete within): o backup começou, mas não terminou a tempo. Essa janela é contada a partir do horário agendado.

PARTIAL: o backup foi concluído só em parte. Uma parte dos dados ou dos recursos não foi copiada, por exemplo, quando alguns jobs filhos de um job composto não terminaram.
RUNNING: o backup está em execução.

{ "source": ["aws.backup"], "detail-type": ["Backup Job State Change"], "detail": { "state": ["COMPLETED", "ABORTED", "FAILED", "EXPIRED", "PARTIAL", "RUNNING"] } }

5.Na próxima tela, será necessário configurar o SNS como target (via e-mail). Após selecionar o SNS, informar o tópico criado anteriormente (backup-notifications-topic), deixar as demais configurações conforme o padrão e prosseguir.

6.Neste teste, não será necessário inclur tags. Na próxima tela, revisar e clicar em “Create rule” para concluir:

A regra foi criada com sucesso:

3.5. Criação de um backup para validar a solução

1.Para testar se a notificação será disparada, será necessário criar um backup de teste. Para isso, basta acessar o serviço AWS Backup e na aba “Protected resources” clicar em “Create on-demand backup”:

2.Em seguida, selecionar EC2 (instância criada anteriormente “srv-backup-test”), retenção de 1 dia para teste, selecionar o cofre criado “bkp-vault-test” e prosseguir:

3.Após a criação, o backup ficará em execução:

Logo em seguida, a notificação informando o status “RUNNING” chegou no e-mail, conforme definido na seção anterior. Dessa forma, sempre que algum backup estiver em execução, será disparada uma notificação:
O e-mail informando que o backup foi concluído “COMPLETED” também foi recebido:

OBS: o fuso horário pode ser ajustado no console, para que a rotina execute no horário local correto.

4. Conclusão

Com a solução implementada, os backups dos recursos passam a ser executados automaticamente pelo AWS Backup, de acordo com o plano definido, e qualquer mudança de status dos jobs é comunicada por e-mail via EventBridge e SNS. Dessa forma, não é necessário acessar o console todos os dias para verificar se os backups foram realizados, e eventuais falhas podem ser identificadas e tratadas rapidamente.

Cobrança dos serviços:

AWS Backup: é cobrado por GB/mês de armazenamento dos backups, dados restaurados e transferências entre regiões. https://aws.amazon.com/backup/pricing
Amazon SNS: é cobrado pela quantidade de solicitações de API e de notificações enviadas, que variam conforme o tipo de entrega (e-mail, SMS, HTTPS, etc). https://aws.amazon.com/sns/pricing
Amazon EventBridge: é cobrado pela quantidade de eventos publicados, processados ou invocações, conforme a funcionalidade utilizada. https://aws.amazon.com/eventbridge/pricing
EC2: é cobrado pelo tempo de execução da instância, considerando tipo, sistema operacional e região. Também há cobrança pelo armazenamento dos volumes EBS (GB/mês), mesmo quando a instância está desligada. https://aws.amazon.com/ec2/pricing
DynamoDB: é cobrado por leituras, gravações e armazenamento dos dados, de acordo com modo escolhido (on-demand ou provisioned). https://aws.amazon.com/dynamodb/pricing

OBS: os valores variam de acordo com a região. Para criar uma estimativa correta de custos, é possível utilizar o AWS Pricing Calculator, informando a região, o tipo de recurso, o volume de dados e o tempo de retenção dos backups.

Referências: