Quando o custo de cloud vai para um centro de custo genérico de TI, ninguém tem responsabilidade pelo que consome. O time de produto pede mais recursos sem pensar em custo. O time de dev deixa ambientes ligados sem consequência. Chargeback muda essa dinâmica — e os resultados são imediatos.
O que é chargeback e o que é showback
Os dois conceitos são frequentemente confundidos, mas têm diferenças importantes na prática:
Showback: os times veem quanto consomem de infraestrutura de cloud — mas TI continua absorvendo o custo. É sobre transparência e consciência, não sobre transferência financeira. Times recebem relatórios de custo mas não são cobrados pelo que consomem.
Chargeback: os times são efetivamente cobrados pelo custo de cloud que geram. O custo é transferido do centro de custo de TI para o centro de custo do time ou produto que o originou. Isso pode ser literal (o time paga de verdade) ou contábil (é alocado no relatório financeiro do time, afetando o P&L da área).
A diferença é de incentivo: showback cria consciência, chargeback cria responsabilidade financeira real. Times que pagam pelo que consomem tendem a tomar decisões muito mais cuidadosas sobre provisioning.
Por que tagging é o pré-requisito
Não existe chargeback sem tagging. Sem identificar a qual time ou projeto cada recurso pertence, você não tem como alocar o custo — tudo fica num pool indiferenciado de “cloud de TI”.
Estrutura mínima de tags para chargeback:
| Tag | Propósito | Exemplo |
|---|---|---|
Team ou Owner |
Identifica o time responsável | backend, dados, produto-x |
CostCenter |
Código do centro de custo financeiro | CC-001-PRODUTO |
Project |
Projeto ou produto específico | app-clientes, api-pagamentos |
Environment |
Separa prod de dev/test (geralmente absorvidos diferentes) | prod, staging, dev |
Application |
Sistema ou aplicação específica | erp, crm, billing |
O problema mais comum: recursos sem tag. Toda estratégia de chargeback tem um “untagged bucket” — recursos que não podem ser alocados porque não têm tags. Quanto menor esse bucket, mais precisa é a alocação. Políticas que impedem a criação de recursos sem tags obrigatórias (via AWS Service Control Policies ou Azure Policy) são a solução mais eficaz.
Como implementar progressivamente
A jornada recomendada tem quatro estágios:
Estágio 1 — Visibilidade (mês 1–2)
Ative o Cost Explorer ou equivalente. Veja o custo atual por serviço e por conta. Entenda onde está o maior gasto. Esse estágio não requer tags ainda — é só análise inicial.
Estágio 2 — Tagging (mês 2–4)
Implemente a estrutura de tags. Comece pelos recursos mais caros e mais fáceis de identificar. Documente a política de tagging e comunique os times. Defina prazo para compliance de tags (recursos sem tag depois de X dias devem ser tagueados ou deletados).
Ferramenta: AWS Tag Editor, Azure Tag Management ou script de auditoria de tags. Objetivo: 85%+ dos recursos tagueados nos primeiros 60 dias.
Estágio 3 — Showback (mês 3–6)
Com tags no lugar, gere relatórios de custo por time/projeto mensalmente. Compartilhe com cada time. Nenhuma cobrança ainda — apenas consciência. Observe as reações: times que ficam surpresos com o que consomem geralmente tomam ações espontâneas de otimização.
Ferramentas: dashboards em AWS Cost Explorer com filtro por tag, relatórios do Azure Cost Management, Looker Studio ou Power BI conectado às APIs de billing.
Estágio 4 — Chargeback (mês 6+)
Com visibilidade estabelecida e times conscientes do que consomem, você pode introduzir o chargeback real. Isso geralmente requer alinhamento com o financeiro sobre como os centros de custo são estruturados.
Modelos de chargeback:
- Custo direto: o custo exato de cada recurso tagueado é alocado ao time. Simples e transparente, mas pode ter distorções em recursos compartilhados.
- Custo compartilhado proporcional: recursos sem owner definido (infraestrutura compartilhada, rede, logging) são distribuídos proporcionalmente ao uso dos recursos diretos.
- Custo fixo + variável: o time paga um valor fixo mensal de infraestrutura base + variável pelo que consumiu além da base.
O que muda quando os times veem a fatura deles
Isso é o resultado mais consistente e mais interessante do chargeback: quando times de produto e desenvolvimento passam a ver — e pagar — o custo de infraestrutura que geram, o comportamento muda sem que TI precise pedir.
Exemplos típicos:
- Dev passa a desligar os ambientes de teste antes de sair na sexta
- Time de produto começa a perguntar “quanto vai custar em infra?” antes de aprovar features
- Squads começam a revisar logs e métricas para encontrar gargalos que geram custo extra
- Engenheiros escolhem tipos de instância com mais cuidado, não apenas o “maior disponível”
Esses comportamentos não emergem de treinamento ou de instrução de TI — emergem naturalmente quando o custo é visível e alocado a quem decide.
O cuidado necessário: chargeback pode criar tensão se implementado abruptamente, especialmente se os times não tiveram tempo de se adaptar. A progressão showback → chargeback com comunicação clara e prazo adequado é essencial para a adoção.
Ferramentas para implementar chargeback
Nativas dos provedores:
- AWS Cost Allocation Tags + Cost Categories: permite criar grupos de recursos e alocar custos por tag. Relatórios em Cost Explorer filtrados por categoria.
- Azure Cost Management: alocação por departamento, conta, grupo de recursos. Exportação para Power BI.
- GCP Billing Labels + BigQuery Billing Export: dados de billing detalhados no BigQuery para análise personalizada.
Ferramentas especializadas:
- CloudHealth by VMware: gestão de cloud multi-provedor com alocação de custos, showback e chargeback automatizados
- Apptio Cloudability: focado em FinOps enterprise, com gestão de reservas, showback e chargeback
- Finout: alternativa mais simples e moderna para alocação de custos
A Adentro oferece relatórios mensais de custo por projeto para clientes de cloud privada — facilitando o processo de showback e chargeback interno sem necessidade de ferramentas adicionais de FinOps.