Visibilidade de custos no EKS: você não gerencia o que não mede

Quanto custa cada time, namespace ou aplicação no seu cluster AWS EKS? Neste artigo, você vai montar a visibilidade de custos no EKS em camadas: cost allocation tags e Cost Explorer, Split Cost Allocation Data no CUR 2.0, labels do Kubernetes como tags de custo e Kubecost. Também vai ver quando usar cada opção e um checklist para começar.

Series: Otimização de custos com AWS EKS (5 articles)

1
Dimensões de custo no EKS: por que o Kubernetes é diferente
2
Visibilidade de custos no EKS: você não gerencia o que não mede This article
3
Rightsizing de pods no EKS: por que seus containers pedem demais

Felipe Olivieri

Solution Architect

Published Oct 11, 2026

Last modified Oct 11, 2026

Num cluster AWS EKS , a fatura da nuvem mostra infraestrutura, enquanto o Kubernetes organiza aplicações, como vimos no post sobre as dimensões de custo no EKS . Uma instância AWS EC2 aparece como uma linha só, mas pode rodar pods de cinco times diferentes. Sem visibilidade de custos no EKS, perguntas simples ficam sem resposta. Quanto custa o namespace do time de pagamentos? Qual aplicação dobrou de custo no último mês? Quanto da capacidade que pagamos está parada?

Um post da série "Otimização de custos com AWS EKS".

Neste post, vamos montar essa visibilidade em camadas, da mais simples à mais detalhada:

Cost allocation tags e AWS Cost Explorer , para a visão por cluster;
Split Cost Allocation Data (SCAD) no CUR 2.0, para o custo por pod, namespace e workload, direto na fatura da AWS;
Labels do Kubernetes como cost allocation tags, para alocar por time, aplicação ou centro de custo;
Kubecost, para análise em tempo real dentro do cluster e recomendações de otimização.

No fim, você terá um critério para escolher o que usar e um checklist para começar.

Camada 1: cost allocation tags e Cost Explorer (visão por cluster)

O primeiro passo é saber quanto custa cada cluster. Para isso, a AWS usa cost allocation tags , que podem ser de dois tipos:

Tags geradas pela AWS , com o prefixo aws:. A mais importante aqui é a aws:eks:cluster-name, que identifica a qual cluster EKS um recurso pertence.
Tags definidas por você , como environment, team ou cost-center, aplicadas aos seus recursos AWS.

Um detalhe costuma confundir: a tag só aparece nas ferramentas de billing depois de ativada. A ativação é feita na página Cost allocation tags do console de Billing and Cost Management. A partir daí, a tag vira dimensão de agrupamento no Cost Explorer e coluna no Cost and Usage Report.

Com isso, você já consegue responder:

Quanto custa o cluster de produção e quanto custa o de homologação?
Qual é a tendência de custo de cada cluster nos últimos meses?
Quanto de cada cluster é EC2, AWS EBS ou load balancer?

Essa visão, porém, para no nível da instância. O Cost Explorer sabe quanto custou o nó, mas não sabe quais pods rodaram nele. Para dividir o custo de um nó compartilhado entre aplicações, precisamos descer até o pod.

Camada 2: Split Cost Allocation Data no CUR 2.0 (visão por pod)

O Split Cost Allocation Data (SCAD) resolve exatamente esse problema. Ele traz para o AWS Cost and Usage Report (CUR) o custo e o uso de cada pod do Kubernetes. Esse valor é calculado a partir do custo da instância EC2 em que o pod rodou.

Segundo o anúncio da AWS de abril de 2024 , o recurso não tem custo adicional. Ele está disponível em todas as regiões comerciais da AWS, exceto as da China. Ainda assim, considere os custos indiretos. O CUR é entregue num bucket AWS S3 , e consultar os dados com AWS Athena ou visualizá-los no AWS Quick Sight tem cobrança própria. Confira as condições atuais na documentação do Split Cost Allocation Data .

💰 Preços de referência: outubro de 2026. A informação de que o Split Cost Allocation Data não tem custo adicional vem do anúncio da AWS de abril de 2024, e as condições podem ter mudado. Confira os preços atuais dos serviços envolvidos nas páginas de preço do AWS S3 , do AWS Athena e do AWS Quick Sight , e acompanhe as novidades na página de gerenciamento financeiro na nuvem da AWS .

Como o custo de um nó é dividido entre os pods

Entender o cálculo ajuda a confiar no número e a explicá-lo para os times que vão recebê-lo:

Custo de partida. O SCAD usa o custo amortizado da instância EC2, ou seja, já considera Savings Plans e Reserved Instances.
Peso de CPU e memória. Para dividir o custo da instância entre CPU e memória, o SCAD usa uma proporção de 9:1 (vCPU:GB). Essa proporção vem do preço relativo de vCPU e de memória no AWS Fargate .
Recurso alocado por pod. Para cada pod, vale o maior valor entre o request e o uso real de CPU e memória. No modo de requests, explicado abaixo, o uso real é considerado zero e vale o request.
Custo dividido (split cost). Cada pod recebe a fração da instância proporcional ao que alocou.
Custo ocioso (unused cost). A capacidade que nenhum pod alocou é redistribuída entre os pods, na proporção do que cada um alocou.

Como resultado, a soma do custo dos pods de um nó é igual ao custo do nó. Nenhum centavo fica sem dono, e o custo ocioso fica visível em vez de desaparecer.

Exemplo ilustrativo

Os valores abaixo são hipotéticos, só para entender a lógica. Imagine um nó que custa US$ 1,00 por hora, com quatro pods que alocam juntos 80% da capacidade:

Os quatro pods recebem US$ 0,80 de custo dividido, conforme a fração de cada um.
Os US$ 0,20 restantes correspondem à capacidade parada e são distribuídos entre eles como custo ocioso.
Assim, se um pod alocou metade do que foi alocado no nó, ele recebe metade desses US$ 0,20.

💰 Preços de referência: outubro de 2026. Os valores deste exemplo são hipotéticos e servem só para mostrar a lógica do cálculo. Para saber o custo real de uma instância, consulte a página de preços do AWS EC2 , porque os valores mudam com o tempo e variam por região.

💡 O custo ocioso é um ótimo indicador para os próximos passos da série. Um namespace com muito custo ocioso aponta para nós grandes demais ou mal aproveitados, assunto dos posts sobre rightsizing e sobre Cluster Autoscaler x Karpenter.

Três formas de medir o uso dos pods

Ao ativar o SCAD para o EKS, você escolhe de onde vêm as métricas de CPU e memória:

Opção	Como aloca o custo	Quando usar
Resource requests	Só pelos requests de CPU e memória dos pods	Para incentivar os times a pedir só o que precisam. É a opção mais simples.
AWS Managed Service for Prometheus	Pelo maior valor entre request e uso real	Para que cada time pague pelo que usa, inclusive acima do request. Exige all features habilitado no AWS Organizations.
AWS CloudWatch Container Insights	Usa as métricas do Container Insights	Para clusters que já usam Container Insights e querem mais granularidade nos custos compartilhados.

Pontos de atenção

Sem request, sem custo dividido. No modo de requests, pods sem request de CPU e memória não recebem custo. É mais um motivo para sempre declarar requests, como veremos no post sobre application profiling e rightsizing.
Instâncias aceleradas. Com GPUs NVIDIA e AMD, AWS Trainium e AWS Inferentia, o SCAD também aloca o custo do acelerador por pod. Nesse caso, porém, só no modo de requests.
Mais linhas no CUR. Cada pod gera dois registros por hora, um de CPU e outro de memória, ou três em instâncias aceleradas. Pela fórmula da documentação, mil pods com vida média de até uma hora geram cerca de 48 mil registros por dia. Planeje o armazenamento e as consultas com isso em mente.

Passo a passo para ativar

Ative o SCAD . Na conta de gerenciamento (payer), abra o console de Billing and Cost Management e vá em Cost Management preferences. Em Split cost allocation data, selecione o EKS (Elastic Kubernetes Service) e o modo de medição.
Crie ou edite uma exportação do CUR 2.0. Em Data Exports , crie uma exportação do tipo CUR 2.0, ou edite uma existente, e marque Include split cost allocation data. A AWS recomenda incluir os resource IDs e usar granularidade horária.
Espere até 24 horas. O SCAD varre os clusters de toda a família de faturamento consolidado, em todas as contas e regiões. Em seguida, os dados começam a aparecer no CUR.

⚠️ O SCAD não aparece no Cost Explorer. Ele existe apenas no CUR legado e no CUR 2.0. Para analisar os dados, consulte o CUR com o Athena ou use um dashboard pronto, como o que mostramos mais abaixo.

As tags que o SCAD cria

Ao ativar o SCAD, o EKS passa a ter novas cost allocation tags geradas pela AWS, ativadas por padrão:

Tag	O que contém
aws:eks:cluster-name	Nome do cluster
aws:eks:namespace	Namespace do pod
aws:eks:node	Nó em que o pod rodou
aws:eks:workload-type	Tipo de workload: ReplicaSet, StatefulSet, Job, DaemonSet ou ReplicationController
aws:eks:workload-name	Nome do workload
aws:eks:deployment	Deployment que criou o ReplicaSet (só para workloads do tipo ReplicaSet)

Se você já tinha desativado a tag aws:eks:cluster-name no passado, o SCAD respeita essa escolha e não a reativa. Nesse caso, ative-a manualmente na página Cost allocation tags.

Um exemplo de consulta

No CUR 2.0, o SCAD adiciona colunas com o prefixo split_line_item_ . Para começar, estas são as mais úteis:

Coluna	O que contém
split_line_item_split_cost	Custo alocado ao pod
split_line_item_unused_cost	Parte do custo ocioso do nó redistribuída para o pod
split_line_item_net_split_cost e split_line_item_net_unused_cost	As mesmas métricas depois de descontos (só aparecem se a conta tiver descontos)
split_line_item_parent_resource_id	A instância EC2 em que o pod rodou

Consulta de exemplo no Athena

Uma consulta no Athena para ver o custo por namespace no mês fica assim:

1
2
3
4
5
6
7
8
9
10
11
12
13
-- Custo por namespace no mês (custo alocado + custo ocioso redistribuído)
-- Ajuste o nome da tabela e o filtro de período para o seu ambiente.
SELECT
  resource_tags['aws_eks_cluster_name'] AS cluster,
  resource_tags['aws_eks_namespace']    AS namespace,
  ROUND(SUM(split_line_item_split_cost),  2) AS custo_alocado,
  ROUND(SUM(split_line_item_unused_cost), 2) AS custo_ocioso,
  ROUND(SUM(split_line_item_split_cost + split_line_item_unused_cost), 2) AS custo_total
FROM cur2
WHERE bill_billing_period_start_date = TIMESTAMP '2026-10-01 00:00:00'
  AND split_line_item_split_cost IS NOT NULL
GROUP BY 1, 2
ORDER BY custo_total DESC;

💡 No CUR 2.0, as tags ficam numa coluna do tipo mapa (resource_tags). Só aparecem as chaves ativadas como cost allocation tags, e os nomes são normalizados: as tags de usuário, como as labels do Kubernetes, ganham o prefixo user_ (por exemplo, resource_tags['user_team']), e hífens e dois-pontos viram sublinhado. Antes de rodar, liste as chaves com SELECT DISTINCT map_keys(resource_tags) FROM cur2 LIMIT 10;.

Camada 3: labels do Kubernetes como cost allocation tags

Namespace, cluster e workload já ajudam muito. Mas a forma como a sua empresa quer dividir o custo nem sempre coincide com a estrutura do cluster. Por exemplo, um namespace pode ter aplicações de dois times, ou um time pode ter aplicações em vários namespaces.

Desde outubro de 2025 , o SCAD importa as labels dos pods como cost allocation tags definidas pelo usuário. Com isso, você aloca custos por qualquer atributo de negócio que já esteja nas labels, como team, app, cost-center, environment ou business-unit.

Exemplo de labels no Deployment

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout
  namespace: ecommerce
spec:
  replicas: 3
  selector:
    matchLabels:
      app: checkout
  template:
    metadata:
      labels:
        app: checkout            # aplicação
        team: pagamentos         # time dono
        cost-center: cc-1234     # centro de custo
    spec:
      containers:
        - name: checkout
          image: <sua-imagem>
          resources:
            requests:            # no modo de requests, sem request não há custo dividido
              cpu: "500m"
              memory: "512Mi"

⚠️ O que importa para o SCAD são as labels do pod, no template.metadata.labels, e não as labels do Deployment.

Como ativar as labels

Com o SCAD já ativo, aplique as labels nos pods pelo manifesto, pelo Helm ou pelo pipeline de CI/CD.
Em até 24 horas, as labels aparecem na página Cost allocation tags, como tags definidas pelo usuário.
Ative as labels que você quer usar. A ativação é feita na conta de gerenciamento e pode levar mais 24 horas para valer.
Depois disso, cada label ativada vira uma coluna nova no CUR (por exemplo, resourceTags/user:team no CUR legado).

Limites e boas práticas

Até 50 labels por pod são importadas. A lista é ordenada em ordem alfabética, e o que passa de 50 é descartado. Alguns serviços gerenciados da AWS também adicionam labels aos pods, e elas entram nessa conta. Portanto, planeje os nomes para que as labels de custo fiquem entre as 50 primeiras.
Limite de caracteres: chaves com mais de 128 caracteres e valores com mais de 256 caracteres não são importados.
Limite de tags ativas: 50 tags definidas pelo usuário por recurso e 500 por conta payer. As tags geradas pelo sistema não entram nessa conta.
Remover a label não desativa a tag. A coluna continua sendo preenchida até você desativá-la explicitamente.
Padronize as chaves. Defina um conjunto pequeno e obrigatório, como team, app e cost-center, e exija essas labels com uma política de admissão no cluster.

O pulo do gato: custo total da aplicação

As labels ficam ainda mais úteis quando você usa a mesma chave e o mesmo valor nas labels dos pods e nas tags dos recursos AWS da aplicação. É o caso de bancos AWS RDS , buckets S3 e domínios AWS OpenSearch Service .

Por exemplo, se os pods do checkout têm a label app: checkout e o banco RDS dele tem a tag app: checkout, o CUR soma os dois sob a mesma cost allocation tag app. O resultado é o custo total de propriedade da aplicação: os pods e os serviços que ela usa, numa única visão.

Visualizando: o Containers Cost Allocation Dashboard

Consultar o CUR com SQL é poderoso, mas nem todo mundo da empresa vai fazer isso. Por isso, os Cloud Intelligence Dashboards oferecem o SCAD Containers Cost Allocation Dashboard, um dashboard pronto no Quick Sight construído sobre os dados do SCAD. Ele mostra o custo de workloads EKS e AWS ECS até o nível de pod ou tarefa, com filtros por cluster, namespace e workload.

Em outras palavras, é uma boa opção de showback para os times, sem instalar nada no cluster. Para implantar, siga os pré-requisitos da documentação do dashboard . Um deles é ativar o parâmetro de SCAD no CUR 2.0 ao implantar os dashboards de base.

Camada 4: Kubecost (visão em tempo real dentro do cluster)

O SCAD trabalha com os dados da fatura: os números são exatos, mas chegam com algumas horas de atraso. Para quem precisa de visibilidade quase em tempo real e de recomendações de otimização, a AWS oferece um bundle do Kubecost otimizado para o EKS, fruto de uma colaboração entre a AWS e a Kubecost .

O Kubecost roda dentro do cluster e mostra o custo por pod, nó, namespace, label e outros objetos do Kubernetes. Por baixo, ele usa o OpenCost , um projeto open source da CNCF que serve de motor de alocação de custos para Kubernetes. Além de mostrar o custo, o Kubecost traz:

Eficiência: quanto do que foi pedido está sendo usado, por namespace, workload e container;
Recomendações de rightsizing de requests de containers e de nós;
Detecção de desperdício, como workloads abandonados e discos sem uso.

Como instalar

A documentação do EKS sugere dois caminhos:

Como add-on do EKS, o caminho mais simples para quem está começando;
Com Helm, para quem precisa customizar a instalação.

Além disso, há dois pontos de atenção na versão atual:

No Kubecost v3, o Helm chart mudou para public.ecr.aws/kubecost/kubecost. Se você está atualizando a partir da v2, ajuste as referências ao repositório.
Em instalações com vários clusters, o Kubecost v3 guarda as métricas em armazenamento de objetos compatível com S3. No EKS, isso significa o S3, no lugar do armazenamento compatível com Prometheus usado na v2.

O bundle otimizado para o EKS pode ser suportado pelos seus contratos de suporte da AWS. Confira as versões disponíveis e o que cada uma inclui na documentação de instalação do Kubecost no EKS .

⚠️ Cuidado ao aplicar recomendações automaticamente. Se a configuração do cluster é gerenciada por GitOps, mudar requests direto no cluster cria drift entre o repositório e o que está rodando. Prefira levar as recomendações para o seu pipeline.

Qual usar? SCAD, Kubecost ou os dois

	Cost Explorer + tags	SCAD no CUR 2.0	Kubecost
Granularidade	Cluster e recurso AWS	Pod, namespace, workload e labels	Pod, container, namespace, labels e outros objetos
Fonte dos dados	Fatura da AWS	Fatura da AWS (custo amortizado, com descontos)	Métricas do cluster e preços da AWS (com integração ao CUR para mais precisão)
Atualização	Diária	Até 24 horas	Quase em tempo real
Onde roda	Console da AWS	CUR no S3, consultado com Athena ou Quick Sight	Dentro do cluster
Pontos fortes	Simples, já disponível	Bate com a fatura; multi-conta e multi-cluster sem instalar nada no cluster	Recomendações de otimização e análise operacional rápida
Bom para	Visão executiva	Showback, chargeback e FinOps	Times de plataforma e de aplicação no dia a dia

Na prática, para montar a visibilidade de custos no EKS, as abordagens se complementam:

Use o SCAD como fonte oficial de alocação de custo, porque ele bate com a fatura e cobre toda a organização.
Use o Kubecost como ferramenta operacional dos times, para investigar e otimizar no dia a dia.
Por fim, use as mesmas labels nos dois, para que os números conversem.

Boas práticas de visibilidade de custos no EKS

Ter os dados não basta, porque eles precisam chegar a quem toma as decisões. Para que a visibilidade de custos no EKS seja útil:

Defina a unidade de alocação. Namespace por time é um bom começo, e as labels de team, app e cost-center refinam a visão.
Torne as labels obrigatórias. Sem governança, a alocação degrada em semanas. Use uma política de admissão para rejeitar pods sem as labels de custo.
Decida o que fazer com o custo compartilhado. Control plane, DaemonSets de observabilidade, controllers e capacidade ociosa precisam de uma regra clara: rateio proporcional, divisão igual ou absorção pelo time de plataforma.
Comece com showback e só depois parta para chargeback. Mostrar o custo para os times já muda comportamentos. A cobrança interna pode vir quando os números forem confiáveis.
Monitore continuamente. Crie relatórios recorrentes e alertas para variações fora do padrão, em vez de olhar a fatura só no fim do mês.

Para estruturar o processo do lado de FinOps, o guia da FinOps Foundation sobre como calcular e alocar custos de containers é um bom complemento.

Checklist do post

Ativar a tag aws:eks:cluster-name (e as tags de ambiente e time) na página Cost allocation tags
Ativar o Split Cost Allocation Data para o EKS e escolher o modo de medição
Criar uma exportação do CUR 2.0 com SCAD, resource IDs e granularidade horária
Garantir que todos os pods tenham requests de CPU e memória
Definir as labels obrigatórias de custo e aplicá-las nos pods
Ativar essas labels como cost allocation tags
Usar as mesmas chaves de tag nos recursos AWS de cada aplicação (RDS, S3 etc.)
Implantar o Containers Cost Allocation Dashboard para showback
Avaliar o Kubecost para visibilidade em tempo real e recomendações

Perguntas frequentes

O Split Cost Allocation Data tem custo?

Segundo o anúncio da AWS de abril de 2024, o recurso não tem custo adicional. Mesmo assim, você paga pelo armazenamento do CUR no S3 e pelas consultas no Athena ou no Quick Sight. Confira as condições atuais na documentação do Split Cost Allocation Data .

💰 Preços de referência: outubro de 2026. Essas condições podem ter mudado. Confira os preços atuais nas páginas de preço do AWS S3 , do AWS Athena e do AWS Quick Sight .

O SCAD aparece no Cost Explorer?

Não. Os dados do SCAD existem apenas no CUR legado e no CUR 2.0. Para analisá-los, consulte o CUR com o Athena ou use o Containers Cost Allocation Dashboard.

Como ver o custo por namespace no EKS?

Ative o SCAD, crie uma exportação do CUR 2.0 com os dados de split e agrupe o custo pela tag aws:eks:namespace. A consulta de exemplo deste post faz exatamente isso.

Kubecost ou OpenCost: qual a diferença?

O OpenCost é o projeto open source da CNCF que calcula a alocação de custos no Kubernetes. O Kubecost é construído sobre ele e acrescenta recursos como recomendações de rightsizing e detecção de desperdício.

Quanto tempo leva para os dados aparecerem no CUR?

Até 24 horas depois de ativar o SCAD. No caso das labels do Kubernetes, elas levam até 24 horas para aparecer como cost allocation tags e até mais 24 horas para valer depois de ativadas.

Próximo post

Agora que você tem visibilidade de custos no EKS e sabe quanto cada aplicação custa, a pergunta seguinte é: quanto dessa conta é desperdício? No próximo post da série, vamos falar de application profiling e rightsizing, e entender por que os containers costumam pedir muito mais recurso do que usam.

# amazon-eks # cost-optimization # kubernetes

Series: Otimização de custos com AWS EKS (5 articles)

1
Dimensões de custo no EKS: por que o Kubernetes é diferente
2
Visibilidade de custos no EKS: você não gerencia o que não mede This article
3
Rightsizing de pods no EKS: por que seus containers pedem demais

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

Visibilidade de custos no EKS: você não gerencia o que não mede

Series: Otimização de custos com AWS EKS (5 articles)

Felipe Olivieri

Camada 1: cost allocation tags e Cost Explorer (visão por cluster)

Camada 2: Split Cost Allocation Data no CUR 2.0 (visão por pod)

Como o custo de um nó é dividido entre os pods

Exemplo ilustrativo

Três formas de medir o uso dos pods

Pontos de atenção

Passo a passo para ativar

As tags que o SCAD cria

Um exemplo de consulta

Consulta de exemplo no Athena

Camada 3: labels do Kubernetes como cost allocation tags

Exemplo de labels no Deployment

Como ativar as labels

Limites e boas práticas

O pulo do gato: custo total da aplicação

Visualizando: o Containers Cost Allocation Dashboard

Camada 4: Kubecost (visão em tempo real dentro do cluster)

Como instalar

Qual usar? SCAD, Kubecost ou os dois

Boas práticas de visibilidade de custos no EKS

Checklist do post

Perguntas frequentes

O Split Cost Allocation Data tem custo?

O SCAD aparece no Cost Explorer?

Como ver o custo por namespace no EKS?

Kubecost ou OpenCost: qual a diferença?

Quanto tempo leva para os dados aparecerem no CUR?

Próximo post

Series: Otimização de custos com AWS EKS (5 articles)