Visibilidade de custo

Custo de nuvem é a única linha do orçamento que engenharia decide e financeiro paga. Enquanto a conta chega em um PDF para o financeiro e ninguém consegue dizer qual serviço gastou o quê, a discussão degenera em corte linear (“todo mundo reduz 20%”) — que corta o lugar errado.

Visibilidade é o primeiro passo de FinOps e o que viabiliza todos os outros: sem alocação, não há responsabilidade; sem responsabilidade, otimização não dura.

Por que a fatura é ilegível

Ela é organizada por serviço do provedor, não pelo seu negócio: EC2-Other, Data Transfer, NatGateway-Bytes. Some a isso descontos, créditos, compromissos amortizados e uso compartilhado, e você tem um documento que responde “quanto” mas nunca “por quê” nem “de quem”.

Traduzir isso para a linguagem da empresa — time, produto, ambiente — é o trabalho.

Estratégia de tags

Poucas tags, obrigatórias, com valores controlados. Muitas tags opcionais produzem grafias divergentes e nenhuma alocação.

# o mínimo que resolve a maior parte das perguntas
default_tags = {
  ambiente        = "prod"        # prod | hom | dev
  time            = "loja"        # o dono operacional
  produto         = "checkout"    # a que o gasto serve
  centro_de_custo = "CC-4821"     # o vínculo com o financeiro
  gerenciado_por  = "terraform"
}

Aplique via default_tags no provider (ou equivalente), ative as tags como chaves de alocação de custo no console de billing (elas não aparecem nos relatórios até serem ativadas) e exija por política:

# Azure Policy, Organization Policy ou SCP: recurso sem tag não é criado
efeito: Deny
condicao: tags['centro_de_custo'] ausente

Depois, meça a cobertura: o percentual de gasto com tags válidas é a métrica de saúde do programa. Abaixo de 90%, os relatórios ainda não sustentam decisão.

Nem tudo aceita tag (tráfego entre zonas, alguns serviços compartilhados). É por isso que a separação por conta ou projeto por ambiente continua sendo a alocação mais confiável — tags complementam, não substituem.

Alocação por time e produto

Com tags e contas no lugar, monte a visão que interessa:

-- exportação de faturamento no BigQuery/Athena: gasto por time e serviço no mês
SELECT tags.time, service.description AS servico,
       ROUND(SUM(cost), 2) AS custo_brl
  FROM faturamento
 WHERE usage_date BETWEEN '2026-08-01' AND '2026-08-31'
 GROUP BY 1, 2
 ORDER BY custo_brl DESC
 LIMIT 20;

Use a exportação detalhada (CUR na AWS, Billing Export no GCP, Cost Management Export no Azure) em vez do console: é o único caminho para cruzar custo com dado seu — número de pedidos, clientes, times.

E publique. Um relatório mensal por time, visível para todos, muda comportamento mais que qualquer política. O objetivo não é constranger: é dar a quem escolhe a arquitetura a informação que ele nunca teve.

Custo compartilhado e rateio

Sempre existe uma fatia comum: cluster compartilhado, observabilidade, rede, ferramentas. Escolha um método simples e documente:

• Proporcional ao uso (requests, CPU reservada, volume de logs) — o mais justo, e exige medição. Em Kubernetes, ferramentas como o OpenCost/Kubecost dão custo por namespace.
• Proporcional ao gasto direto — fácil e razoável.
• Igualitário entre times — simples, e injusto quando os tamanhos diferem muito.

Perfeição aqui é armadilha: um rateio aproximado e aceito por todos vale mais que um modelo exato que ninguém entende. O objetivo é orientar decisão, não fechar balanço contábil.

Alertas de anomalia

Fatura é mensal; problema de custo é diário. Sem alerta, você descobre o vazamento 30 dias depois.

• Orçamento com alerta por conta e por time (50%, 80%, 100% do previsto).
• Detecção de anomalia do próprio provedor (Cost Anomaly Detection, Cost Alerts) — barata e eficaz para pegar salto súbito.
• Alerta de recurso caro criado: instância grande, NAT novo, cluster novo.

# revisão semanal: o que mais subiu em relação à semana anterior
aws ce get-cost-and-usage --time-period Start=2026-08-25,End=2026-09-01 \
  --granularity DAILY --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE --query 'ResultsByTime[].Groups[]' --output table

As causas mais comuns de salto são sempre as mesmas: ambiente de teste esquecido ligado, log em modo debug em produção, laço de retry gerando tráfego, consulta analítica varrendo tudo, e recurso órfão (volume, snapshot, IP) que ninguém apaga.

Próximo passo: com a conta legível, ataque o desperdício em Otimização de custo. Para investigar um pico, veja Achar gasto inesperado.