Estratégias e Boas Práticas 14 min de leitura

Tags para Alocação de Custos na Nuvem: Guia Prático com Terraform para AWS, Azure e GCP

Implemente uma estratégia de tags para alocação de custos na nuvem com Terraform. Exemplos práticos para AWS (SCPs), Azure (Policy) e GCP (labels) com automação e validação CI/CD.

Editorial Team

Por Que a Alocação de Custos É o Alicerce do FinOps

Você sabe — de verdade — quanto cada equipe, projeto ou microsserviço gasta na sua infraestrutura em nuvem? Se a resposta é "mais ou menos" ou um silêncio constrangedor, saiba que você não está sozinho. Segundo o State of FinOps 2026 Report, 72% das empresas globais ultrapassaram seus orçamentos de cloud em 2025. E o motivo? Quase sempre o mesmo: falta de visibilidade granular sobre quem gasta o quê.

Isso é um problema sério. Estudos recentes apontam que entre 30% e 40% dos gastos com nuvem são desperdiçados — recursos ociosos, superdimensionados ou simplesmente esquecidos rodando ali, queimando dinheiro 24/7.

Mas aqui vai o ponto: antes de otimizar qualquer coisa, você precisa enxergar o problema. E é exatamente aí que entra a estratégia de tags (ou labels, no caso do GCP) para alocação de custos — o alicerce sobre o qual toda prática de FinOps é construída.

Neste guia, vamos além da teoria. Você vai aprender a projetar uma taxonomia de tags, implementá-la nos três grandes provedores e, o mais importante, automatizar tudo com Terraform e políticas nativas para que nenhum recurso escape sem identificação. Bora lá.

O Que São Tags de Alocação de Custos

Tags são pares de chave-valor (Key = Value) que você atribui a recursos de nuvem. Pense nelas como etiquetas digitais que respondem perguntas simples mas poderosas: "De quem é esse recurso?", "Qual projeto ele atende?" e "É produção ou desenvolvimento?".

Cada provedor implementa o conceito de forma ligeiramente diferente:

  • AWS: Chama de Tags. Limite de 50 tags por recurso. Chaves são case-sensitive (sim, Environment e environment são tags diferentes — já vi isso causar confusão real).
  • Azure: Também usa Tags. Limite de 50 tags por recurso, aplicáveis tanto ao recurso quanto ao resource group de forma independente.
  • GCP: Usa o termo Labels. Limite de 64 labels por recurso. Obrigatoriamente em minúsculas, sem espaços ou caracteres especiais além de hífen e underscore.

Um detalhe que pega muita gente de surpresa: a diferença entre uma tag qualquer e uma tag de alocação de custos é que esta última precisa ser ativada no sistema de billing do provedor. Na AWS, por exemplo, você precisa ativar as tags no console de Billing and Cost Management antes que elas apareçam no Cost Explorer. Sem essa ativação, suas tags existem nos recursos mas não aparecem nos relatórios financeiros.

Projetando Sua Taxonomia de Tags

O erro mais comum — e eu já vi isso acontecer em várias empresas — é começar com tags demais ou de menos. Exigir 20 tags obrigatórias no primeiro dia praticamente garante baixa adoção. As equipes simplesmente contornam a exigência ou preenchem com valores genéricos tipo "N/A". Por outro lado, começar com apenas uma ou duas não oferece granularidade suficiente para uma alocação que faça sentido.

O Ponto Ideal: 5 a 8 Tags Obrigatórias

Com base nas melhores práticas da indústria e na experiência de organizações com programas de FinOps maduros, o conjunto inicial que funciona bem é este:

Tag KeyExemplo de ValorPropósito
Environmentprod, staging, devSeparar custos por ambiente
Teambackend, data, mobileResponsabilidade por equipe
CostCenterCC-1042Integração com sistema financeiro
Applicationapi-gateway, ml-pipelineCusto por aplicação
Ownerjoao.silvaPonto de contato para alertas
ManagedByterraform, manualRastreabilidade de provisionamento

Padronização de Nomenclatura

Consistência aqui é tudo. Se uma equipe usa Environment, outra env e uma terceira Env, seus relatórios de alocação viram uma bagunça. Defina e documente desde o início:

  • Formato das chaves: PascalCase (CostCenter) ou kebab-case (cost-center) — escolha um e mantenha. Misturar os dois é receita para dor de cabeça.
  • Valores permitidos: Use listas controladas. Environment aceita apenas prod, staging, dev, sandbox — nada de production, Prod ou PRD.
  • Cross-cloud: O GCP exige labels em minúsculas. Se você opera em multi-cloud, normalize para minúsculas ou documente o mapeamento (ex.: CostCenter na AWS/Azure → cost-center no GCP).

Tags Opcionais que Agregam Valor

Além das obrigatórias, vale considerar algumas tags opcionais que ajudam bastante em automação e compliance:

  • AutoShutdown = true — para ambientes não-produtivos que podem ser desligados à noite. Honestamente, essa tag sozinha pode gerar economia de até 65%.
  • DataClassification = confidential — útil para compliance e auditoria.
  • ExpirationDate = 2026-06-30 — para recursos temporários, evitando aquele clássico cloud waste de "criei para testar e esqueci".

Implementação na AWS: Tags + Cost Explorer + SCPs

Passo 1: Criar e Aplicar Tags via Terraform

A maneira mais confiável de garantir que todo recurso nasce com tags é aplicá-las diretamente no código de infraestrutura. No Terraform, o bloco default_tags no provider da AWS é seu melhor amigo — ele aplica tags automaticamente a todos os recursos:

provider "aws" {
  region = "us-east-1"

  default_tags {
    tags = {
      Environment = "prod"
      Team        = "backend"
      CostCenter  = "CC-1042"
      Application = "api-gateway"
      Owner       = "joao.silva"
      ManagedBy   = "terraform"
    }
  }
}

resource "aws_instance" "app_server" {
  ami           = "ami-0c02fb55956c7d316"
  instance_type = "m6i.large"

  # Tags adicionais específicas deste recurso
  tags = {
    Name = "app-server-prod-01"
  }
}

Com essa configuração, toda instância EC2, bucket S3, função Lambda ou qualquer outro recurso criado nesse módulo herdará automaticamente as seis tags padrão, além das tags específicas definidas individualmente. Simples e eficaz.

Passo 2: Ativar Tags de Alocação de Custos

Depois de aplicar as tags nos recursos, você precisa ativá-las no AWS Billing. Dá pra fazer pelo console, mas via CLI é mais rápido:

# Listar tags disponíveis para alocação
aws ce list-cost-allocation-tags --status inactive

# Ativar tags específicas
aws ce update-cost-allocation-tags-status   --cost-allocation-tags-status   '[{"TagKey":"Environment","Status":"Active"},{"TagKey":"Team","Status":"Active"},{"TagKey":"CostCenter","Status":"Active"},{"TagKey":"Application","Status":"Active"}]'

Atenção: Tags recém-ativadas só começam a aparecer nos relatórios de custo a partir do dia seguinte. E dados históricos não são retroativamente tagueados — outro motivo para configurar isso o quanto antes.

Passo 3: Aplicar Guardrails com SCPs

Tag Policies da AWS controlam os valores permitidos para tags, mas (e isso surpreende muita gente) não impedem a criação de recursos sem tags. Para fechar essa brecha, combine com Service Control Policies (SCPs):

resource "aws_organizations_policy" "require_tags_scp" {
  name        = "RequireTagsOnEC2"
  description = "Impede criacao de instancias EC2 sem tags obrigatorias"
  type        = "SERVICE_CONTROL_POLICY"

  content = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid       = "DenyEC2WithoutTags"
        Effect    = "Deny"
        Action    = ["ec2:RunInstances"]
        Resource  = ["arn:aws:ec2:*:*:instance/*"]
        Condition = {
          "StringNotLike" = {
            "aws:RequestTag/Environment" = ["prod", "staging", "dev", "sandbox"]
          }
        }
      },
      {
        Sid       = "DenyEC2WithoutCostCenter"
        Effect    = "Deny"
        Action    = ["ec2:RunInstances"]
        Resource  = ["arn:aws:ec2:*:*:instance/*"]
        Condition = {
          "Null" = {
            "aws:RequestTag/CostCenter" = "true"
          }
        }
      }
    ]
  })
}

resource "aws_organizations_policy_attachment" "require_tags" {
  policy_id = aws_organizations_policy.require_tags_scp.id
  target_id = "ou-xxxx-yyyyyyyy" # ID da OU alvo
}

Com essa SCP em vigor, qualquer tentativa de criar uma instância EC2 sem as tags Environment e CostCenter será bloqueada, independentemente das permissões IAM do usuário. É um guardrail que funciona de verdade.

Implementação no Azure: Tags + Azure Policy + Herança

Passo 1: Tags no Terraform com Azure

No Azure, a abordagem ideal é definir tags no resource group e herdá-las nos recursos filhos. Isso centraliza a gestão e evita repetição desnecessária:

resource "azurerm_resource_group" "app" {
  name     = "rg-api-gateway-prod"
  location = "Brazil South"

  tags = {
    Environment = "prod"
    Team        = "backend"
    CostCenter  = "CC-1042"
    Application = "api-gateway"
    Owner       = "joao.silva"
    ManagedBy   = "terraform"
  }
}

resource "azurerm_linux_virtual_machine" "app_server" {
  name                = "vm-api-prod-01"
  resource_group_name = azurerm_resource_group.app.name
  location            = azurerm_resource_group.app.location
  size                = "Standard_D2s_v5"

  # Herda tags do resource group + adiciona específicas
  tags = merge(azurerm_resource_group.app.tags, {
    Role = "application-server"
  })

  # ... demais configurações
}

Passo 2: Aplicar Azure Policy para Tags Obrigatórias

O Azure Policy é bem poderoso nesse cenário. Ele permite tanto bloquear a criação de recursos sem tags quanto aplicar herança automática do resource group:

# Policy: Exigir tag Environment em todos os recursos
resource "azurerm_resource_group_policy_assignment" "require_env" {
  name                 = "require-environment-tag"
  resource_group_id    = azurerm_resource_group.app.id
  policy_definition_id = "/providers/Microsoft.Authorization/policyDefinitions/871b6d14-10aa-478d-b466-ce391587edef"

  parameters = jsonencode({
    tagName = { value = "Environment" }
  })

  non_compliance_message {
    content = "Todos os recursos devem ter a tag Environment definida."
  }
}

# Policy: Herdar tag CostCenter do Resource Group
resource "azurerm_resource_group_policy_assignment" "inherit_costcenter" {
  name                 = "inherit-costcenter-from-rg"
  resource_group_id    = azurerm_resource_group.app.id
  policy_definition_id = "/providers/Microsoft.Authorization/policyDefinitions/cd3aa116-8754-49c9-a813-ad46512ece54"
  location             = azurerm_resource_group.app.location

  identity {
    type = "SystemAssigned"
  }

  parameters = jsonencode({
    tagName = { value = "CostCenter" }
  })
}

Dica importante: A policy de herança usa o efeito Modify e requer uma managed identity com a role Tag Contributor. Sem essa role, a remediação falha silenciosamente — e você fica achando que está tudo funcionando quando não está.

Passo 3: Auditar e Remediar Recursos Existentes

As políticas do Azure afetam apenas recursos novos por padrão. Para os recursos que já existem sem tags (o chamado "legado"), execute uma tarefa de remediação:

# Via Azure CLI
az policy remediation create   --name "remediate-costcenter-inheritance"   --policy-assignment "/subscriptions/{sub-id}/resourceGroups/rg-api-gateway-prod/providers/Microsoft.Authorization/policyAssignments/inherit-costcenter-from-rg"   --resource-group "rg-api-gateway-prod"

Implementação no GCP: Labels + Organization Policies

Passo 1: Labels no Terraform com GCP

No GCP, lembre-se de que labels exigem formato minúsculo com hífens ou underscores. Nada de PascalCase aqui:

resource "google_compute_instance" "app_server" {
  name         = "app-server-prod-01"
  machine_type = "e2-standard-4"
  zone         = "southamerica-east1-a"

  labels = {
    environment  = "prod"
    team         = "backend"
    cost-center  = "cc-1042"
    application  = "api-gateway"
    owner        = "joao-silva"
    managed-by   = "terraform"
  }

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-12"
    }
  }

  network_interface {
    network = "default"
  }
}

Passo 2: Aplicar Labels com Terraform Variables Obrigatórias

Uma técnica que funciona muito bem no GCP é usar variáveis Terraform com validação integrada. Isso garante que labels obrigatórios nunca passem em branco:

variable "mandatory_labels" {
  type = object({
    environment = string
    team        = string
    cost-center = string
    owner       = string
  })

  validation {
    condition = alltrue([
      contains(["prod", "staging", "dev", "sandbox"], var.mandatory_labels.environment),
      length(var.mandatory_labels.team) > 0,
      can(regex("^cc-[0-9]{4}$", var.mandatory_labels.cost-center)),
      length(var.mandatory_labels.owner) > 0
    ])
    error_message = "Labels obrigatorios devem seguir o padrao definido."
  }
}

resource "google_compute_instance" "app_server" {
  name         = "app-server-${var.mandatory_labels.environment}-01"
  machine_type = "e2-standard-4"
  zone         = "southamerica-east1-a"

  labels = var.mandatory_labels

  # ... demais configurações
}

Passo 3: Validação de Políticas no CI/CD

Aqui vai uma limitação importante do GCP: ele não possui um mecanismo nativo de deny para labels ausentes como as SCPs da AWS ou o Azure Policy deny. A alternativa (que na prática funciona bem) é validar no pipeline de CI/CD:

# No pipeline CI/CD, valide o plano Terraform contra políticas
terraform plan -out=tfplan
terraform show -json tfplan > tfplan.json

# Use gcloud para validar contra políticas organizacionais
gcloud beta terraform vet tfplan.json   --policy-library=./policy-library   --format=json

Outra opção é usar Open Policy Agent (OPA) ou Sentinel no seu pipeline Terraform para aplicar regras de labels independentemente do provedor. Para ambientes multi-cloud, essa acaba sendo a abordagem mais consistente.

Lidando com Custos Não-Tagueáveis

Nem tudo na nuvem pode ser tagueado — e essa é uma realidade que pega muita gente desprevenida. Custos de transferência de dados, taxas de suporte e certos serviços de marketplace simplesmente escapam das tags. Esses custos "invisíveis" podem representar de 10% a 20% da fatura total.

Então, o que fazer? Algumas estratégias:

  • Alocação proporcional: Distribua custos de transferência de dados proporcionalmente entre os recursos de computação tagueados que geram o tráfego.
  • AWS Cost Categories: Crie regras personalizadas para alocar custos não-tagueados a unidades de negócio específicas com base em padrões de conta ou serviço.
  • Virtual tagging: Plataformas de FinOps como Vantage, CloudZero e Apptio permitem criar tags virtuais que cobrem o que tags físicas não alcançam.
  • Azure Cost Management: Use cost allocation rules para redistribuir custos compartilhados entre subscriptions.

Medindo o Sucesso: KPIs de Cobertura de Tags

Implementar tags é só o começo. O trabalho de verdade está em medir e melhorar continuamente a cobertura. As métricas que realmente importam:

  • Taxa de cobertura de tags: Percentual de recursos com todas as tags obrigatórias. Meta realista: 85-90%.
  • Percentual de gastos alocados: Quanto do total da fatura pode ser atribuído a um dono. Meta: 95% ou mais.
  • Tempo de remediação: Quanto tempo leva para corrigir recursos não conformes após detecção.
  • Tag drift: Número de recursos que perdem tags ao longo do tempo, especialmente em ambientes com deploys frequentes (esse é mais traiçoeiro do que parece).

Configure dashboards no AWS Cost Explorer, Azure Cost Management ou Google Cloud Billing para monitorar essas métricas semanalmente. E não esqueça de configurar alertas para quando a cobertura cair abaixo do limiar definido.

Showback vs Chargeback: Usando Tags para Responsabilização

Com tags bem implementadas, você pode finalmente adotar modelos de responsabilização financeira. Na prática, existem dois caminhos:

  • Showback: Mostra para cada equipe quanto ela gasta, sem cobrar formalmente. Gera consciência de custo e é o primeiro passo recomendado — funciona surpreendentemente bem.
  • Chargeback: Os custos são efetivamente cobrados do orçamento de cada equipe ou departamento. Exige maior maturidade de tagging e processos financeiros mais robustos.

A maioria das organizações começa com showback e evolui para chargeback à medida que a cobertura de tags atinge 90% ou mais. E os resultados falam por si: segundo o State of FinOps 2026, organizações com chargeback implementado reduzem gastos desnecessários em 25% a 35% nos primeiros seis meses. Por quê? Porque as equipes passam a tratar cloud como custo real — e não como recurso infinito.

Checklist de Implementação

Para facilitar, aqui vai um checklist prático que você pode seguir passo a passo:

  1. Defina a taxonomia: 5-8 tags obrigatórias, padronize nomenclatura, documente valores permitidos.
  2. Implemente no IaC: Use default_tags no Terraform para AWS, tags no resource group para Azure, e variáveis validadas para GCP.
  3. Ative no billing: Habilite tags de alocação de custos nos consoles de billing de cada provedor.
  4. Aplique guardrails: SCPs na AWS, Azure Policy deny/modify, validação de CI/CD no GCP.
  5. Remedie o legado: Execute tarefas de remediação para tagear recursos existentes.
  6. Monitore cobertura: Dashboards semanais com meta de 85-90% de cobertura.
  7. Itere: Revise a taxonomia trimestralmente com feedback das equipes de engenharia e finanças.

Perguntas Frequentes

Como funciona a alocação de custos por tags na AWS?

Funciona em duas etapas. Primeiro, você aplica tags de chave-valor aos seus recursos (EC2, S3, RDS, etc.). Depois, ativa essas tags no console de Billing and Cost Management. Uma vez ativadas, os custos passam a ser exibidos segmentados por tag no AWS Cost Explorer e nos relatórios CUR (Cost and Usage Reports). Vale lembrar que tags geradas pela AWS (como aws:createdBy) são diferentes das tags definidas pelo usuário — mas ambas podem ser ativadas para alocação.

Qual é a diferença entre tags na AWS, no Azure e labels no GCP?

Funcionalmente, são conceitos equivalentes — metadados chave-valor aplicados a recursos. As diferenças estão nos detalhes: a AWS suporta até 50 tags por recurso com chaves case-sensitive; o Azure suporta 50 tags com herança nativa via Resource Groups; o GCP suporta 64 labels por recurso, mas exige minúsculas em tudo. Para ambientes multi-cloud, documente o mapeamento entre provedores (ex.: CostCenter na AWS → cost-center no GCP) e normalize os dados antes de gerar relatórios consolidados.

Como automatizar a aplicação de tags com Terraform?

No Terraform, a forma mais prática é usar o bloco default_tags no provider da AWS, que aplica tags automaticamente a todos os recursos. No Azure, defina tags no resource group e use merge() para herdá-las. No GCP, use variáveis com blocos validation para garantir que labels obrigatórios nunca fiquem em branco. Combine com as políticas nativas de cada provedor (SCPs, Azure Policy, GCP policy validation) para bloquear recursos sem tags.

O que fazer com custos que não podem ser tagueados?

Custos de transferência de dados, suporte e marketplace frequentemente não podem ser tagueados diretamente. Use alocação proporcional, AWS Cost Categories ou Azure cost allocation rules para criar regras de distribuição. Plataformas de FinOps com virtual tagging também ajudam a cobrir essas lacunas. A meta é alocar 95% ou mais dos gastos totais, aceitando que uma pequena parcela será distribuída por regras de negócio.

Quanto tempo leva para implementar uma estratégia de tags e ver resultados?

Na prática, dá pra fazer em fases: a definição da taxonomia e implementação no IaC leva de 1 a 2 semanas; a ativação no billing e configuração de guardrails, mais 1 semana; a remediação de recursos legados, de 2 a 4 semanas dependendo do volume. Os primeiros relatórios úteis aparecem em cerca de 30 dias. E aqui vai um dado motivador: organizações que adotam showback com tags consistentes reportam reduções de 15% a 25% nos gastos dentro dos primeiros 3 meses, porque a visibilidade por si só já muda o comportamento das equipes.

Sobre o Autor Editorial Team

Our team of expert writers and editors.

Artigos Relacionados