Tag parece o assunto mais simples do mundo do FinOps. Você cola uma etiqueta no recurso, ela aparece no relatório, e pronto, dá para saber quanto cada projeto, time ou cliente gasta.
Na teoria.
Na prática, o comportamento das cost allocation tags muda bastante dependendo de onde você está. Numa conta AWS sozinha ou dentro de uma Organization, com uma conta pagadora e várias contas membro. E é justamente esse recorte, muito comum em cenário de parceiro e cliente, que gera confusão, mensagem de Access Denied e relatório com metade do custo aparecendo como não alocado.
Neste artigo eu separo os dois mundos: como a tag funciona numa conta avulsa, o que muda numa Organization, e as armadilhas que valem para todo mundo.
Antes de tudo: tag tem dois momentos
Existe uma distinção que resolve a maior parte da confusão sobre o tema. Uma cost allocation tag passa por dois momentos diferentes, e eles acontecem em telas diferentes.
Aplicar a tag no recurso. É colar a etiqueta, do tipo ambiente igual a produção ou centro de custo igual a vendas, na instância EC2, no bucket S3, no banco RDS. Isso se faz no console de Resource Groups, na API, ou, de longe o melhor caminho, via infraestrutura como código.
Ativar a chave da tag para custo. Aplicar a etiqueta não faz o custo aparecer fatiado. Você precisa dizer à AWS que quer usar aquela chave como dimensão de custo, na página Cost Allocation Tags do console de Billing. Só depois disso a chave vira uma coluna utilizável no Cost Explorer e no relatório de uso.
Guarde esses dois momentos. É a diferença entre eles que muda de figura quando você entra numa Organization.
Cenário 1: a conta avulsa
Numa conta única, sem Organization, a vida é simples. Você faz os dois momentos na mesma conta. Aplica a tag nos recursos, vai na página de Cost Allocation Tags, ativa a chave, e pouco depois passa a ver o custo fatiado no Cost Explorer.
Tudo mora no mesmo lugar. Quem administra a conta controla tanto a aplicação quanto a ativação, e enxerga cem por cento do próprio custo. Não há hierarquia, não há disputa sobre quem manda em quê.
É o cenário mais direto. Também é o menos comum em ambiente corporativo, e por isso a maior parte do conteúdo disponível sobre tag não serve para quem realmente precisa.
Cenário 2: a Organization
Aqui está o pulo do gato, e o que a maioria dos artigos não explica. Numa Organization, os dois momentos se separam entre contas diferentes, e isso cria uma hierarquia clara.
A ativação só existe na conta pagadora
Você pode aplicar tag nos recursos de qualquer conta membro normalmente. Mas a ativação da chave para custo só pode ser feita na conta pagadora. É centralizada, para valer para a Organization inteira.
A consequência prática: se você abrir a página de Cost Allocation Tags dentro de uma conta membro, vai ver a mensagem de Access Denied dizendo que as tags são gerenciadas no nível da conta pagadora.
Isso assusta muita gente, e todo mundo começa a mexer em política de IAM tentando consertar. Não é erro nem falta de permissão. É o comportamento esperado. A conta membro não gerencia tag de custo, ela apenas consome. Nem AdministratorAccess muda isso, porque a tela simplesmente não existe funcionalmente ali.
Cada conta membro só vê o próprio custo
Uma vez que a chave está ativada na pagadora, cada conta membro passa a ver o próprio consumo fatiado por aquela tag. Uma conta não enxerga o custo da outra.
Repare no detalhe, porque ele é estratégico: o que garante o isolamento entre clientes ou times numa Organization não é a tag. É o fato de que a visão de custo de cada conta é limitada a ela mesma. A tag é granularidade, não fronteira.
A perspectiva parceiro e cliente
Esse modelo mapeia direitinho a relação entre parceiro e cliente.
O parceiro normalmente detém a conta pagadora. É ele quem ativa as chaves, define a governança e enxerga o consolidado.
O cliente costuma operar numa conta membro. Ele aplica tag nos próprios recursos e consome a visão de custo, mas depende do parceiro para ativar as chaves.
E para o cliente conseguir de fato abrir o Cost Explorer, ainda faltam dois ajustes que ficam sob controle do parceiro:
Linked account access habilitado nas preferências de Cost Management, autorizando conta membro a usar o Cost Explorer.
Permissão de IAM de Cost Explorer e Billing no usuário ou role dentro da conta do cliente.
Sem esses dois, a chave pode estar ativada e mesmo assim o cliente não vê nada, porque não consegue nem abrir a ferramenta. Esse é um chamado que abre muito, e quase sempre é diagnosticado errado como problema de tag.
Dois recursos que só fazem sentido em Organization
Account-level cost allocation tags. Você aplica a tag na própria conta, dentro do AWS Organizations, e todo o custo daquela conta passa a ser atribuído por ela. Inclusive o que a tag de recurso nunca alcança, como crédito, reembolso e taxa. Para alocação por unidade de negócio, cliente ou divisão num modelo multi conta, isso costuma ser mais robusto do que sair etiquetando recurso por recurso.
Tag Policies. Regras no Organizations que padronizam chave e valor em todas as contas, evitando o caos clássico de centro de custo escrito de três formas diferentes convivendo como se fossem coisas distintas. E para o Cost Explorer, são mesmo.
As armadilhas que valem para os dois mundos
Independente de estar numa conta avulsa ou numa Organization, alguns comportamentos pegam quase todo mundo de surpresa.
A tag não é retroativa. O custo passa a ser atribuído à tag a partir da data de ativação da chave, para frente. Todo o histórico anterior aparece como não alocado, de forma permanente, a menos que você use o Backfill tags, que reaplica ao passado, tipicamente até doze meses.
O ideal é o recurso nascer com a tag. Etiquetar depois, em ambiente já em produção, funciona, mas tem limitação, sobretudo em computação, e não conserta histórico. Taguear via código, na criação, é a prática que separa quem sofre de quem não sofre.
Nem todo recurso taggeado gera custo. Uma Task Definition de ECS não custa nada, é só o molde da aplicação. O custo vem das tasks em execução, que não herdam a tag automaticamente, é preciso configurar propagação. Etiquetar o recurso errado dá a falsa impressão de que a tag não funciona, quando na verdade não há custo pendurado nela.
Uma parte do custo nunca será fatiada por tag. Transferência de dados, processamento de NAT Gateway, parte do CloudWatch, plano de Support, imposto, crédito e reembolso são itens sem etiqueta possível no nível do recurso. É aqui que account tags e Cost Categories têm seu valor numa Organization, porque conseguem alocar o que a tag de recurso não pega.
A análise não acontece na tela de tags. A página de Cost Allocation Tags serve só para ativar chave. A análise é no Cost Explorer, agrupando por tag. E ao filtrar você vai ver dois grupos: os recursos que têm a chave, listados por valor, e um balde de sem chave de tag. Esse balde é exatamente a sua lacuna de cobertura, e é o número que importa acompanhar.
Tag ou conta como fronteira de custo?
Um último ponto estratégico, que só aparece quando você pensa em Organization.
A alocação de custo mais confiável da AWS não é a tag, é a própria conta. Se cada cliente, time ou ambiente tem conta dedicada, o custo daquele cliente já vem isolado, sem depender de etiqueta nenhuma.
A recomendação da própria AWS combina as duas coisas:
Conta como fronteira para a separação macro, seja cliente, unidade de negócio ou ambiente.
Tag para a granularidade dentro de cada conta, como projeto, aplicação e dono.
Cost Categories e account tags por cima, para reconciliar o que sobrar.
Resumo rápido
Na conta avulsa você aplica e ativa a tag no mesmo lugar. Simples e sem hierarquia.
Na Organization, aplicar é local e ativar é centralizado na pagadora. Access Denied na conta membro é normal, não é bug.
Cada conta membro só vê o próprio custo, e é isso que isola cliente e time.
Parceiro governa, cliente consome, mas o cliente ainda depende de linked account access e permissão de IAM para enxergar qualquer coisa.
Tag não é retroativa, o recurso deve nascer etiquetado, e uma fatia do custo sempre ficará sem tag.
Meta de boa governança: manter o não alocado baixo, idealmente abaixo de cinco a dez por cento, e cobrir o resto com account tags e Cost Categories.
Tag continua sendo extremamente importante na alocação de custo na AWS. Só que, quando você entra numa Organization, ela deixa de ser um botão que você aperta sozinho e passa a ser parte de uma governança compartilhada entre quem paga e quem consome. Entender esse recorte é o que separa um relatório de custo confiável de um cheio de não alocado.