Desvendando os custos ocultos das métricas do CloudWatch

O monitoramento na nuvem é essencial para manter e otimizar a infraestrutura na AWS, e o Amazon CloudWatch é uma das principais ferramentas para acompanhar métricas, logs e alarmes. Mas, conforme o uso da AWS cresce, os custos do CloudWatch também aumentam — e, em alguns casos, podem ser difíceis de rastrear.

Um desafio comum para quem usa AWS é identificar com precisão o que está puxando os custos do CloudWatch no Cost & Usage Report (CUR). O relatório até mostra um panorama geral, mas não traz o nível de detalhe necessário para apontar as fontes específicas dos gastos mais altos.

Este artigo traz um caso real de diagnóstico de custos inesperados do CloudWatch usando o DoiT Cloud Intelligence. Depois de identificar as operações mais caras, vamos mostrar como usar os data events do CloudTrail e o Amazon Athena para descobrir a origem dessas cobranças e gerar insights práticos. No final, você terá uma estratégia clara para entender e controlar os custos ocultos do CloudWatch.

O Amazon CloudWatch é uma ferramenta de monitoramento indispensável em ambientes AWS e oferece insights detalhados sobre métricas e logs. Acontece que sua estrutura de custos pode ser pouco transparente, o que dificulta identificar a origem de picos inesperados na fatura.

Mesmo trazendo um detalhamento granular dos custos da AWS, o Cost & Usage Report (CUR) deixa a desejar quando o assunto é visibilidade no nível do recurso para cobranças específicas. Um exemplo clássico é o GetMetricData, uma operação de API usada para obter dados de métricas do CloudWatch. Apesar do impacto significativo nos custos, o CUR não traz detalhes suficientes para mostrar quais serviços, aplicações ou usuários estão por trás dessas cobranças.

Essa falta de transparência atrapalha quem usa AWS na hora de otimizar custos, evitar estouros de orçamento e tomar decisões embasadas sobre as configurações de monitoramento.

Para ilustrar esse desafio, usamos os relatórios do DoiT Cloud Analytics, que ajudam a visualizar e interpretar os dados de custo da nuvem. Os dados podem ser apresentados em diferentes diagramas, com filtros e agrupamentos que facilitam a leitura.

A análise a seguir, por exemplo, traz um detalhamento dos custos do CloudWatch em 28 dias e evidencia os valores consistentemente altos das operações GMD-Metrics (GetMetricData ).

A tabela de custos abaixo classifica as despesas do CloudWatch por SKU (Stock Keeping Unit), tipo de operação e informações do recurso. Pontos de destaque:

• GMD-Metrics (GetMetricData ) é um dos principais responsáveis pelos custos.
• As informações do recurso não aparecem, o que dificulta identificar a origem dessas requisições.
• O MetricMonitorUsage também pesa nos custos, embora em menor proporção.

Como o GetMetricData está gerando custos relevantes e sem explicação clara, é hora de partir para uma investigação mais aprofundada com os data events do CloudTrail e o Amazon Athena para rastrear a origem.

O AWS CloudTrail registra eventos de gerenciamento por padrão, como mudanças no IAM, configurações de segurança e provisionamento de recursos. Já os data events, que capturam chamadas de API específicas de cada serviço — como operações em nível de objeto no S3 ou execuções do Lambda —, não vêm habilitados por padrão.

Como precisamos rastrear eventos de métricas do CloudWatch, é preciso habilitar os data events do CloudTrail explicitamente. Dá para fazer isso em uma trilha existente ou ao criar uma nova.

Configurando o CloudTrail

1. Escolha uma trilha do CloudTrail

• Modifique uma trilha existente ou crie uma nova.
• Defina um bucket S3 para armazenar os logs do CloudTrail.

2. Configure os recursos opcionais

• Criptografia KMS (opcional), para reforçar a segurança.
• Validação de logs e notificações por SNS (opcional, para integridade e alertas).
• Armazenamento no CloudWatch Logs (não se aplica aqui, já que vamos usar o Athena na análise).

Definindo o data event para métricas do CloudWatch

1. Selecione CloudWatch metric como o tipo de Data Event.

2. Defina o Log Selector:

• Todos os eventos (nossa escolha, por simplicidade).
• Eventos somente leitura ou somente escrita
• Use seletores customizados para mais controle.

Uma vez habilitado, o CloudTrail passa a registrar as requisições GetMetricData do CloudWatch, mas é preciso esperar os logs se acumularem antes da análise.

Criando uma tabela do Athena para os logs do CloudTrail

Com o CloudTrail registrando as requisições GetMetricData do CloudWatch em um bucket S3, podemos usar o Amazon Athena para analisá-las.

Para analisar os logs do CloudTrail no Amazon Athena, é preciso criar uma tabela que aponte para os dados de log armazenados no seu bucket S3:

• Acesse o Console do CloudTrail e vá até Event history, no menu à esquerda.
• Clique em Create Athena table e, no menu suspenso Storage location, selecione o bucket S3 onde os logs do CloudTrail estão armazenados.

Consultando eventos GetMetricData

Agora dá para consultar no Amazon Athena quem (ou o quê) está fazendo requisições GetMetricData. Esta consulta SQL é apenas um exemplo, usando um pequeno conjunto de dados de amostra. Em um conjunto real, uma consulta diferente pode trazer resultados mais precisos.

SELECT
    COUNT(*) as count,
    eventname,
    useridentity.principalId,
    useridentity.arn
FROM cloudtrail_logs_aws_cloudtrail_logs_cw_metrics
WHERE eventname = 'GetMetricData'
GROUP BY eventname, useridentity.principalId, useridentity.arn
ORDER BY count DESC
LIMIT 100;

Interpretando os resultados

Os resultados (no exemplo abaixo) revelam as fontes que estão gerando requisições GetMetricData.

• A primeira linha mostra 18 requisições, o que a coloca como principal responsável pelos custos.
• As colunas principalId e arn ajudam a identificar se as requisições vêm de um serviço AWS específico, de um usuário/role do IAM ou de uma aplicação.
• Se as requisições em excesso não forem necessárias, vale reduzir a frequência de polling, otimizar as configurações de monitoramento ou restringir o acesso para diminuir os custos.