Uma das surpresas mais comuns em quem configura backup no Amazon S3 pela primeira vez chega no fim do mês seguinte, na fatura: o bucket que deveria estar “quase vazio” cobrando como se tivesse dez vezes mais dados. Na maioria das vezes, o culpado é o versionamento ativado sem uma política de limpeza — cada substituição de arquivo cria uma versão antiga que continua sendo cobrada normalmente, e sem lifecycle rule configurada, elas se acumulam pra sempre.
Antes de subir o primeiro arquivo: escolher a classe de armazenamento certa
O S3 oferece várias classes de armazenamento, e escolher errado é o segundo erro mais comum depois do problema do versionamento:
- S3 Standard: pra dados acessados com frequência — não é a escolha certa pra backup que você espera nunca precisar tocar.
- S3 Intelligent-Tiering: quando você não tem certeza do padrão de acesso; o próprio S3 move os dados entre camadas automaticamente com base no uso real, cobrando uma pequena taxa de monitoramento por objeto.
- S3 Standard-IA (Infrequent Access): bom pra backups que raramente são acessados mas precisam ficar disponíveis rápido se precisar.
- S3 Glacier (e Glacier Deep Archive): a opção mais barata por GB, pensada pra arquivamento de longo prazo — mas com o detalhe importante de que restaurar um arquivo do Glacier não é instantâneo, pode levar de minutos a várias horas dependendo do nível de recuperação escolhido.
Pra backup de rotina de servidores ou bancos de dados, uma combinação comum e que funciona bem na prática é: Standard nos primeiros 30 dias (pra restaurar rápido se algo der errado logo depois do backup), migrando pra Glacier depois disso via lifecycle rule.
Configurando a lifecycle rule (o que realmente evita a surpresa na fatura)
Pelo console da AWS, a configuração fica em Bucket > Management > Lifecycle rules. Mas o jeito mais confiável de replicar isso em vários buckets é via AWS CLI:
aws s3api put-bucket-lifecycle-configuration \
--bucket meu-bucket-de-backup \
--lifecycle-configuration file://lifecycle.jsonUm lifecycle.json básico e funcional, cobrindo os dois problemas mais comuns (versões antigas e uploads incompletos):
{
"Rules": [
{
"ID": "MoverParaGlacierApos30Dias",
"Status": "Enabled",
"Filter": {"Prefix": ""},
"Transitions": [
{"Days": 30, "StorageClass": "GLACIER"}
],
"NoncurrentVersionTransitions": [
{"NoncurrentDays": 30, "StorageClass": "GLACIER"}
],
"NoncurrentVersionExpiration": {"NoncurrentDays": 180},
"AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}
}
]
}A regra AbortIncompleteMultipartUpload é a que praticamente ninguém configura e que sozinha já resolve uma boa fatia dos casos de “cobrança misteriosa” — uploads grandes que falham no meio (queda de conexão, script interrompido) deixam partes órfãs no S3 que continuam sendo cobradas até alguém excluir manualmente, a menos que essa regra faça isso automaticamente.
Versionamento: proteção real contra exclusão acidental, com um porém
Ativar o versionamento do bucket é o que garante que um delete acidental (ou um script de sincronização mal configurado sobrescrevendo tudo) não seja definitivo — o S3 guarda a versão anterior em vez de apagar de verdade. O porém, como já mencionado, é que isso só compensa quando combinado com uma regra de expiração de versões antigas. Versionamento sem lifecycle rule é a receita mais comum pra bucket “vazio” custando caro.
Permissões: o erro que vira manchete
Antes de automatizar qualquer backup pro S3, vale configurar uma política do IAM com o mínimo de permissão necessária — nunca usar as credenciais root da conta AWS num script de backup. Uma policy básica e segura pra essa finalidade concede apenas s3:PutObject, s3:GetObject e s3:ListBucket no bucket específico, nada além disso. Buckets configurados como públicos por engano (geralmente por alguém copiar um exemplo de configuração de “site estático” sem entender o que aquilo implica) já foram responsáveis por vazamentos de dados de empresas grandes — é um erro de configuração simples de cometer e caro de corrigir depois.
Testando antes de confiar
Depois de configurar tudo, vale simular uma restauração de verdade — não só assumir que o backup “deve estar funcionando”. Baixe um arquivo aleatório do bucket, valide que abre corretamente, e monitore o CloudTrail nos primeiros dias pra confirmar que as lifecycle rules estão realmente movendo os objetos como esperado, e não silenciosamente falhando por alguma permissão faltando.
Se o objetivo é ter uma estratégia de backup completa e não só o armazenamento na nuvem, vale complementar com o processo do lado do dispositivo também — nosso guia de backup completo do Android em nuvem cobre a ponta do usuário final, caso o S3 seja usado como repositório central de backups de múltiplos dispositivos numa empresa.
Perguntas frequentes
Qual o custo médio de manter backups no S3 Glacier?
Varia por região, mas Glacier costuma custar uma fração do preço do S3 Standard por GB armazenado — o custo real está mais nas taxas de recuperação e nas requisições do que no armazenamento em si, então backups que você espera nunca (ou raramente) restaurar se beneficiam bastante dessa classe.
Preciso de um script customizado ou dá pra usar uma ferramenta pronta?
Ferramentas como o AWS Backup (serviço gerenciado da própria AWS) cobrem boa parte dos casos sem precisar escrever lifecycle rules manualmente, mas scripts customizados dão mais controle fino sobre prefixos, filtros e frequência.
O S3 substitui um backup local completamente?
Não deveria ser a única cópia. A recomendação clássica de backup (3 cópias, 2 mídias diferentes, 1 fora do local) continua valendo — S3 cobre bem o “fora do local”, mas não substitui ter uma cópia local rápida de acessar em caso de queda de internet.
Como sei se as permissões do meu bucket estão seguras?
O AWS Trusted Advisor e o S3 Access Analyzer, ambos gratuitos ou de baixo custo dentro do console da AWS, apontam automaticamente buckets com acesso público não intencional — vale rodar essa checagem logo depois de qualquer configuração nova.
