Monitoramento de Custos (AWS Cost Explorer)

Monitoramento de custos é a prática de tornar o gasto com nuvem visível, atribuível e comparável ao longo do tempo, e o AWS Cost Explorer é a ferramenta nativa que cumpre esse papel na AWS. O princípio do FinOps que fundamenta a prática é simples: ninguém otimiza aquilo que não vê, e ninguém responsabiliza um time por um custo que não consegue atribuir. O Cost Explorer transforma a fatura agregada em séries temporais filtráveis por serviço, região, conta, tag e tipo de uso, com dados atualizados a cada 24 horas e projeção de gasto para o fechamento do mês. Em produção, essa visibilidade é a fundação de todas as demais práticas financeiras, de right-sizing a compromissos de uso, porque toda decisão de economia começa por uma pergunta que só os dados de custo respondem. O arquivo cobre o funcionamento do Cost Explorer, os relatórios derivados, orçamentos com alarmes e a análise profunda com Cost and Usage Report e Athena.

Conceito e papel no FinOps

O FinOps organiza o ciclo de gestão financeira de nuvem em três fases: informar, otimizar e operar. O monitoramento de custos vive inteiramente na primeira fase, e a qualidade dela condiciona as outras duas, pois otimização sem visibilidade é chute e operação sem metragem é opinião. O papel do Cost Explorer é converter a fatura, um documento mensal ilegível por natureza, em séries temporais que um time de engenharia consegue correlacionar com releases, campanhas e mudanças de infraestrutura.

A unidade básica de dado é o line item de custo e uso, com data, serviço, região, tipo de uso, quantia e custo amortizado ou unblended. Toda agregação, filtro e agrupamento do Cost Explorer opera sobre esse granular. Entender que a ferramenta é uma interface de consulta sobre esse granular evita o erro mais comum de interpretação, que é tratar um número de gráfico como verdade absoluta sem conferir o que ele exclui, como créditos, refunds e custos amortizados de reserva.

O hábito de produção que sustenta a prática é a cadência de revisão. Times maduros de FinOps rodam revisão semanal curta, focada em variação e anomalia, e revisão mensal profunda, focada em tendência e planejamento de compromissos. A ferramenta fornece o dado, mas é a cadência com dono que produz decisão.

O problema que resolve

Sem monitoramento estruturado, o custo de nuvem chega ao time como surpresa: a fatura do mês vem 40% acima da anterior, ninguém sabe dizer onde, e a reação é cortar capacidade às cegas, geralmente nos lugares errados. O problema tem três raízes. A variabilidade é natural em nuvem, pois elasticidade e pagamento por uso transformam qualquer mudança de comportamento em mudança de custo. A atribuição é difícil, pois a fatura é centralizada e o consumo é distribuído. E a temporidade engana, pois custo é acumulado ao longo do mês e percebido tarde demais para agir.

O Cost Explorer ataca cada raiz com um recurso: séries diárias e mensais com comparativo período a período, agrupamento por dimensão com filtros combináveis, e previsão de fechamento que antecipa a conversa antes do ciclo de faturamento terminar. O ganho em produção aparece como velocidade de diagnóstico: uma anomalia de custo diagnosticável em minutos vira incidente operacional, e a mesma anomalia sem visibilidade vira crise financeira no fim do mês.

Cost Explorer na prática

A consulta típica responde três perguntas: quanto custou, o que compõe o custo e para onde está indo. A interface gráfica cobre o dia a dia, e a CLI ou a API permitem automatizar relatórios e alimentar dashboards próprios. As dimensões de filtro mais usadas em produção são serviço, região, tagged key, linked account e usage type, e a granularidade temporal costuma ser diária para diagnóstico e mensal para tendência.

# Custo por serviço no último mês, com agregação diária
aws ce get-cost-and-usage \
  --time-period Start=2025-05-01,End=2025-05-31 \
  --granularity DAILY \
  --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

# Custo por tag de produto no mês corrente, base do showback por time
aws ce get-cost-and-usage \
  --time-period Start=2025-06-01,End=2025-06-15 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --filter '{"Tags":{"Key":"produto","Values":["checkout"]}}' \
  --group-by Type=TAG,Key=centro-custo

A leitura correta exige disciplina de janela e de métrica. Comparar dias de semana com fins de semana gera falsa anomalia, e comparar unblended com amortized cost mistura regimes de pagamento, já que o segundo dilui o custo de reservas ao longo do uso. A recomendação operacional é fixar a métrica do dashboard de time em amortized cost e reservar unblended para reconciliação com a fatura.

Relatórios e visões nativas

Além da consulta livre, o Cost Explorer entrega visões prontas que cobrem os relatórios recorrentes de um programa de FinOps. O relatório de custos por serviço mapeia tendência e concentração, e o de uso por tipo mostra unidade consumida, como horas de instância ou GB de saída de dados, separando o custo da causa. As visões de Reserved Instance e Savings Plan utilization e coverage respondem o que todo compromisso existente está entregando, em utilização e em cobertura do consumo total.

• Cost by service: concentração de gasto e direção da tendência por serviço, base do right-sizing.
• Cost by linked account: atribuição por conta, essencial em organizações multi-account.
• Usage type breakdown: unidades físicas consumidas, que conectam custo a capacidade provisionada.
• RI e Savings Plan reports: utilização e cobertura de compromissos, insumo direto da próxima compra.
• Forecasts: projeção de fechamento, que transforma surpresa em conversa antecipada.

Uma limitação operacional precisa constar no desenho de qualquer automação: o dado do Cost Explorer é atualizado a cada 24 horas e valores de menos de 48 horas ainda podem ser reprocessados. Alertas de custo quase em tempo real exigem outro caminho, tipicamente métricas de consumo da aplicação ou telemetria de CloudWatch convertidas em estimativa de custo, com o Cost Explorer servindo como reconciliação oficial. Times que ignoram essa defasagem constroem alarmes que apitam com um dia de atraso e somem sozinhos no reprocessamento.

Orçamentos com alarmes

O AWS Budgets completa o monitoramento com controle, definindo teto por custo, uso, reserva ou cobertura, e disparando ação quando o real ou o projetado cruza o limiar. O desenho correto é em camadas: um orçamento total por conta, orçamentos por centro de custo derivados de tags e orçamentos por serviço para itens voláteis. Cada orçamento aceita múltiplos limiares, tipicamente 80% para alerta e 100% para ação, e pode disparar automação via SNS, Lambda ou até suspensão controlada de recursos não críticos.

# Orçamento mensal por tag de produto com dois limiares (AWS Budgets)
budget:
  name: checkout-mensal
  budget_type: COST
  time_unit: MONTHLY
  budget_limit: { amount: 12000, unit: USD }
  cost_filters:
    tags: { produto: [checkout] }
  notifications:
    - comparison_operator: GREATER_THAN
      threshold: 80            # aviso: 80% do teto, em valor real
      notification_type: ACTUAL
      subscribers: [email:finops@empresa.br, sns:alertas-custo]
    - comparison_operator: GREATER_THAN
      threshold: 100
      notification_type: FORECASTED   # projeta estouro antes de acontecer
      subscribers: [sns:acao-custo]

Cost and Usage Report e análise em Athena

O Cost Explorer limita consultas interativas; quando a análise precisa cruzar custo com dados de aplicação, o instrumento é o Cost and Usage Report, que entrega o granular completo em S3 em formato Parquet, e o Athena, que consulta esses arquivos com SQL. O Cost and Usage Report é o dado de verdade da fatura, incluindo campos que o Cost Explorer não expõe com o mesmo detalhe, como custo por linha com amortização, descontos negociados e split de custo compartilhado. Times de FinOps maduros tratam o CUR como fonte única e reconstroem seus relatórios executivos a partir dele, usando o Cost Explorer apenas como lente de consulta rápida.

O desenho típico da esteira de análise tem quatro peças: o CUR entregue diariamente em um bucket S3, uma tabela Glue apontando para os arquivos, consultas ad hoc ou agendadas no Athena e um dashboard que consome o resultado. Com essa esteira, perguntas como custo por feature, custo por tenant e custo de cada release passam a ser consultas SQL de minutos, e não projetos manuais de planilha.

-- Top 10 recursos mais caros no mês por serviço (CUR no Athena)
SELECT line_item_resource_id AS recurso,
       line_item_service_code AS servico,
       SUM(line_item_unblended_cost) AS custo_usd
FROM cur_database.cur_table
WHERE line_item_usage_start_date >= DATE '2025-06-01'
  AND line_item_usage_start_date <  DATE '2025-07-01'
GROUP BY 1, 2
ORDER BY custo_usd DESC
LIMIT 10;

Consultas como essa são o ponto de partida dos relatórios de showback, do right-sizing direcionado e da investigação de anomalias, e substituem com precisão o trabalho manual de abrir planilhas de fatura.

Variabilidade, anomalias e comparações

Custo em nuvem é ruidoso por natureza, e o monitoramento maduro separa variação esperada de anomalia real. Os padrões normais incluem sazonalidade de tráfego, custo de backup mensal e saídas de dados concentradas em rotinas noturnas; anomalias reais aparecem como salto por serviço ou por tipo de uso sem evento de negócio associado. O AWS Cost Anomaly Detection aprende o padrão por serviço e por conta e alerta por email ou SNS quando o desvio supera o esperado, cobrindo justamente o caso em que nenhum orçamento estático pegaria o problema.

Erros comuns

• Monitorar sem atribuir: custo visível por serviço, mas sem tags por time, e cada queda de gasto vira discussão sem dono.
• Comparar janelas incomparáveis: mês com campanha contra mês sem, ou semana de lançamento contra semana normal, gerando conclusões erradas.
• Orçamento único e central: um teto para a conta inteira, que alerta tarde e não aponta culpado, em vez de camadas por centro de custo.
• Ignorar projeção: alarmar só no custo real, quando o alerta de forecast existe justamente para agir antes do estouro.
• Ver custo sem ver uso: reagir ao valor sem olhar a unidade consumida, o que confunde subida de preço com subida de consumo real.
• Tratar D+1 como tempo real: decisões de incidente de custo tomadas com dado defasado, sem validar o evento na telemetria da aplicação.
• Misturar métricas de custo: alternar entre unblended, amortized e blended na mesma comparação, o que distorce compromissos e créditos.

Boas práticas

Padronize um dashboard por time com a mesma métrica, a mesma janela e o mesmo recorte de tags, pois comparabilidade entre times é o que transforma visibilidade em conversa de gestão. Rode a revisão de custo em cadência fixa, semanal para anomalias e mensal para tendência, com o relatório de utilização de reservas sempre na pauta. Automatize o básico via CLI e API em vez de depender de cliques, porque relatório manual morre na primeira semana cheia. Por fim, trate todo alarme de orçamento com processo de diagnóstico em duas etapas, primeiro isolar dimensão com maior variação e depois explicar com evento, pois essa disciplina é o que separa monitoramento de custo de pânico mensal.

Uma métrica de eficiência amarra o monitoramento ao negócio: custo por unidade de valor entregue, como custo por mil requisições, custo por pedido processado ou custo por usuário ativo. O custo absoluto sobe naturalmente com o crescimento da empresa, e essa é uma boa notícia; o que precisa ficar sob vigilância é a unidade, que denuncia desperdício mesmo quando o total é aceitável. O Cost Explorer fornece o numerador, e a métrica de negócio fornecida pela aplicação fecha a fração.