Todo líder de engenharia já passou por aquele momento de choque no dia 5 do mês: abrir o AWS Cost Explorer e descobrir que o faturamento não explodiu por causa de instâncias EC2 gigantes ou de um pico de tráfego no banco de dados. O grande vilão escondido na fatura, ocupando o pódio de custos, é o Amazon CloudWatch.
Existe uma ironia dolorosa no mundo de Cloud Computing: às vezes, custa mais caro monitorar uma aplicação do que executá-la.
Com a popularização dos microsserviços, Kubernetes (EKS) e funções Serverless (Lambda), a cultura do “log everything” (registre tudo) se tornou o padrão. O problema é que a observabilidade na nuvem tem um modelo de precificação implacável.
Neste artigo, vamos dissecar por que o CloudWatch drena o seu orçamento e, mais importante, quais as decisões arquiteturais definitivas para estancar esse sangramento financeiro sem perder a visibilidade do seu ambiente.
A Matemática do Desperdício: Onde o Dinheiro Escorre?
O Amazon CloudWatch não cobra apenas para armazenar seus logs, ele cobra pela ingestão de dados. E é aqui que a armadilha se fecha.
Dependendo da região da AWS, você paga cerca de US$ 0,50 a US$ 0,57 por Gigabyte ingerido.
Pense em uma API transacional robusta. A equipe de desenvolvimento, visando facilitar o troubleshooting, decide logar o payload completo (em JSON) de cada requisição, os cabeçalhos HTTP e todas as respostas bem-sucedidas (HTTP 200).
Em dias de alto tráfego, essa API pode facilmente gerar dezenas, ou até centenas de Gigabytes de texto por dia. Você não está pagando computação; você está pagando quase 50 centavos de dólar para o CloudWatch ler a palavra "status": "success" milhões de vezes.
Para piorar, por padrão, os Log Groups do CloudWatch são criados com a política de retenção definida como “Never Expire” (Nunca Expirar). Você passa a pagar armazenamento perpétuo por dados de debug que perdem a utilidade em menos de 48 horas.
Como virar o jogo: 3 Estratégias Avançadas de FinOps
Cortar custos com logs não significa apagar os olhos da operação. Significa roteamento inteligente e engenharia de software aplicada à infraestrutura.
1. Nível de Log Dinâmico (Dynamic Logging)
O maior erro de times de engenharia é manter o nível de log em DEBUG ou INFO em produção o tempo todo. Logs transacionais completos só são úteis quando há um incêndio para apagar.
A solução: Desacople a configuração de log do deploy da sua aplicação. Utilize serviços como o AWS AppConfig ou o Systems Manager Parameter Store. Configure seu código para escutar essa variável. O estado normal da aplicação deve ser o nível ERROR ou WARN. Se um incidente começar, a equipe de SRE altera o parâmetro no AppConfig para DEBUG. Em segundos, sem precisar derrubar os pods ou fazer um novo deploy, a aplicação começa a cuspir logs detalhados. Resolvido o incidente? Volte a chave para ERROR. O alívio financeiro é imediato.
2. Roteamento de Logs: O CloudWatch não é Banco de Dados
O CloudWatch é excelente para disparar alarmes, cruzar métricas e gerar dashboards em tempo real, mas é financeiramente tóxico para retenção de longo prazo (Cold Storage) ou auditoria compliance.
A solução: Não mande tudo para o CloudWatch. Se você usa Amazon EKS (Kubernetes) ou ECS, configure o Fluent Bit para fazer o roteamento inteligente (Log Splitting). Envie apenas métricas e logs de erros cruciais para o CloudWatch. Para logs de acesso (Access Logs) volumosos e payloads para fins de auditoria, direcione a saída do Fluent Bit direto para o Amazon Kinesis Data Firehose. O Firehose empacotará esses logs e os jogará diretamente no Amazon S3. O custo de armazenamento no S3 Standard é de ínfimos US$ 0,023 por GB (e cai ainda mais no Glacier). Você corta a ingestão cara do CloudWatch e atende aos requisitos de compliance e segurança de forma barata.
3. Destruição Programada (Retenção Agressiva)
Uma regra de ouro do FinOps na AWS: Nunca, em hipótese alguma, permita que um recurso seja criado sem um ciclo de vida definido.
A solução: Automatize a gestão dos Log Groups. Para resolver o passado, escreva um script simples em Python (usando boto3) que percorre todos os Log Groups da sua conta que estão marcados como “Never Expire” e force a retenção para 7 a 14 dias. Para o futuro, garanta que seus módulos de Terraform ou CloudFormation incluam a tag de retenção (retention_in_days) como um campo obrigatório antes da criação de qualquer infraestrutura. O que passa de duas semanas deve ser arquivado no S3 ou descartado.
Conclusão
Observabilidade de excelência não é sobre registrar absolutamente tudo; é sobre registrar aquilo que tem valor acionável.
Ao implementar retenção agressiva, roteamento de logs para o S3 via Firehose e log dinâmico via AppConfig, empresas reduzem sua fatura de CloudWatch em até 80%, devolvendo o orçamento para onde ele realmente importa: inovação, instâncias de processamento e entrega de valor para o cliente.
Da próxima vez que sua fatura chegar, não aceite passivamente a taxa do CloudWatch como um “imposto de infraestrutura”. Otimize.
