Dimensões de custo no EKS: por que o Kubernetes é diferente
A fatura da AWS mostra instâncias, volumes e load balancers, mas não diz quanto custa cada aplicação no Kubernetes. Neste artigo, você vai entender o que torna o custo no AWS EKS diferente e conhecer as oito dimensões de custo no EKS, do control plane à observabilidade, com as armadilhas mais comuns em cada uma. É o ponto de partida para otimizar custos no EKS.
Series: Otimização de custos com AWS EKS (5 articles)
- 1Dimensões de custo no EKS: por que o Kubernetes é diferente This article
Abra a fatura de uma conta que roda AWS EKS e você vai encontrar linhas conhecidas. Lá estão instâncias AWS EC2 , volumes AWS EBS , load balancers, transferência de dados, AWS CloudWatch e uma linha pequena do próprio EKS. No entanto, nenhuma delas responde à pergunta que o produto, o FinOps e o CFO fazem: quanto custa rodar a aplicação X? Para responder, você precisa conhecer as dimensões de custo no EKS.
Este post abre a série "Otimização de custos com AWS EKS".
Essa é a diferença central do Kubernetes. A fatura da nuvem mostra infraestrutura, enquanto o Kubernetes organiza aplicações em cima dela. Ou seja, várias aplicações dividem os mesmos nós, a mesma rede e as mesmas ferramentas. Por isso, antes de otimizar qualquer coisa, você precisa saber de onde vem cada custo.
Neste post, vamos montar esse mapa. Você vai ver o que gera cobrança em cada dimensão e quais armadilhas aparecem com mais frequência. Também vai saber em qual post da série cada assunto é aprofundado.
O que torna o custo no Kubernetes diferente
Três características explicam por que o modelo "um servidor, uma aplicação, um centro de custo" não funciona mais:
- Recursos compartilhados. Um mesmo nó roda pods de vários times. A instância é uma linha na fatura, mas o uso é dividido entre muitos donos.
- Recursos efêmeros. Pods e nós nascem e morrem o tempo todo, por causa de deploys, autoscaling e consolidação. Assim, a capacidade que existia ontem às 15h pode não existir hoje.
- Reserva x uso. O scheduler reserva capacidade pelos requests de CPU e memória, e não pelo consumo real. Por exemplo, um container que pede 1 vCPU e usa 200 milicores ocupa 1 vCPU inteiro do nó. E você paga por ele.
Em resumo, custo no Kubernetes é, antes de tudo, um problema de alocação: dividir uma conta compartilhada entre as aplicações e os times que a consomem.
Control plane e data plane: onde está o dinheiro
Do ponto de vista de custo, um cluster EKS tem duas partes bem diferentes.
Control plane: pequeno, fixo, mas com uma armadilha
O control plane (API server, etcd, scheduler e controllers) é gerenciado pela AWS. Você paga uma taxa fixa por cluster e por hora, que depende da fase de suporte da versão do Kubernetes:
| Fase de suporte | Duração | Preço por cluster | Aproximadamente por mês (730 h) |
|---|---|---|---|
| Standard support | 14 meses a partir do lançamento da versão no EKS | US$ 0,10/h | ~US$ 73 |
| Extended support | 12 meses após o fim do standard support | US$ 0,60/h | ~US$ 438 |
A armadilha do extended support
Em clusters atualizados, o control plane costuma ser a menor parte da conta. A armadilha está no extended support: um cluster parado numa versão antiga passa a custar 6 vezes mais só no control plane. Numa frota com dezenas de clusters, essa diferença deixa de ser pequena. Portanto, manter os clusters atualizados também é uma prática de otimização de custo.
📌 Exemplo da própria AWS. Um cluster criado no dia do lançamento da versão e mantido 26 meses sem atualização paga, em média, US$ 0,33 por hora nesse período(14 meses a US$ 0,10/h + 12 meses a US$ 0,6/h). Se fosse atualizado no prazo, pagaria US$ 0,10/h nos 26 meses.
💰 Preços de referência: outubro de 2026. A AWS revisa preços de tempos em tempos, então os valores desta seção (tabela, diferença de 6 vezes e exemplo) podem ter mudado quando você ler este post. Antes de fazer as suas contas, confira os valores atuais na página de preços do AWS EKS .
Data plane: onde vive a maior parte do custo
O data plane é onde as aplicações rodam e onde o custo varia de verdade. Ele depende de quantos nós você tem, de quais nós (família, tamanho e arquitetura) e de como você paga por eles. Além disso, inclui tudo o que esses nós consomem: rede, armazenamento e observabilidade. Por isso, a maior parte desta série fala do data plane.
As dimensões de custo no EKS
Uma forma útil de organizar as dimensões de custo no EKS é pensar em camadas, partindo da aplicação até o custo operacional do time.
1. Workloads (aplicações)
É a camada que dá sentido a todas as outras: as aplicações em containers que você executa. Ela não aparece como linha na fatura, mas decide quanto você consome das outras camadas. Requests de CPU e memória, número de réplicas, comunicação entre serviços e volume de logs são decisões da aplicação. No fim, todas viram custo de infraestrutura.
- Armadilha comum: requests superdimensionados "por segurança", que reservam capacidade que nunca é usada.
- Para se aprofundar: mais adiante na série, você vai ver como medir o consumo real de cada aplicação e ajustar os requests, no post sobre rightsizing de pods no EKS, e como fazer o número de réplicas acompanhar a demanda, no post sobre autoscaling de pods no EKS.
2. Computação
Normalmente é a maior dimensão. Inclui os nós EC2 (managed node groups, nós autogerenciados ou provisionados pelo Karpenter), os pods no AWS Fargate e os nós do EKS Auto Mode.
O ponto central é que, no EC2, você paga pelo nó, e não pelo pod. Assim, a capacidade ociosa dentro de um nó é custo sem retorno. No Fargate, por outro lado, a cobrança é por pod, conforme a vCPU e a memória solicitadas. Já no Auto Mode existe uma taxa de gerenciamento por instância, além do preço do EC2.
Alavancas de economia na computação
As alavancas desta camada são:
- Densidade: colocar mais pods úteis em menos nós, com bin packing e consolidação.
- Elasticidade: ter só a capacidade necessária a cada momento.
- Tipo de instância: por exemplo, instâncias AWS Graviton.
- Modelo de compra: On-Demand, Savings Plans e Spot. Os Savings Plans dão até 72% de desconto em troca de compromisso de uso, e o Spot dá até 90% usando capacidade ociosa da AWS.
💰 Preços de referência: outubro de 2026. Os percentuais de desconto acima são os divulgados pela AWS nessa data e podem ter mudado. Confira os valores atuais na página de preços do AWS EC2 .
- Armadilha comum: nós grandes e pouco utilizados, criados para "caber tudo".
- Densidade sem perder resiliência: ao juntar pods em menos nós, não concentre todas as réplicas de uma aplicação no mesmo nó. Se um nó falhar, os pods dele caem juntos. Por padrão, o Kubernetes espera 5 minutos antes de recriá-los em outros nós, segundo a documentação sobre taints e tolerations . Se não houver espaço, eles ficam pendentes até o autoscaler criar um nó novo. Por isso, o EKS Best Practices Guide recomenda espalhar as réplicas entre nós e zonas de disponibilidade.
- Para se aprofundar: mais adiante na série, você vai ver como remover nós ociosos, no post sobre Karpenter no EKS, e como usar instâncias Arm, no post sobre Graviton no EKS. Também vai ver como combinar Spot, Savings Plans e On-Demand, no post sobre instâncias Spot no EKS, e quando deixar a operação dos nós com a AWS, nos posts sobre Fargate no EKS e EKS Auto Mode.
3. Redes e transferência de dados
Na minha experiência com clientes, é a dimensão que menos recebe atenção. Ela cresce junto com o número de microsserviços e quase nunca entra na estimativa inicial. A seguir, as principais fontes de custo.
Tráfego entre zonas de disponibilidade
Espalhar pods e nós por várias AZs é uma boa prática de alta disponibilidade. Porém, por padrão, o kube-proxy distribui o tráfego de um Service entre todos os pods, em qualquer AZ. Cada GB que cruza de uma AZ para outra é cobrado nas duas direções. São US$ 0,01/GB em cada sentido, ou US$ 0,02/GB por troca, no Norte da Virgínia e em São Paulo (outubro de 2026).
Para ter uma ideia da escala, veja um exemplo ilustrativo. Dois serviços que trocam 10.000 GB por mês entre AZs geram cerca de US$ 200 por mês só de transferência entre zonas. E isso vale para um único par de serviços.
💰 Preços de referência: outubro de 2026. O preço de transferência de dados entre AZs pode mudar e variar por região. Para refazer esta conta com os valores atuais da sua região, consulte a seção de transferência de dados na página de preços do AWS EC2 On-Demand .
Além disso, o tráfego entre AZs dos nós até o control plane também é cobrado, como avisa a página de preços do EKS. O volume costuma ser pequeno perto do tráfego entre serviços, mas aparece na mesma linha da fatura.
NAT gateway e load balancers
- NAT gateway. Pods em sub-redes privadas que acessam a internet ou serviços AWS sem endpoints da AWS VPC pagam pelo processamento de dados no NAT gateway.
- Load balancers. Cada Application Load Balancer ou Network Load Balancer do Elastic Load Balancing tem um custo por hora, mais as unidades de capacidade consumidas. Assim, criar um load balancer por Service ou por Ingress multiplica esse custo fixo e aumenta o número de recursos a gerenciar, como endpoints, certificados e regras de segurança.
- Pull de imagens e tráfego para a internet. O pull de imagens do AWS ECR na mesma região não é cobrado, mas, sem VPC endpoints, ele passa pelo NAT gateway e paga o processamento por GB. O mesmo vale para registries públicos e para o tráfego dos pods para a internet. Use VPC endpoints e o pull through cache do ECR para evitar esse custo.
IPv4 público
Todo IPv4 público é cobrado por hora, em uso ou ocioso: US$ 0,005 por endereço por hora, cerca de US$ 3,65 por mês (valor de outubro de 2026). Esses endereços aparecem em nós de sub-redes públicas, em NAT gateways e em load balancers públicos, que normalmente usam um endereço por AZ. Um ALB público em 3 AZs, por exemplo, soma cerca de US$ 11 por mês só de IPv4.
Para reduzir o custo de IPv4, mantenha os nós em sub-redes privadas e compartilhe load balancers entre Ingresses. Além disso, use o Public IP Insights do IP Address Manager da AWS VPC para achar endereços ociosos.
💰 Preços de referência: outubro de 2026. Os valores de IPv4 público podem mudar. Confira o preço atual na seção Public IPv4 Address da página de preços da AWS VPC e a lista do que é cobrado no cluster na página de preços do AWS EKS .
Como reduzir: preferir a mesma zona
O Kubernetes já oferece ferramentas para manter o tráfego dentro da mesma zona. Um exemplo é o campo
trafficDistribution do Service, GA desde o Kubernetes 1.33. A documentação do Kubernetes sobre Services e traffic distribution explica o comportamento em detalhes:1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: v1
kind: Service
metadata:
name: orders-service
spec:
selector:
app: orders
ports:
- port: 80
targetPort: 8080
# Prefere endpoints na mesma zona do cliente e só cruza a AZ se não houver nenhum.
# No Kubernetes 1.35, o valor foi renomeado para PreferSameZone (PreferClose continua aceito).
trafficDistribution: PreferClose
Há um trade-off, porém: concentrar o tráfego por zona pode sobrecarregar os pods de uma AZ. Por isso, combine esse recurso com topology spread constraints. Antes de mudar qualquer coisa, meça o tráfego com o Container Network Observability do EKS, que mostra o tráfego entre AZs e de NAT gateway por pod (a partir do Kubernetes 1.35).
- Armadilha comum: microsserviços muito "conversadores" espalhados em 3 AZs, sem nenhuma preferência de zona.
- Para se aprofundar: no próximo post da série, sobre visibilidade de custos no EKS, você vai ver como separar o custo de cada cluster e de cada aplicação. Já o checklist de otimização de custos no EKS, que encerra a série, retoma a verificação do tráfego entre AZs, do NAT gateway e dos IPv4 públicos.
4. Armazenamento
Volumes EBS usados por PersistentVolumes são cobrados pelo que é provisionado, e não pelo que é usado. A cobrança vale até o volume ser apagado, e os snapshots têm cobrança própria.
- Armadilha comum: PersistentVolumeClaims órfãos de ambientes temporários e volumes superdimensionados, que continuam gerando custo depois que a aplicação saiu do ar. Outra é usar um tipo de volume mais caro do que o workload precisa.
- Para se aprofundar: no post sobre visibilidade de custos no EKS, você vai ver como usar as mesmas chaves nas labels dos pods e nas tags dos recursos AWS, para somar ao custo de cada aplicação os recursos que ela usa. Já o checklist de otimização de custos no EKS, que encerra a série, inclui a busca por volumes EBS órfãos.
5. Plataforma
Aqui entram o próprio EKS (o control plane que vimos acima) e o AWS ECR . O ECR cobra pelo armazenamento das imagens e pela transferência de dados para fora. Sem lifecycle policies, um repositório de CI/CD acumula milhares de imagens antigas, e cada uma continua custando.
- Armadilha comum: clusters esquecidos em versões em extended support e repositórios ECR sem política de limpeza.
6. Ferramentas de DevOps e segurança
Pipelines de CI/CD, scanners de imagem, agentes de segurança, service mesh e controllers adicionais rodam dentro do cluster ou ao lado dele. Dentro do cluster, eles rodam como DaemonSets e Deployments e, portanto, consomem CPU e memória de todos os nós.
- Armadilha comum: vários DaemonSets "pequenos" que, somados e multiplicados pelo número de nós, ocupam uma fatia relevante de cada instância.
7. Observabilidade
Logs, métricas e traces são essenciais. No entanto, são cobrados pelo volume ingerido, armazenado e consultado. Num cluster dinâmico, esse volume cresce com o número de pods, réplicas e nós, e os logs são, de longe, o vilão mais comum.
Coletar tudo, no detalhe máximo e com retenção longa, pode fazer a observabilidade custar uma fração considerável do cluster. Ferramentas como o CloudWatch Container Insights permitem escolher quais métricas coletar. Dessa forma, você equilibra visibilidade e custo.
- Armadilha comum: logs de debug em produção, retenção "para sempre" e métricas com alta cardinalidade que ninguém consulta.
8. Custos operacionais
É a dimensão que não aparece na fatura da AWS, mas aparece na folha de pagamento. São as horas de engenharia gastas para operar a plataforma: atualizar versões, aplicar patches nas AMIs, ajustar node groups, responder a incidentes de capacidade e manter as ferramentas do cluster.
Automatizar reduz esse custo. Opções gerenciadas, como Fargate e EKS Auto Mode, transferem parte da operação para a AWS em troca de um preço diferente na computação. Em outras palavras, comparar só o preço por hora, sem considerar o OPEX, leva a decisões erradas.
- Para se aprofundar: mais adiante na série, você vai ver como comparar o custo total, somando computação e operação, no post sobre Fargate no EKS. No post sobre EKS Auto Mode, você vai ver quando vale deixar a operação dos nós com a AWS em vez de operar o Karpenter por conta própria.
Granularidade: a quem atribuir o custo
Conhecer as dimensões é o primeiro passo. O segundo é decidir em que nível você quer enxergar e distribuir o custo:
| Nível | O que representa | Para que serve |
|---|---|---|
| Cluster | Custo total (control plane + data plane + recursos associados) | Visão executiva e comparação entre ambientes |
| Namespace | Normalmente um time, um produto ou um tenant | O nível mais útil para showback e chargeback |
| Deployment / Service | Uma aplicação ou um microsserviço | Decisões de arquitetura e de rightsizing por aplicação |
| Pod / Container | O nível mais granular | Investigação detalhada, como descobrir qual container está superdimensionado |
Depois de mapear as dimensões de custo no EKS, o namespace costuma ser o melhor ponto de partida, porque é a fronteira natural de multi-tenancy na maioria das empresas. Em seguida, as labels dos pods (
team, app, cost-center) permitem ir além do namespace.Custo compartilhado
Parte do custo, no entanto, é compartilhada e não pertence a nenhuma aplicação específica. É o caso do control plane, dos DaemonSets de logging e monitoramento, dos controllers do cluster e da capacidade ociosa dos nós. Dividir esse custo de forma proporcional, igual ou absorvê-lo no time de plataforma é uma decisão de negócio, e ela precisa ser explícita.
Para se aprofundar no tema, a FinOps Foundation tem um guia sobre como calcular e alocar custos de containers . Ele combina dados de billing com métricas do Kubernetes.
Por onde começar
Com as dimensões de custo no EKS mapeadas, faça três perguntas sobre o seu ambiente antes de mudar qualquer configuração:
- Quanto custa cada cluster, e quanto disso é control plane, computação, rede, armazenamento e observabilidade? Se você não sabe, comece pela visibilidade.
- Algum cluster está em extended support? É a economia mais simples, porque atualizar a versão reduz o custo do control plane em 6 vezes.
- Qual é a distância entre o que os pods pedem (requests) e o que eles usam? Geralmente, é ali que está a maior oportunidade de computação.
💰 Preços de referência: outubro de 2026. A diferença de 6 vezes compara os preços do standard e do extended support nessa data. Confira os valores atuais na página de preços do AWS EKS .
Checklist
- Liste os clusters e as versões do Kubernetes; identifique os que estão (ou vão entrar) em extended support
- Separe o custo de cada cluster por dimensão: computação, rede, armazenamento, plataforma e observabilidade
- Defina o nível de atribuição de custo (recomendação: namespace + labels de time e aplicação)
- Decida como tratar o custo compartilhado (control plane, DaemonSets, capacidade ociosa)
- Verifique o tráfego entre AZs e o processamento de NAT gateway dos serviços mais "conversadores"
- Procure IPv4 públicos ociosos (Public IP Insights) e nós em sub-redes públicas sem necessidade
- Procure volumes EBS órfãos e repositórios ECR sem lifecycle policy
- Revise retenção e nível de log em produção
Perguntas frequentes
Quanto custa um cluster AWS EKS por mês?
O control plane custa US$ 0,10 por hora em standard support (cerca de US$ 73 por mês) e US$ 0,60 por hora em extended support (cerca de US$ 438), em valores de outubro de 2026. Além disso, você paga pelos recursos do data plane: nós, volumes, rede e observabilidade. Confira os valores atuais na página de preços do AWS EKS .
O que é o extended support do EKS?
É um período de 12 meses que começa depois dos 14 meses de standard support de cada versão do Kubernetes. Nesse período, a versão continua recebendo patches de segurança, mas o control plane passa a custar 6 vezes mais.
💰 Preços de referência: outubro de 2026. Os valores destas respostas podem ter mudado. Confira os preços atuais na página de preços do AWS EKS .
O EKS cobra por pod ou por nó?
Depende da opção de computação. Com nós EC2, você paga pela instância inteira, mesmo que os pods usem só uma parte dela. Com o Fargate, por outro lado, a cobrança é por pod, conforme a vCPU e a memória solicitadas.
Por que o tráfego entre AZs aumenta a fatura do EKS?
Porque, por padrão, o kube-proxy envia o tráfego para pods em qualquer AZ, e cada GB que cruza zonas é cobrado nas duas direções. Recursos como o
trafficDistribution ajudam a manter o tráfego na mesma zona.Como dividir o custo de um cluster EKS entre times?
Comece pelo namespace e refine com labels de time e de aplicação. Depois, defina uma regra clara para o custo compartilhado, como o control plane e a capacidade ociosa. As ferramentas para isso são o tema do próximo post.
Próximo post
Se você não consegue medir, não consegue gerenciar. No próximo post, vamos sair da teoria e montar a visibilidade de custos no EKS na prática, com cost allocation tags, CUR 2.0, Split Cost Allocation Data com labels do Kubernetes e Kubecost.
Series: Otimização de custos com AWS EKS (5 articles)
- 1Dimensões de custo no EKS: por que o Kubernetes é diferente This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article