AWS Backup: Estratégia de Recuperação Confiável

O Backup que Você Tem vs. O Backup que Você Precisa

Existe uma crença perigosa que se espalha silenciosamente em times de TI: “a AWS já cuida dos meus dados”. E em parte, é verdade a AWS garante a durabilidade da infraestrutura. Mas durabilidade de infraestrutura não é o mesmo que proteção contra deleção acidental, corrupção de dados, falha de aplicação ou ransomware.

Quando um desenvolvedor roda um script errado e apaga uma tabela inteira do DynamoDB às 22h de uma sexta-feira, a AWS não vai restaurar isso para você. Quando um banco de dados RDS é deletado por engano durante uma reorganização de recursos, a janela de recuperação automática tem um limite. Quem protege seus dados, com regras claras de retenção e cobertura de múltiplos serviços, é o AWS Backup.

O problema é que muitas empresas usam o AWS Backup de forma reativa — criando políticas soltas, sem cobertura centralizada, sem teste de recuperação. Este artigo mostra como estruturar isso corretamente em 3 passos.

1. Centralize tudo em um Backup Vault com políticas de retenção definidas

O primeiro erro de quem configura backup na AWS é fazer isso serviço a serviço: configura snapshots automáticos no RDS, configura backup manual no EFS, esquece o DynamoDB, ignora o EBS. O resultado é uma colcha de retalhos onde você nunca sabe exatamente o que está protegido.

O AWS Backup resolve isso com dois conceitos centrais: o Backup Vault (o cofre onde os backups ficam armazenados) e o Backup Plan (o plano que define o que é copiado, quando e por quanto tempo).

Estrutura recomendada de Vaults

Crie pelo menos dois Vaults separados:

• Vault Principal (prod-backup-vault): Recebe os backups da conta de produção. Configurado na mesma região.
• Vault de DR (dr-backup-vault): Recebe cópias dos backups críticos em uma segunda região (ex: us-east-1 como backup de sa-east-1). Isso protege contra falha regional.

Para o Vault de DR, ative o Vault Lock uma configuração que impede que qualquer usuário, inclusive o root, delete ou altere backups antes do período de retenção acabar. Isso é a principal defesa contra ransomware que compromete credenciais da AWS.

Defina retenção por criticidade, não por conveniência

Um erro comum é definir retenção por custo (“vou guardar 7 dias porque é barato”). A retenção precisa ser definida por criticidade do dado e pelo tempo que você levaria para perceber um problema.

Uma estrutura sólida trabalha com três camadas:

• Diário: Retenção de 30 dias. Cobre erros operacionais do dia a dia.
• Semanal: Retenção de 90 dias. Cobre problemas descobertos semanas depois.
• Mensal: Retenção de 1 ano. Cobre requisitos de compliance e auditoria.

O AWS Backup permite empilhar essas regras dentro de um único Backup Plan, aplicado aos mesmos recursos. Você não precisa criar três planos separados.

2. Use Tags para Aplicar Backup em Todos os Recursos Automaticamente

O segundo passo é garantir que nenhum recurso crítico fique de fora — não porque alguém esqueceu de adicioná-lo manualmente, mas porque o próprio sistema identifica automaticamente o que deve ser protegido.

O AWS Backup suporta seleção de recursos por Tag. Em vez de listar individualmente cada instância EC2, banco RDS ou tabela DynamoDB, você cria uma regra que diz: “faça backup de tudo que tiver a tag backup:true“.

Como implementar na prática

Defina um padrão de tags para o seu ambiente. Por exemplo:

• backup:tier = gold → Backup diário + semanal + mensal, retenção máxima, cópia cross-region.
• backup:tier = silver → Backup diário, retenção de 30 dias, sem cross-region.
• backup:tier = bronze → Backup semanal, retenção de 14 dias.

Depois, crie um Backup Plan para cada tier e configure a seleção de recursos por essa tag. A partir daí, quando um novo banco RDS é criado em produção, basta o time adicionar a tag backup:tier = gold para ele entrar automaticamente na política correta.

O que isso elimina

Elimina o problema mais comum em auditorias de backup: o recurso que existe há meses, foi criado por alguém que “ia configurar o backup depois”, e nunca foi configurado. Com seleção por tags, o risco é a ausência da tag, que é muito mais fácil de auditar com AWS Config e alertas do que a ausência de configuração manual.

Serviços cobertos pelo AWS Backup

Vale listar o que o AWS Backup gerencia de forma centralizada, porque a lista é maior do que a maioria imagina: EC2, EBS, RDS, Aurora, DynamoDB, S3, EFS, FSx, Neptune, DocumentDB, Timestream, Redshift, VMware workloads on AWS, e serviços de Storage Gateway.

Um único painel, uma única política, um único lugar para auditar.

3. Teste a Recuperação — Porque Backup Não Testado Não É Backup

Este é o passo que 90% das empresas ignoram até o momento em que precisam do backup de verdade. E quando chegam nesse momento, frequentemente descobrem que o arquivo está corrompido, que a permissão de acesso ao Vault mudou, ou que o processo de restauração leva o triplo do tempo esperado.

Regra de ouro em infraestrutura: Um backup nunca testado é tecnicamente equivalente a não ter backup. A diferença é que um te dá falsa segurança.

Como estruturar testes de recuperação na AWS

O AWS Backup tem uma funcionalidade nativa chamada Restore Testing que automatiza exatamente isso. Você configura um plano de teste que:

1. Seleciona backups recentes (por exemplo, o backup mais recente de cada recurso crítico).
2. Realiza a restauração em uma conta ou ambiente isolado.
3. Valida se a restauração foi concluída com sucesso.
4. Gera um relatório de conformidade.

Configure esse processo para rodar mensalmente nos recursos mais críticos e trimestralmente nos demais. O custo de restaurar um banco de dados em um ambiente de teste uma vez por mês é negligenciável comparado ao custo de uma recuperação de emergência que falha.

Defina e documente o RTO e o RPO

Além de testar se o backup restaura, você precisa saber quanto tempo leva. Dois termos são fundamentais aqui:

• RPO (Recovery Point Objective): Qual é o máximo de dados que você pode perder? Se o RPO é 1 hora, você precisa de backups a cada hora.
• RTO (Recovery Time Objective): Quanto tempo você tem para restaurar? Se o RTO é 4 horas, o processo de restauração precisa caber nesse janela.

Faça a restauração de teste com cronômetro. Se a restauração de um banco RDS de produção leva 6 horas e seu RTO é 4 horas, você tem um problema que nenhum backup resolve — e é melhor descobrir isso no teste mensal do que durante um incidente real.

Conclusão

Uma estratégia de backup confiável na AWS não é sobre ter os snapshots ligados. É sobre cobertura centralizada (sem lacunas), retenção alinhada à criticidade real dos dados, imutabilidade contra ataques e, principalmente, testes regulares que provam que a recuperação funciona quando mais importa.

O AWS Backup oferece todas as ferramentas para isso. O que define se funciona de verdade é como você o configura — não se você o ativou.