CloudWatch é conveniente — e cresce silenciosamente quando cada microserviço loga verbose em prod com retenção infinita. Em contas médias, logs + métricas custom rivalizam com um pedaço relevante de EC2.
O que cobra no CloudWatch (visão FinOps)
| Item | Quando pesa |
|---|---|
| Ingestão de logs | GB/dia alto (JSON verboso, debug em prod) |
| Armazenamento | Retenção longa ou “Never expire” |
| Métricas custom | Alta cardinalidade (tag por user_id) |
| Dashboards e alarms | Muitos alarms com alta frequência |
| Logs Insights queries | Scans grandes em histórico longo |
| Contributor Insights | Regras em volumes enormes |
O vilão #1 em startups: log group sem retention criado pelo Lambda/ECS/EKS default.
Auditoria em 1 hora
- CloudWatch → Log groups → ordene por Stored bytes
- Liste grupos com Retention: Never expire
- Cost Explorer → filtre CloudWatch últimos 30 dias
- Identifique top 5 fontes (Lambda, API Gateway,
/aws/eks/, RDS audit)
Anote dono de cada top group — sem owner, ninguém aprova mudar retenção.
Política de retenção sugerida
| Ambiente | Retenção típica | Notas |
|---|---|---|
| dev | 3–7 dias | Debug liberado com prazo curto |
| staging | 7–14 dias | Suficiente para reproduzir bugs |
| prod (app) | 14–30 dias | Compliance pode exigir mais |
| prod (audit/security) | 90–365+ | Só onde regulatório exige |
Nunca “Never expire” por default em IaC — exija exceção documentada.
Aplicar em massa
- Account-level data protection / retention policies (recursos novos)
- Script boto3 para atualizar log groups legados
- Terraform
aws_cloudwatch_log_groupcomretention_in_days
Reduzir ingestão (na fonte)
Mais barato que pagar storage é não logar lixo:
- Nível
INFOem prod,DEBUGsó temporário com flag - Structured logging (JSON) sem stack trace em todo request 200
- Amostragem de access logs (1 em N requests)
- Remover PII dos logs (reduz risco + tamanho)
Lambda e API Gateway
Lambda cobra por GB ingestado no log group /aws/lambda/.... Funções em loop ou com log verbose custam caro.
- Revisar
console.logem hot path - Powertools / structured log com nível configurável por env
Métricas custom: cardinalidade mata
Criar métrica Errors com dimensão UserId = milhões de valores → custo explode.
- Prefira agregados (p95 latência por serviço, não por usuário)
- EMF (Embedded Metric Format) com cuidado nas dimensões
- Alarms em métricas nativas AWS quando bastarem
Logs Insights vs exportar para S3
Consultas frequentes em terabytes de log custam scan.
- Histórico frio → export to S3 + lifecycle Glacier
- Análise ad hoc → Insights em janela curta
- Analytics pesado → OpenSearch/Athena em S3 (compare TCO)
Integração com S3 e lifecycle
Padrão cost-effective:
App → CloudWatch (retenção curta) → subscription filter → S3 → GlacierArtigo: S3 lifecycle.
Alarms: quantidade e frequência
Mil alarms avaliando a cada 10s geram cobrança e ruído.
- Consolidar alarms por serviço crítico
datapoints to alarm> 1 para evitar flapping- Delete alarms de recursos já destruídos (terraform destroy esquecido no alarm)
EKS e containers
Sidecars de log (Fluent Bit, etc.) duplicam stream se mal configurados.
- Um agent por nó, não por pod quando possível
- Filtrar namespaces de sistema
- Retenção diferente por namespace (dev vs prod)
Checklist CloudWatch FinOps
- Top 10 log groups têm retention definida?
- Nenhum “Never expire” sem aprovação?
- Debug desligado em prod por padrão?
- Métricas custom sem dimensão de alta cardinalidade?
- Alarms órfãos removidos?
- Custo CloudWatch no budget mensal?