Como configurar ciclo de vida no Amazon S3: Intelligent-Tiering, Glacier e expiração na prática

Se você administra bucket de logs de aplicação, backup de banco ou dados de data lake, provavelmente já viu a fatura do S3 crescer mês a mês sem ninguém apagar nada. A causa mais comum não é volume de dado novo: é dado velho parado em STANDARD que ninguém mais acessa, mas que também ninguém configurou para sair dali. É pra esse cenário que existe o S3 Lifecycle, e neste tutorial eu mostro como configurar as três peças que mais resolvem esse problema: transição para INTELLIGENT_TIERING, arquivamento em Glacier e expiração automática.

O que o Lifecycle faz (e o que ele não faz)

Uma configuração de lifecycle no S3 é um conjunto de regras com dois tipos de ação possíveis, segundo a documentação da AWS: transição, que move o objeto para outra storage class depois de X dias, e expiração, que apaga o objeto depois de X dias. Não existe uma terceira opção de "congelar" ou pausar: ou o objeto muda de classe, ou ele morre.

Um detalhe que pega gente de plantão: não dá para usar bucket policy para bloquear uma ação de lifecycle. A documentação é explícita nisso: mesmo que sua bucket policy negue todas as ações para todos os principals, a regra de lifecycle continua rodando normalmente.

Pré-requisitos

Você vai precisar de:

• Um bucket já existente (vou usar meu-bucket-logs nos exemplos, na região sa-east-1)
• AWS CLI configurado com um profile que tenha a permissão s3:PutLifecycleConfiguration no bucket
• Versionamento ativado no bucket, se você também quiser tratar versões antigas (não é obrigatório, mas é comum em bucket de backup)

Confira a versão da CLI com aws --version; qualquer versão 2.x recente suporta os comandos abaixo.

Passo 1: desenhar o ciclo de vida do dado antes de escrever JSON

Antes de abrir o editor, responda três perguntas sobre o dado que está no bucket:

1. Por quantos dias ele é acessado com frequência?
2. Depois disso, por quanto tempo precisa ficar acessível, mas raramente?
3. Existe uma data a partir da qual ele pode (ou deve, por compliance) ser apagado?

Para um bucket de logs de aplicação, um padrão típico é: acesso frequente nos primeiros 30 dias, acesso raro por mais 60 dias, e expiração aos 365 dias. É esse padrão que vou usar no exemplo.

Passo 2: escrever a configuração de lifecycle

Crie um arquivo lifecycle.json:

{
 "Rules": [
 {
 "ID": "logs-ciclo-completo",
 "Filter": { "Prefix": "logs/" },
 "Status": "Enabled",
 "Transitions": [
 {
 "Days": 30,
 "StorageClass": "STANDARD_IA"
 },
 {
 "Days": 90,
 "StorageClass": "GLACIER"
 }
 ],
 "Expiration": {
 "Days": 365
 },
 "NoncurrentVersionExpiration": {
 "NoncurrentDays": 30
 }
 }
 ]
}

Repare na ordem dos Transitions: primeiro STANDARD_IA aos 30 dias, depois GLACIER aos 90 dias, do acesso mais frequente para o mais raro. O NoncurrentVersionExpiration só faz sentido se o bucket tiver versionamento ligado.

Aplique a regra:

aws s3api put-bucket-lifecycle-configuration \
 --bucket meu-bucket-logs \
 --lifecycle-configuration file://lifecycle.json \
 --region sa-east-1

Passo 3: quando usar Intelligent-Tiering em vez de regra manual

A regra acima funciona bem quando você conhece o padrão de acesso do dado. O problema é quando você não conhece — um bucket compartilhado entre times, por exemplo, onde parte dos objetos é acessada todo dia e outra parte nunca mais é tocada. Nesse caso, a transição manual para STANDARD_IA/GLACIER é um tiro no escuro: você corre o risco de mover pra Glacier um objeto que alguém ainda consulta, e aí paga retrieval e espera horas pra recuperar.

A alternativa é transicionar direto para INTELLIGENT_TIERING desde o dia 0:

{
 "Rules": [
 {
 "ID": "dados-compartilhados-it",
 "Filter": { "Prefix": "datalake/" },
 "Status": "Enabled",
 "Transitions": [
 {
 "Days": 0,
 "StorageClass": "INTELLIGENT_TIERING"
 }
 ]
 }
 ]
}

O INTELLIGENT_TIERING existe justamente para esse cenário em que você não conhece o padrão de acesso do dado, sem você precisar adivinhar nada (a própria documentação remete a um artigo separado, "Understanding and managing Amazon S3 storage classes", para quem quiser entender em detalhe como essa classe gerencia o dado internamente). Em resumo: se você sabe o padrão de acesso, regra manual com STANDARD_IA/GLACIER é mais barata; se não sabe, INTELLIGENT_TIERING evita que você pague retrieval por engano.

Verificando que a regra está ativa

Confirme o que foi aplicado:

aws s3api get-bucket-lifecycle-configuration \
 --bucket meu-bucket-logs \
 --region sa-east-1

O retorno deve espelhar o JSON que você enviou. Lifecycle não é instantâneo: pode levar algum tempo até a transição ou expiração ser executada de fato, então não espere ver objetos mudando de classe minutos depois de criar a regra. Para acompanhar o efeito real ao longo do tempo, a própria documentação da AWS tem um artigo dedicado a isso (monitorar as ações tomadas pelas regras de lifecycle), em vez de ficar checando objeto por objeto no console.

Os tropeços que pegam todo mundo

Três comportamentos de cobrança não são óbvios e vale ter na cabeça antes de rodar isso em produção:

• A cobrança muda assim que o objeto fica elegível, mesmo que o S3 demore pra executar a transição de fato — exceto para INTELLIGENT_TIERING, cujo billing só muda quando a transição efetivamente acontece.
• Transição tem custo de ingestão por request (o mesmo tipo de cobrança de um PUT ou COPY), então mover milhões de objetos pequenos pode custar mais do que parece à primeira vista. Não há cobrança de retrieval na transição em si, só na hora de ler o objeto de volta depois.
• Classes com duração mínima de armazenamento (como Glacier) cobram a diferença se você apagar ou transicionar o objeto antes do prazo mínimo — é o chamado minimum storage duration charge, e ele existe justamente pra desincentivar mover objeto pra lá e tirar de novo em poucos dias.

Um erro que eu cometeria (e que a documentação avisa) é esquecer que, quando um objeto tem annotations associadas — metadados anexados separadamente do objeto — elas continuam sendo cobradas em STANDARD independentemente da classe do objeto principal, e são apagadas junto quando a expiração dispara.

O que fazer antes de aplicar em produção

Teste a regra num bucket ou prefixo pequeno antes de aplicar no bucket inteiro. Use Filter com Prefix para escopar a regra a uma pasta específica, confirme com get-bucket-lifecycle-configuration que o JSON foi aceito sem erro, e espere pelo menos um ciclo de avaliação antes de assumir que a regra não funcionou. Se a transição não aconteceu como esperado, vale revisitar a documentação de troubleshooting de lifecycle da AWS antes de assumir que algo quebrou: não adianta ficar atualizando o console esperando o objeto mudar de ícone.

Fonte: Documentação do Amazon S3 — Lifecycle