A conta do CloudWatch está cada vez mais cara? Guia prático de redução de custos para Logs e Metrics

O CloudWatch pode facilmente se transformar de uma “ferramenta padrão de observabilidade” em um buraco negro de cobranças. Especialmente após a integração de contêineres, microsserviços, Lambda, API Gateway e VPC Flow Logs, o Logs ingest, a retenção de logs, Custom Metrics, Alarms e Dashboards crescerão juntos. Para reduzir custos, o primeiro passo não é deletar o monitoramento, mas sim detalhar e entender exatamente onde o dinheiro está sendo gasto.

Os preços a seguir utilizam como referência as tarifas públicas comuns da região us-east-1, dependendo da região atual da AWS para os valores reais: a ingestão padrão de logs do CloudWatch Logs custa geralmente cerca de $0.50/GB, com arquivamento de logs a cerca de $0.03/GB-month; consultas do Logs Insights custam geralmente cerca de $0.005/GB scanned; as primeiras 10.000 Custom Metrics custam geralmente cerca de $0.30/metric-month; alarm de resolução padrão custa geralmente cerca de $0.10/alarm metric-month; e dashboard personalizado custa geralmente cerca de $3/dashboard-month.

Primeiro o diagnóstico: Logs ou Metrics, o que está mais caro?

No Cost Explorer, selecione CloudWatch em Service e detalhe por Usage type. Os itens comuns de alto custo incluem:

• DataProcessing-Bytes: ingestão de logs.
• TimedStorage-ByteHrs: armazenamento de logs.
• MetricMonitorUsage: métricas personalizadas.
• AlarmMonitorUsage: alarmes.
• GMD-Metrics ou requisições de API: consultas GetMetricData.

Muitas equipes pensam que os dashboards são caros, mas na verdade o custo geralmente vem da ingestão de logs ou de custom metrics de alta cardinalidade.

Redução de custos em Logs 1: Configurar o período de retenção

Por padrão, os CloudWatch Log Groups podem reter logs indefinidamente. Para logs de aplicação, muitas equipes precisam de apenas 7, 14, 30 ou 90 dias de busca online.

Visualização em lote:

aws logs describe-log-groups \
  --query 'logGroups[*].[logGroupName,retentionInDays,storedBytes]' \
  --output table

Configurar retenção:

aws logs put-retention-policy \
  --log-group-name /aws/ecs/prod-api \
  --retention-in-days 30

Recomendamos segmentar por tipo de log: logs de erro de produção por 90 dias, logs normais de aplicação de 14 a 30 dias, logs de debug de 3 a 7 dias, e logs de auditoria e conformidade exportados para o S3 para armazenamento de longo prazo.

Redução de custos em Logs 2: Filtrar antes da ingestão, em vez de consultar após a ingestão

A parte mais cara do CloudWatch Logs geralmente é a ingestão. Filtrar os logs com subscription filter ou Logs Insights depois que eles já entraram no CloudWatch não reduzirá a taxa de ingestão.

A filtragem deve ser realizada na camada da aplicação, sidecar, Fluent Bit ou OpenTelemetry Collector:

[FILTER]
    Name   grep
    Match  app.*
    Exclude log ^.*healthcheck.*$

Priorize descartar logs de alta frequência e baixo valor, como health check, requisições de recursos estáticos com status 200, debugs duplicados e payloads excessivamente longos. Manter o ambiente de produção com nível padrão INFO e aumentar temporariamente para DEBUG apenas durante a resolução de problemas é muito mais barato do que manter debug completo a longo prazo.

Redução de custos em Logs 3: Limpar Log Groups sem uso

Quando recursos do Lambda, ECS, API Gateway ou Step Functions são desativados, seus respectivos log groups não são necessariamente excluídos de forma automática. Você pode identificar os grupos que não recebem gravações há muito tempo:

aws logs describe-log-groups \
  --query 'logGroups[?storedBytes>`0`].[logGroupName,storedBytes,retentionInDays]' \
  --output table

Em seguida, use o lastEventTimestamp para verificar se eles ainda estão em uso. Recomendamos exportar para o S3 antes de deletar, evitando a exclusão acidental de dados de conformidade.

Redução de custos em Logs 4: Cautela ao integrar logs de alto tráfego

Logs como VPC Flow Logs, ALB Access Logs, WAF Logs e CloudFront Logs podem ser extremamente volumosos. Não os envie todos por padrão para o CloudWatch.

A abordagem mais comum é:

• Enviar logs de curto prazo para troubleshooting para o CloudWatch.
• Enviar logs de acesso de longo prazo para o S3.
• Utilizar o Athena para consultar dados históricos.
• Para o VPC Flow Logs, amostrar apenas os campos necessários ou ativar o recurso apenas para subnets/ENIs críticas.

A experiência interativa do S3 + Athena pode não ser tão ágil quanto a do CloudWatch Logs, mas o custo de retenção de longo prazo costuma ser significativamente menor, sendo ideal para consultas de auditoria de baixa frequência.

Redução de custos em Logs 5: Avaliar alternativas como opções complementares

Se o principal gargalo for o custo de ingestão e armazenamento do CloudWatch Logs, você pode avaliar soluções alternativas. Por exemplo, o S4 Logs é um produto alternativo focado na otimização de custos do CloudWatch Logs, ideal para cenários com grande volume de logs, longos períodos de retenção e onde a capacidade de consulta nativa do CloudWatch não é um requisito estritamente obrigatório.

Ele não deve ser visto como uma “substituição cega do CloudWatch”. Se a sua equipe depende fortemente do Logs Insights, CloudWatch Alarm e dos fluxos operacionais existentes, o custo de migração deve ser levado em conta. Uma abordagem mais prática é escolher um log group de alto tráfego e baixo risco para um projeto piloto e, em seguida, usar a calculadora de economia para estimar a faixa de economia potencial.

Redução de custos em Metrics 1: Controlar a cardinality

O principal risco com Custom Metrics é a alta cardinalidade. O CloudWatch cobra com base na combinação de namespace, metric name e dimension. Um design de dimensões como o seguinte é perigoso:

MetricName=Latency
Dimensions=service, endpoint, customer_id, pod_id, request_id

Se o customer_id tiver 10.000 valores e o endpoint tiver 50, a combinação teórica se expandirá rapidamente. Uma abordagem mais segura é manter apenas as dimensões realmente necessárias para troubleshooting e alarmes:

MetricName=LatencyP95
Dimensions=service, endpoint, environment

Campos com alta cardinalidade, como pod_id e request_id, são mais adequados para logs ou traces, não devendo ser utilizados como dimensões de custom metrics do CloudWatch.

Redução de custos em Metrics 2: Agregar antes de enviar

Evite chamar PutMetricData diretamente para cada instância, tenant ou endpoint. Faça a agregação na camada da aplicação ou do collector, como por exemplo, enviando p50/p95/p99, count e error_count uma vez a cada 60 segundos.

A própria API PutMetricData pode gerar custos por requisição, com preço comum em torno de $0.01/1,000 requests. Mudar a frequência de envio de 10 segundos para 60 segundos geralmente não afeta a maioria dos alarmes de negócios, mas reduz significativamente o volume de requisições de API e a quantidade de métricas.

Redução de custos em Metrics 3: Usar o EMF corretamente

O Embedded Metric Format permite extrair métricas de logs estruturados, sendo ideal para unificar logs e métricas. No entanto, o EMF não significa “métricas gratuitas”. Ele ainda gerará custos de ingestão de logs e poderá gerar custos de custom metrics.

Ao utilizar o EMF, fique atento a:

• Não inclua user_id, order_id ou container_id nas dimensions.
• Controle a quantidade de namespaces.
• Faça a agregação de eventos de alta frequência antes de gerar a saída EMF.
• Verifique periodicamente quantas unique metrics estão sendo geradas na prática.

Redução de custos em Metrics 4: Governança de alarmes e dashboards

Um problema comum com alarmes é criar um alarm para cada combinação de dimensões, resultando em milhares de alarmes. Em vez disso, recomendamos:

• Criar poucos alarmes agregados para os SLOs críticos.
• Investigar problemas detalhados por meio de dashboards ou logs.
• Utilizar composite alarms para reduzir o ruído gerado por alarmes relacionados.
• Excluir dashboards que ninguém acessa.

O custo unitário de um Dashboard em si pode não ser alto, mas atualizações automáticas frequentes geram custos de API GetMetricData, especialmente em painéis de monitoramento públicos e sistemas de polling.

Quando considerar o S4 Metrics?

Se o principal problema do CloudWatch Custom Metrics for o custo decorrente da alta cardinalidade, mas o negócio realmente precisar reter métricas de granularidade mais fina, vale a pena avaliar alternativas como o S4 Metrics. O seu objetivo é reduzir os custos de cardinality de métricas personalizadas do CloudWatch, e não substituir todo o ecossistema de observabilidade. É recomendável iniciar um piloto A/B a partir de namespaces não críticos ou do grupo de métricas de maior custo.

Um plano executável de 7 dias

Dia 1: Use o Cost Explorer para identificar os principais usage types do CloudWatch. Dia 2: Liste o tamanho e a retention de todos os log groups. Dia 3: Altere a retenção padrão de permanente para períodos segmentados de 7, 14, 30 ou 90 dias. Dia 4: Configure o Fluent Bit ou o OTel Collector para filtrar logs de baixo valor antes do envio. Dia 5: Direcione os logs de longo prazo para o S3 + Athena. Dia 6: Exporte a lista de custom metrics e remova as dimensões com alta cardinalidade. Dia 7: Avalie se vale a pena testar soluções alternativas como S4 Logs / S4 Metrics em um projeto piloto.

O princípio de redução de custos do CloudWatch é simples: mantenha sinais de alto valor, evite a ingestão de ruídos de baixo valor e mova os dados que precisam de retenção de longo prazo para sistemas mais adequados a esse propósito.

Divulgação: O autor deste artigo faz parte da abyo software (desenvolvedora da solução de otimização de custos S4 no AWS Marketplace).