Tags e Alocação de Custos

Tags são pares de chave e valor aplicados a recursos de nuvem, e a alocação de custos é a prática de usar essas etiquetas como dimensão contábil, distribuindo a fatura por produto, time, ambiente e centro de custo. O assunto parece burocrático e é, na realidade, a infraestrutura de governança sobre a qual todo o FinOps se apoia: sem tags confiáveis, a organização sabe quanto gasta no total e não sabe quem gasta, com o quê e por quê. A fatura de nuvem é emitida por conta e por serviço, e nenhuma dessas dimensões corresponde à estrutura organizacional de uma empresa real, o que torna a tag a única ponte entre o consumo e o dono. A diferença entre uma organização que controla custos e uma que só os observa é, quase sempre, a maturidade do seu esquema de tags. O arquivo cobre a convenção de chaves, a exigência via políticas e infraestrutura como código, os relatórios de alocação, os modelos de showback e chargeback e a rotina de higiene que mantém o sistema honesto.

Conceito

Uma tag só tem valor financeiro quando cumpre três propriedades: é aplicada uniformemente, é normalizada em valores controlados e é ativada como cost allocation tag no provedor. Uniformidade significa que todo recurso elegível carrega as chaves obrigatórias; normalização significa que o valor de "producao" é sempre o mesmo, sem variações de caixa, acento ou abreviação; ativação significa que a chave está registrada como alocação de custo e aparece nos relatórios do Cost Explorer e do Cost and Usage Report. Falha em qualquer uma das três produz relatórios com buracos, e relatório de custo com buraco é pior que nenhum relatório, porque transmite falsa segurança.

A hierarquia de organização em nuvem complementa as tags em vez de substituí-las. Contas separadas por produto ou por ambiente são a fronteira mais forte, com isolamento de fatura, de permissão e de cota; as tags atuam dentro de cada conta, refinando a atribuição por serviço, por feature e por centro de custo. O desenho maduro combina os dois níveis, contas para macroestrutura e tags para granularidade.

• Tag de propriedade: identifica quem responde pelo recurso, tipicamente uma chave dono ou time, com valor de registro controlado.
• Tag de ambiente: separa producao, staging e desenvolvimento, base dos relatórios por ciclo de vida.
• Tag de produto ou aplicação: liga o recurso à jornada de negócio que o consome.
• Tag de centro de custo: conecta o consumo à estrutura financeira da empresa, base do chargeback.

O problema que resolve

O problema central é a atribuição. Uma conta com 200 times e 3 mil recursos recebe uma fatura única, e a pergunta "o que aconteceu com o custo da área de pagamentos" não tem resposta sem alocação. Sem resposta, os efeitos em cadeia são previsíveis: otimização sem dono, orçamento por estimativa em vez de por consumo, eTimes que não percebem o custo de suas decisões de arquitetura. A tag transforma a fatura de um documento contábil centralizado em um espelho da organização.

O segundo problema é o do comportamento. Custo que ninguém sente é custo que ninguém otimiza, e a transparência por tag é o mecanismo que dá à engenharia a visão financeira do próprio trabalho. Estudos de mercado sobre FinOps apontam, com consistência, que boa fração do desperdício de nuvem desaparece apenas com a visibilidade atribuída, pois times que veem a própria conta corrigem ambiente esquecido, réplica sobrando e experimento abandonado sem que ninguém peça.

Convenção de tags

A convenção define um esquema pequeno, obrigatório e versionado, porque esquema longo não é cumprido e esquema flexível não é agregável. A prática consolidada limita as chaves obrigatórias a quatro ou cinco, com valores por enumeração fechada, e documenta o significado de cada uma em catálogo publicado. Chaves opcionais podem existir, mas a validação obrigatória se aplica só ao núcleo, e toda exceção precisa de justificativa registrada.

O valor da chave de dono deve apontar para um grupo, e nunca para uma pessoa, pois pessoa muda de time e saí de empresa, enquanto squad persiste e tem canal próprio de alerta. O valor de centro-custo precisa nascer da área financeira e mudar por processo formal, e a sincronização entre o catálogo de tags e o plano de contas é responsabilidade compartilhada de FinOps e controladoria.

Exigência via política e IaC

Convenção sem enforcement é lista de desejos, e o enforcement tem duas camadas complementares. Na camada do código, a infraestrutura como código aplica default_tags e valida as chaves obrigatórias no pipeline, recusando plano que crie recurso sem etiqueta. Na camada da plataforma, políticas de conta bloqueiam a criação de recursos sem tags mesmo para quem contorna o pipeline, por console, por CLI ou por automação externa.

# Terraform: tags obrigatórias por padrão em todos os recursos do módulo
provider "aws" {
  region = "sa-east-1"
  default_tags {
    tags = {
      dono         = var.tag_dono          # exigido por variável sem default
      ambiente     = var.tag_ambiente      # validado por enum no variables.tf
      produto      = var.tag_produto
      centro-custo = var.tag_centro_custo
      gerenciado   = "terraform"           # distingue origem do recurso
    }
  }
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ExigirTagsObrigatoriasNaCriacao",
      "Effect": "Deny",
      "Action": ["ec2:RunInstances", "rds:CreateDBInstance", "s3:CreateBucket"],
      "Resource": "*",
      "Condition": {
        "Null": { "aws:ResourceTag/dono": "true" },
        "StringEquals": { "aws:ResourceTag/ambiente": ["producao", "staging", "dev"] }
      }
    }
  ]
}

O desenho da política de negação merece cuidado com o caminho de emergência. Bloquear criação sem tag em produção protege a alocação, e um papel de break-glass com auditoria cuida do incidente que precisa de recurso imediato; a exigência volta a valer na próxima revisão do recurso. Sem esse escape documentado, times criam workarounds que pioram a higiene.

Além da negação pontual, os provedores oferecem instrumentos de governança de esquema completo. Tag Policies na AWS definem a gramática das chaves, valores permitidos e casings válidos, e reportam conformidade sem bloquear; Azure Policy aplica o mesmo papel com efeito de deny ou audit por definição. O desenho recomendado combina audit amplo sobre todas as chaves do esquema com deny restrito às chaves financeiras essenciais, porque conformidade auditável cobre a nuance e bloqueio indiscriminado gera atrito sem retorno proporcional.

Relatórios de alocação

Com tags ativadas como cost allocation tags, o Cost Explorer passa a agrupar por qualquer chave do esquema, e o CUR recebe as colunas de tag por linha de uso. Os relatórios recorrentes de um programa maduro são três: custo por produto, que responde a roda do negócio; custo por ambiente, que expõe a proporção entre produção e o resto; e custo por centro de custo, que alimenta a contabilidade. Cada relatório precisa de uma linha residual, o custo sem tag, e essa linha é o termômetro de higiene do programa.

Detalhes de mecânica influenciam a leitura. Tags ativadas como alocação só retroagem até 12 meses, e a ativação demora até 24 horas para aparecer nos relatórios. Recursos que correm antes do primeiro dia do mês sem tag vão aparecer com custo acumulado sem dimensão, e a correção é corrigir o recurso e aceitar o histórico, pois realocação retroativa manual não existe na fatura nativa.

Serviços sem suporte completo a tags merecem atenção especial no desenho dos relatórios. Alguns recursos repassam a tag ao custo apenas em datas específicas, e certos itens de uso, como transferência de dados entre serviços, podem não carregar a tag do recurso de origem. A prática recomendada é validar o recorte por tag contra o total da conta no primeiro mês, medir a fração coberta e documentar explicitamente o que cada relatório não vê, evitando a leitura ingênua de que a soma por tag deve bater com a fatura.

Showback e chargeback

Showback e chargeback são os dois modelos de apresentação do custo atribuído, e a escolha entre eles é um estágio de maturidade, não uma preferência estética. O showback mostra a cada time o custo que gera, sem cobrar nada de fato, e serve para criar cultura, calibrar o esquema de tags e corrigir distorções com risco zero. O chargeback transfere o custo para o orçamento do time, e exige esquema de tags confiável, centro de custo validado e um ciclo de fechamento acordado com a controladoria.

A transição recomendada é rodar showback por dois ou três ciclos, corrigir buracos de atribuição enquanto ninguém é cobrado, e só então ativar o chargeback por produto. Implantar chargeback antes da higiene gera reclamações legítimas sobre custo mal atribuído, e reclamação de alocação errada descredita o programa inteiro, que passa a ser visto como contabilidade de estimação.

Higiene de tags

O sistema decai sem rotina de limpeza, e a higiene é composta por três verificações automatizadas. A primeira encontra recursos sem tag obrigatória, por consulta de inventário como Resource Explorer, Config ou script de CLI, e gera fila de correção com prazo. A segunda encontra valores fora do enum, o recurso com "Producao" em vez de "producao", que some dos relatórios case-insensitive mal configurados. A terceira cruza custo residual sem tag com custo total, e alarme dispara quando a fração passa do teto acordado, tipicamente 2% da conta.

# Lista instâncias EC2 sem a tag obrigatória "dono" em uma região
aws ec2 describe-instances --region sa-east-1 \
  --filters "Name=instance-state-name,Values=running" \
  --query 'Reservations[].Instances[?not_null(Tags) == `false` || Tags[?Key==`dono`].Value | length(@) == `0`].[InstanceId,InstanceType]' \
  --output table

A rotina de correção precisa ser de baixo atrito para funcionar: a lista chega ao time com dono, o recurso ganha tag por automação aprovada, e a exceção real, o recurso herdado de outro time, segue processo de reatribuição documentado. Tratar higiene como culpabilidade de time é o caminho curto para que ninguém reporte mais nada.

Erros comuns

• Esquema gigante: dez chaves obrigatórias, e a adesão desmorona; quatro ou cinco chaves bem cumpridas valem mais que dez parciais.
• Valores livres: cada time escreve o ambiente como quiser, e o relatório por ambiente soma três produção diferentes.
• Tag de pessoa como dono: a saída do funcionário deixa recursos órfãos e a fila de correção vira investigação de pertencimento.
• Ativação tardia: esquema definido após a conta estar madura, e meses de custo ficam sem dimensão para sempre.
• Enforcement só no pipeline: automação externa e console criam recursos fora da regra, e a exceção vira regra.
• Showback eterno: relatório apresentado por anos sem nunca cobrar, e a cultura de custo que ele deveria criar nunca se materializa.
• Tag usada como controle de acesso: misturar atribuição financeira com permissão de IAM na mesma chave amarra as duas evoluções entre si.

Boas práticas

Versione o esquema de tags em repositório com dono formal, e trate mudança de chave ou de enum como mudança de plataforma, com migração planejada para os recursos existentes. Aplique default_tags na raiz dos módulos de Terraform, valide as chaves no pipeline com política as code, e mantenha a política de negação na conta como rede de segurança, aceitando que o enforcement tem custo pequeno e retorno permanente. Publique o relatório de custo por tag em cadência fixa, com a linha residual em destaque, e revise a fração sem tag toda semana até o teto acordado. Por fim, caminhe do showback para o chargeback por estágio, com calendário e compromisso da controladoria, pois alocação de custo madura é a que fecha o ciclo entre decisão de arquitetura e orçamento, e é isso que o FinOps existe para construir.