S3 parece barato por GB até você acumula anos de logs, backups de pipeline e uploads de usuário sem política. O problema não é o bucket em si — é classe errada para objeto que ninguém abre há meses.
Classes em linguagem direta
| Classe | Quando usar |
|---|---|
| Standard | Acesso frequente, latência baixa |
| Standard-IA | Acesso pouco frequente, recuperação rápida |
| Glacier Instant Retrieval | Arquivo frio, ainda precisa ms de acesso |
| Glacier Flexible / Deep Archive | Backup legal, retenção longa, restore tolera horas |
| Intelligent-Tiering | Padrão de acesso imprevisível — AWS move automaticamente |
Erro clássico: bucket de logs em Standard sem lifecycle — cada GB novo fica no tier mais caro para sempre.
Intelligent-Tiering: vale ou não?
Vale quando:
- Você não sabe o padrão de acesso (dados de produto, analytics, mídia)
- Objetos ficam frios após 30–90 dias sem você querer gerenciar regras manuais
Cuidado:
- Objetos muito pequenos ou de curta vida podem não compensar a taxa de monitoramento
- Para logs com padrão óbvio (quente 7 dias, morto depois), lifecycle explícito costuma ser mais barato e previsível
Lifecycle rules que funcionam na prática
Bucket de logs de aplicação
Dia 0–30 → Standard (ou IA se quase não lê)
Dia 30–90 → Standard-IA ou Glacier Instant
Dia 90+ → Glacier Flexible ou exclusãoBackups de pipeline / dumps SQL
Dia 0–7 → Standard (restore rápido)
Dia 7–365 → Glacier
Dia 365+ → Deep Archive ou delete (conforme compliance)Assets estáticos (site, CDN)
- Objetos servidos via CloudFront: mantenha Standard na origem se tráfego alto.
- Versões antigas de deploy: expire noncurrent versions após 30 dias se versioning estiver ligado.
Versioning: o multiplicador silencioso
Com versioning ativo, deletes viram markers e versões antigas continuam cobrando.
- Ative lifecycle em
noncurrent versions - Audite buckets com versioning sem regra — é fonte comum de “fatura S3 misteriosa”
Request costs e LIST
Storage é metade da história. PUT/COPY/LIST em milhões (Spark, Athena mal particionado, sync tools) geram linha S3 + Request no CUR.
Mitigações:
- Particionar prefixos por data (
logs/year=2026/month=06/) - Evitar
LISTrecursivo em jobs mal escritos - S3 Inventory para saber tamanho por prefixo antes de mover terabytes
Auditoria em 1 hora
- S3 Storage Lens ou relatório por bucket (tamanho + classe).
- Top 5 buckets por custo no Cost Explorer.
- Para cada um: versioning? lifecycle? objetos > 90 dias em Standard?
- Crie regra em staging primeiro; valide com prefixo de teste.
Integração com o resto do FinOps
- Dados em S3 alimentam Athena/Glue — otimizar formato (Parquet) reduz scan e custo de análise, não só storage.
- Backups cross-region duplicam storage e data transfer — veja NAT e data transfer.
Checklist
- Lifecycle em buckets de log?
- Noncurrent versions expiram?
- IA/Glacier para backups antigos?
- Intelligent-Tiering só onde padrão é caótico?
- Storage Lens ou CUR revisado este mês?