Uma empresa que roda workloads em EC2, banco de dados em RDS, arquivos em EFS e objetos em S3 normalmente acaba com três ou quatro mecanismos de backup diferentes — um para cada serviço, cada um com sua própria política de retenção, seu próprio console e, na prática, ninguém com visão completa de quais dados estão realmente protegidos. O AWS Backup existe para resolver exatamente esse problema: é o serviço gerenciado da AWS que centraliza, automatiza e audita o backup de mais de 20 tipos de recurso a partir de um único console, com uma única política. Este guia explica como ele funciona — backup plans, vaults, cross-region, cross-account, Vault Lock — e onde ele termina e uma estratégia de continuidade de negócio começa.
O Que É o AWS Backup: Backup Plans, Vaults e Políticas Centralizadas
O AWS Backup é descrito pela própria AWS como um serviço que permite "configurar políticas de backup e monitorar atividade para seus recursos AWS em um único lugar", eliminando a necessidade de scripts customizados e processos manuais por serviço. Ele não substitui os mecanismos nativos de cada serviço — RDS já tem snapshot automático, EBS já tem snapshot próprio — mas os organiza sob uma única camada de política, agenda e auditoria.
Dois conceitos sustentam tudo: backup plans e backup vaults. Um backup plan define a política em si — com que frequência fazer backup, em que janela executar, quanto tempo reter em armazenamento "quente" antes de migrar para armazenamento "frio" (cold storage) e se deve copiar o backup para outra região ou conta. Um backup vault é o repositório lógico onde os pontos de recuperação (recovery points) ficam armazenados, com sua própria política de acesso baseada em recurso e criptografia via KMS. Um plano pode ter várias regras, e cada regra grava em um vault específico — é assim que uma empresa separa, por exemplo, backups de produção sujeitos a retenção regulatória de sete anos dos backups de homologação com retenção de 30 dias.
A atribuição de recursos a um plano é feita majoritariamente por tag: em vez de listar manualmente cada instância, você associa o plano a tudo que tiver, por exemplo, Environment=production. Isso é o que torna o modelo escalável — um recurso novo criado com a tag correta já nasce coberto pela política, sem intervenção manual.
Vale registrar uma distinção que pega gente de surpresa: para recursos com "full AWS Backup management" (a lista varia por tipo — ver a documentação de disponibilidade por recurso), o backup é criptografado com a chave KMS do próprio vault, não a chave do recurso de origem — uma camada extra de defesa — e o ARN do backup passa a começar com arn:aws:backup em vez do ARN do serviço original, o que permite políticas de acesso específicas para backup, separadas do recurso ativo. A cobrança também aparece consolidada como "Backup" na fatura, em vez de diluída dentro de cada serviço.
Benefícios de Centralizar o Backup em Um Único Serviço
O ganho mais imediato é ter um único painel de auditoria: o console do AWS Backup mostra o status de todos os jobs de backup e restauração entre serviços, integrado a CloudWatch (métricas e alarmes), EventBridge (eventos) e CloudTrail (log de auditoria completo de quem fez o quê). Antes disso, auditar "todos os bancos estão com backup em dia" exigia entrar em RDS, depois em EFS, depois checar os snapshots de EBS manualmente.
O segundo ganho é a redução de custo por incrementalidade: para os tipos de recurso que suportam, o AWS Backup grava o primeiro backup como cópia completa e os seguintes apenas com as mudanças — o que reduz o volume armazenado sem abrir mão da frequência de proteção. Nem todo recurso suporta esse modo; alguns tipos sempre gravam cópia completa, o que é um fator a considerar ao escolher a frequência do plano.
O terceiro é a gestão de ciclo de vida automática: uma regra de backup pode definir, por exemplo, "mantenha em warm storage por 30 dias, depois transicione para cold storage e retenha por mais dois anos" — sem que ninguém precise mover dados manualmente. Isso é particularmente relevante para quem já lida com prazos de ciclo de vida de outros recursos AWS, como o calendário de suporte do RDS Extended Support: governança de dados e governança de versão andam juntas.
AWS Backup vs. Scripts Manuais e Backup Nativo Por Serviço
A alternativa real ao AWS Backup não costuma ser "não fazer backup" — é continuar usando o que cada serviço já oferece nativamente (snapshot de EBS, snapshot automático de RDS, versionamento de S3) orquestrado por script próprio, ou contratar uma solução de terceiros como Veeam ou Acronis operando sobre a nuvem AWS. As três abordagens resolvem o problema de proteção de dados, mas com trade-offs diferentes:
| Critério | Scripts/snapshots nativos por serviço | AWS Backup | Backup de terceiros (Veeam, Acronis etc.) |
|---|---|---|---|
| Console único para todos os recursos | Não — um lugar por serviço | Sim, nativo | Sim, mas com agente/gateway adicional |
| Política centralizada por tag | Precisa ser construída à mão | Nativa | Depende do produto |
| Cobertura cross-region/cross-account | Exige automação própria (Lambda, EventBridge) | Nativa, dentro do backup plan | Depende do produto, geralmente add-on |
| Imutabilidade (WORM) | Não nativa — depende do serviço | Backup Vault Lock, nativo | Depende do produto |
| Custo de licença adicional | Nenhum, além do armazenamento | Nenhum, paga-se por uso | Licença do fabricante + armazenamento |
| Curva de operação para quem já usa IAM/CLI da AWS | Baixa, mas fragmentada | Baixa, unificada | Média — nova ferramenta a operar |
| Backup híbrido (on-premises) ou múltiplas nuvens | Depende de solução própria | Limitado (Storage Gateway, VMware Cloud) | Ponto forte típico desses produtos |
A conclusão não é "AWS Backup sempre vence". Empresas com ambiente exclusivamente AWS e que já usam IAM/Organizations tendem a preferir o AWS Backup pela ausência de licença extra e pela integração nativa. Empresas com ambiente híbrido real — parte on-premises, parte em outra nuvem — costumam continuar precisando de uma ferramenta de terceiros com alcance multi-plataforma, e usar o AWS Backup como camada complementar só para a parcela que já está na AWS.
Cross-Region e Cross-Account: Backup Além de Uma Conta e Uma Região
Um backup guardado na mesma conta e na mesma região do recurso original protege contra corrupção de dado e erro de aplicação, mas não contra a perda completa da conta ou uma falha regional. É para isso que existem os recursos de Cross-Region backup e cross-account backup.
O Cross-Region backup permite copiar backups para outras regiões AWS, sob demanda ou automaticamente como uma ação dentro do próprio backup plan (uma "copy action" anexada à regra). A documentação oficial descreve esse recurso como particularmente relevante para empresas com requisito de continuidade de negócio ou compliance que exige manter cópias a uma distância geográfica mínima da produção.
O modelo cross-account funciona em duas camadas, e a distinção entre elas importa na prática. A primeira é gestão cross-account: usando o AWS Organizations, é possível aplicar políticas de backup centralizadamente a todas as contas de uma unidade organizacional, sem precisar duplicar planos conta por conta. A segunda é a cópia cross-account de fato: copiar o próprio recovery point para um vault em outra conta dentro da organização — o padrão de "fan-in/fan-out" que a AWS descreve na documentação de cross-account, consolidando backups de várias contas em uma conta dedicada de backup, e depois distribuindo cópias para maior resiliência. Ambos exigem uma estrutura de AWS Organizations já configurada — não é um recurso disponível para contas isoladas.
Um erro comum de arquitetura: tratar cross-region como suficiente para isolar um comprometimento de credenciais. Se o backup cross-region continua na mesma conta que foi comprometida, o atacante com acesso de administrador ainda alcança os dois. Separar a cópia em uma conta de backup dedicada, com permissões restritas e idealmente com Vault Lock ativo, é o que de fato isola o backup do raio de ação de um incidente na conta de produção.
AWS Backup Vault Lock: Imutabilidade Contra Ransomware e Erro Humano
Ransomware moderno não criptografa só a produção — ele mira os backups primeiro, porque um backup íntegro é o que permite recusar pagar o resgate. O AWS Backup Vault Lock existe para fechar essa porta: é um recurso opcional de um backup vault que impõe um modelo WORM (write-once, read-many), impedindo que qualquer usuário — incluindo o usuário root da conta, e incluindo a própria AWS — apague ou altere o período de retenção de um recovery point enquanto o lock estiver ativo.
Existem dois modos, e a diferença entre eles é a diferença entre governança interna e proteção contra comprometimento total da conta:
- Modo governance: o vault pode ser gerenciado ou desbloqueado por usuários com permissões de IAM suficientes. Serve para impedir alterações acidentais ou de usuários sem privilégio, mas não protege contra um administrador comprometido.
- Modo compliance: uma vez expirado o período de carência (grace time, no mínimo 3 dias/72 horas e configurável em CLI via
--changeable-for-days), o vault e seu lock tornam-se imutáveis — não podem ser alterados ou removidos por ninguém, nem pela própria AWS, enquanto contiverem recovery points. O período máximo de retenção configurável chega a 36.500 dias (aproximadamente 100 anos), o suficiente para qualquer exigência regulatória de longuíssimo prazo.
Um detalhe que custa caro se ignorado: recovery points com retenção definida como "Always" (sempre) dentro de um vault em modo compliance ficam retidos para sempre depois que a carência expira — não há como reverter isso, nem excluindo a conta AWS (o encerramento de conta suspende por 90 dias antes de apagar o conteúdo, mesmo com Vault Lock ativo). Configurar o período de retenção corretamente antes de travar o vault não é um detalhe operacional, é a diferença entre proteção e custo de armazenamento perpétuo não planejado.
O Vault Lock também se combina com o AWS Backup Audit Manager, que fornece controles prontos e customizáveis para checar automaticamente a conformidade dos backups contra as políticas da organização — por exemplo, o controle "recursos estão em um backup plan com um Vault Lock associado" — gerando relatórios diários que servem como evidência de conformidade para auditoria, e que podem ser importados para o AWS Audit Manager corporativo.
Quanto Custa o AWS Backup: Armazenamento, Restauração e Auditoria
O modelo de cobrança do AWS Backup tem quatro componentes, segundo a página oficial de preços: armazenamento do backup, dados restaurados, teste de restauração e transferência de dados entre regiões — além da cobrança específica do Backup Audit Manager. Não há taxa de licença ou assinatura: paga-se por uso.
O armazenamento é cobrado por GB-mês, com diferença significativa entre warm storage (tarifa padrão) e cold storage (tarifa reduzida, mas com retenção mínima obrigatória de 90 dias — mover um backup para cold storage e excluí-lo antes disso gera cobrança de exclusão antecipada). A própria documentação da AWS usa como exemplo ilustrativo uma tarifa de aproximadamente US$ 0,05 por GB-mês em warm storage para EFS contra cerca de US$ 0,015 por GB-mês em cold storage para EBS — a proporção entre as duas é o que importa, não o valor absoluto, porque cada região e cada tipo de recurso tem sua própria tabela.
A restauração também é cobrada por volume de dados restaurado, medido em GB — a documentação cita como exemplo US$ 0,02 por GB restaurado a partir de warm storage no caso do EFS, com cold storage tipicamente mais caro por GB restaurado. Isso significa que um plano de testes de restauração recorrente (boa prática de qualquer estratégia de backup) tem custo variável proporcional ao volume testado, e deve entrar na conta do orçamento, não ser tratado como custo zero.
A transferência de dados cross-region é cobrada por GB transferido para fora da região de origem, com tarifas que variam por grupo de tipo de recurso — a documentação categoriza os recursos em grupos com preços distintos por GB. Nenhum desses números deve ser usado como orçamento direto para a região de São Paulo: a tabela real, por região, está sempre em aws.amazon.com/backup/pricing. O que vale generalizar é a mecânica: o custo cresce com volume retido e com frequência de cópia cross-region, não com o número de recursos protegidos — dez instâncias pequenas com retenção curta podem custar menos que uma instância grande com retenção de anos.
Esse tipo de custo que cresce silenciosamente enquanto ninguém revisita a política de retenção é exatamente o que uma prática de FinOps na AWS deveria capturar — revisar retenção de backup é item de checklist recorrente, não tarefa única.
Casos de Uso por Porte de Empresa
Para empresas de 30 a 100 funcionários, o padrão mais comum é um backup plan único, com regras separadas por criticidade de tag (production vs. staging), cross-region para os recursos mais críticos e sem necessidade imediata de estrutura multi-conta — o ganho principal aqui é sair de scripts fragmentados e ganhar auditoria centralizada sem aumentar o time.
Para empresas de 100 a 300 funcionários, normalmente já operando algum nível de AWS Organizations, o cross-account começa a fazer sentido: uma conta de backup dedicada, separada da conta de produção, com Vault Lock em modo governance para as cargas internas e compliance para os dados sujeitos a exigência regulatória (dados financeiros, de saúde, de RH). É também o ponto em que o Backup Audit Manager passa a valer o esforço de configuração — o volume de recursos já dificulta a auditoria manual.
Para empresas acima de 300 funcionários, com múltiplas contas AWS e exigências de compliance formais (LGPD, contratos com cláusula de retenção, certificações setoriais), o padrão passa a incluir gestão cross-account centralizada via Organizations, Vault Lock em modo compliance como política padrão para produção, e revisão trimestral dos controles do Audit Manager como parte do processo de auditoria interna — nesse porte, quem cuida da política de banco de dados terceirizada também precisa estar na mesma mesa que decide a política de backup, porque as duas convergem em governança de dados.
AWS Backup Não É Disaster Recovery: Onde Termina o Backup e Começa a Continuidade de Negócio
É comum confundir os dois, e a confusão custa caro na hora de definir prioridade de projeto. O AWS Backup é a ferramenta operacional que garante que existe uma cópia recuperável dos dados — automatizada, auditável, com retenção definida. Ele responde à pergunta "se um recurso for corrompido, apagado ou sequestrado por ransomware, existe uma cópia íntegra para restaurar?".
O Disaster Recovery multi-região responde a uma pergunta diferente e mais ampla: "se uma região inteira da AWS ficar indisponível, minha operação continua funcionando, e em quanto tempo?". Isso envolve replicação ativa de infraestrutura, roteamento de tráfego, e as estratégias de pilot light, warm standby ou multi-site ativo-ativo que tratamos em detalhe no guia de Disaster Recovery na AWS: Estratégias Multi-Região. O AWS Backup pode ser (e deveria ser) um componente dessa estratégia — os backups cross-region alimentam o processo de recuperação —, mas ele sozinho não substitui um plano de DR: restaurar um banco a partir de um backup em outra região ainda significa reconstruir a infraestrutura ao redor dele, o que normalmente leva muito mais tempo do que um failover para um ambiente já ativo.
Na prática, a maioria das empresas de porte médio não precisa das duas estratégias com o mesmo nível de investimento. O AWS Backup bem configurado — com cross-region, Vault Lock e testes de restauração regulares — já cobre a maior parte dos cenários reais de perda de dados (erro humano, corrupção, ransomware). O investimento pesado em DR ativo-ativo se justifica quando a tolerância a indisponibilidade é medida em minutos, não em horas — um cálculo de RTO que vale a pena fazer antes de escolher onde investir primeiro, e é exatamente o tipo de decisão que se apoia em uma leitura honesta do AWS Well-Architected Framework, no pilar de confiabilidade.
Tendências: Auditoria Contínua e IA na Proteção de Dados
A direção clara do AWS Backup nos últimos anos é sair do backup como tarefa passiva e se tornar parte ativa da postura de segurança. O Backup Audit Manager, com seus controles automatizados e relatórios diários, é a materialização disso: a pergunta deixa de ser "fizemos backup ontem?" e passa a ser "todos os recursos que deveriam estar protegidos, segundo a política que definimos, estão de fato cobertos, agora?" — uma verificação contínua, não um checklist mensal.
A integração cada vez mais próxima com EventBridge e CloudWatch também aponta para automação de resposta: alertas de job de backup falho disparando remediação automática, sem depender de alguém revisando o console manualmente. E a ampliação constante da lista de recursos suportados — de bancos relacionais tradicionais a serviços mais recentes como Aurora DSQL e clusters EKS — mostra que a AWS está tratando o AWS Backup como a camada de proteção padrão para qualquer novo serviço de dados que lança, não como um produto à parte.
Perguntas Frequentes sobre AWS Backup
O AWS Backup substitui os snapshots nativos de EBS e RDS?
Não substitui a tecnologia por trás — para muitos recursos, o AWS Backup usa a mesma infraestrutura de snapshot que o serviço já oferece nativamente. O que ele adiciona é uma camada de política, agendamento, retenção e auditoria centralizada sobre esses mecanismos, além de recursos que os snapshots nativos isolados não têm, como cross-account e Vault Lock.
Preciso do AWS Organizations para usar o AWS Backup?
Não para o uso básico dentro de uma única conta. O AWS Organizations só é pré-requisito para os recursos de gestão cross-account e cópia cross-account — aplicar políticas centralizadamente a várias contas ou copiar backups para uma conta de backup dedicada.
O Vault Lock em modo compliance pode ser desfeito em algum momento?
Só durante o período de carência (grace time, mínimo de 3 dias), antes de o lock se tornar definitivo. Depois disso, nem o usuário root da conta nem a AWS conseguem alterar ou remover o lock enquanto houver recovery points no vault — por isso a configuração de retenção precisa ser revisada com cuidado antes de travar.
Qual a diferença entre warm storage e cold storage no AWS Backup?
Warm storage é o armazenamento padrão, com custo por GB-mês mais alto, mas sem restrição de tempo mínimo. Cold storage tem custo por GB-mês mais baixo, mas exige retenção mínima de 90 dias — excluir um backup em cold storage antes desse prazo gera cobrança de exclusão antecipada. A transição entre os dois pode ser automatizada dentro do próprio backup plan.
O AWS Backup cobre ambientes híbridos ou apenas recursos nativos da AWS?
A cobertura de fora da AWS é limitada — existe suporte a volumes do AWS Storage Gateway e a VMware Cloud on AWS, mas não é uma ferramenta pensada para backup de infraestrutura on-premises isolada ou de outros provedores de nuvem. Empresas com ambiente híbrido real costumam manter uma ferramenta de terceiros para essa parcela e usar o AWS Backup para a carga que já roda nativamente na AWS.
O AWS Backup é suficiente como plano de recuperação de desastres?
Sozinho, não. Ele garante que existe uma cópia íntegra e recuperável dos dados, inclusive em outra região — mas restaurar a partir de um backup ainda exige reconstruir a infraestrutura ao redor, o que costuma levar mais tempo do que um failover para um ambiente de disaster recovery já ativo. Para tolerância a indisponibilidade medida em minutos, é necessário combinar o AWS Backup com uma estratégia de DR multi-região.
Como sei se estou pagando mais do que deveria pelo AWS Backup?
Três sinais práticos: retenção configurada acima do que a política da empresa exige, backups em warm storage que já poderiam estar em cold storage, e cópias cross-region habilitadas para recursos que não têm requisito real de continuidade regional. Revisar esses três pontos trimestralmente costuma capturar a maior parte do desperdício, sem reduzir a proteção real.
O AWS Backup É a Base — Não o Teto — da Estratégia de Proteção de Dados na AWS
Centralizar backup plans, vaults, cross-region, cross-account e imutabilidade em um único serviço gerenciado tira a proteção de dados da lista de tarefas fragmentadas por serviço e coloca sob uma política única, auditável e automatizada. É o alicerce sobre o qual qualquer estratégia mais ampla de resiliência — incluindo disaster recovery multi-região — deveria ser construída, não um substituto para ela.
Empresas que tratam o AWS Backup como configuração de política, com retenção revisada, Vault Lock ativo onde faz sentido e testes de restauração regulares, chegam ao momento de um incidente com uma pergunta já respondida. As que tratam backup como "o job que roda sozinho" descobrem, no pior momento possível, se a resposta era mesmo sim.
Artigos Relacionados
- Disaster Recovery na AWS: Estratégias Multi-Região — o AWS Backup garante a cópia dos dados; este guia mostra como estruturar a continuidade de operação quando uma região inteira falha, o passo além do backup.
- O Guia Definitivo para a Gestão de Backup e Recuperação de Dados na Era da Resiliência Cibernética — cobre a estratégia de backup de forma independente de fornecedor (regra 3-2-1-1, RPO/RTO); aqui está a implementação prática dessa estratégia com a ferramenta nativa da AWS.
- FinOps AWS: o Guia Completo para Reduzir Custos na Nuvem — retenção de backup mal revisada é um dos custos silenciosos mais comuns na fatura AWS; aqui está como capturar esse tipo de desperdício sistematicamente.
- RDS Extended Support: o Guia Completo do Ciclo de Vida de Versões do Amazon RDS — antes de qualquer upgrade de versão maior de banco de dados, validar o ponto de restauração do AWS Backup é o primeiro passo de segurança.
