O que é o modelo de preços do Amazon EKS?
O Amazon EKS cobra uma taxa fixa de US$ 0,10 por hora pelo control plane de cada cluster (aproximadamente US$ 72/mês). Além disso, você paga pelos recursos subjacentes da AWS (instâncias EC2, Fargate, volumes EBS, load balancers) usados para executar seus worker nodes e sua aplicação. O suporte estendido para versões mais antigas do Kubernetes custa US$ 0,60 por hora.
Entender o modelo de preços do EKS é fundamental para que as organizações estimem seus gastos com nuvem com precisão e evitem custos inesperados. A AWS oferece vários modos operacionais para o EKS, cada um com sua própria estrutura de custos. É preciso avaliar as implicações de preço ao usar clusters padrão, managed node groups, opções de auto scaling e add-ons opcionais. Analisar esses componentes desde o início garante um planejamento orçamentário eficaz e possibilita a otimização de custos.
Este artigo faz parte de uma série sobre preços do Kubernetes.
Neste artigo:
- Entendendo os componentes de preço do AWS EKS
- Custos ocultos e adicionais do Amazon EKS
- Exemplos de preços do Amazon EKS
- 6 formas de reduzir e otimizar os custos do Amazon EKS
Entendendo os componentes de preço do AWS EKS
Vamos analisar os principais componentes de custo dos clusters Amazon EKS.
Preço do cluster Amazon EKS
O Amazon EKS cobra uma taxa horária por cluster para cada cluster EKS. O preço depende do nível de suporte da versão do Kubernetes usada pelo cluster:
- Clusters executando uma versão do Kubernetes com suporte padrão custam US$ 0,10 por cluster por hora.
- Uma versão do Kubernetes permanece em suporte padrão pelos primeiros 14 meses após seu lançamento no Amazon EKS.
- Após o fim do suporte padrão, a versão entra em suporte estendido pelos 12 meses seguintes.
- O suporte estendido custa US$ 0,60 por cluster por hora. Isso inclui a taxa horária padrão de US$ 0,10 mais US$ 0,50 adicionais por cluster por hora.
Esse preço se aplica ao cluster EKS em si. Os usuários continuam pagando separadamente pelos recursos da AWS usados pelos seus workloads, como instâncias EC2, volumes EBS, endereços IPv4 públicos ou computação Fargate.
Preço do Amazon EKS Provisioned Control Plane
O Amazon EKS Provisioned Control Plane permite reservar uma quantidade definida de capacidade de control plane para um cluster. Essa opção é indicada para workloads que precisam de desempenho estável do control plane, resposta mais rápida a picos de tráfego ou suporte a operações Kubernetes em maior escala.
O preço é baseado no tier de escala de control plane selecionado. A cobrança é por hora e se soma à taxa padrão do cluster EKS. Não há taxas antecipadas nem compromissos de longo prazo:
- O tier XL custa US$ 1,65 por cluster por hora.
- O tier 2XL custa US$ 3,40 por cluster por hora.
- O tier 4XL custa US$ 6,90 por cluster por hora.
- O tier 8XL custa US$ 13,90 por cluster por hora.
Os usuários podem alternar entre os tiers de escala ou voltar ao control plane padrão. Para tiers maiores que 8XL, a AWS exige que os usuários entrem em contato com sua equipe de conta para obter preços.
Amazon EKS Auto Mode
O preço do Amazon EKS Auto Mode se aplica a clusters com o EKS Auto Mode habilitado. A cobrança é baseada no tipo e na duração das instâncias Amazon EC2 que o EKS Auto Mode inicia e gerencia. Essa taxa é separada do preço da instância EC2. Você paga o custo normal do EC2 pelas instâncias subjacentes, enquanto o EKS Auto Mode adiciona sua própria taxa de gerenciamento.
O EKS Auto Mode é cobrado por segundo, com um mínimo de um minuto. A cobrança independe da opção de compra do EC2, ou seja, aplica-se tanto a instâncias com preço On-Demand quanto a Reserved Instances, Compute Savings Plans ou Spot Instances. Organizações que planejam usar o EKS Auto Mode com mais de 150 nós devem entrar em contato com sua equipe de conta da AWS para obter informações de preço.
Preço do Amazon EKS Capabilities
O preço do Amazon EKS Capabilities se aplica quando capacidades específicas são habilitadas em um cluster EKS. O preço tem duas partes horárias: uma cobrança base para cada capacidade habilitada e uma cobrança de uso baseada no número de recursos gerenciados por essa capacidade:
- Para o Argo CD em US East (Ohio), a cobrança base é de US$ 0,02771 por hora de capacidade do Argo CD. A cobrança de uso é de US$ 0,00136 por hora de aplicação do Argo CD. Cada aplicação é contada por implantação em cluster de destino, então uma aplicação implantada em cinco clusters conta como cinco aplicações.
- Para o AWS Controllers for Kubernetes (ACK), a cobrança base é de US$ 0,004482 por hora de capacidade do ACK. A cobrança de uso é de US$ 0,000045 por hora de recurso do ACK.
- Para o Kubernetes Resource Orchestrator (KRO), a cobrança base é de US$ 0,004482 por hora de capacidade do KRO. A cobrança de uso é de US$ 0,000045 por hora de instância RGD do KRO.
- Todas as cobranças de EKS Capabilities são faturadas por hora. Não há taxas antecipadas nem compromissos mínimos.
Preço do Amazon EKS Hybrid Nodes
O Amazon EKS Hybrid Nodes permite conectar infraestrutura on-premises ou de edge a clusters Amazon EKS. Isso possibilita que workloads Kubernetes usem infraestrutura fora da AWS, mantendo o gerenciamento do cluster no Amazon EKS.
O preço é baseado em vCPU-horas reportadas ao Kubernetes:
- O faturamento começa quando um nó híbrido entra no cluster e termina quando o nó é removido.
- Em ambientes bare metal com hyperthreading habilitado, cada núcleo físico de CPU reporta duas vCPUs ao Kubernetes, e o faturamento usa a contagem de vCPUs reportada.
O preço do Hybrid Nodes é escalonado pelo uso mensal agregado de vCPU-horas na mesma Região da AWS:
- As primeiras 576.000 vCPU-horas mensais custam US$ 0,020 por vCPU-hora.
- As próximas 576.000 custam US$ 0,014 por vCPU-hora.
- As próximas 4.608.000 vCPU-horas mensais custam US$ 0,010 por vCPU-hora.
- As próximas 5.760.000 custam US$ 0,008 por vCPU-hora.
- O uso acima de 11.520.000 vCPU-horas mensais custa US$ 0,006 por vCPU-hora.
Se o faturamento consolidado for usado por meio do AWS Organizations, esses tiers se aplicam a todas as contas da organização na mesma Região. Usuários que planejam executar nós híbridos em máquinas com mais de 32 vCPUs por máquina devem entrar em contato com sua equipe de conta da AWS.
Preço do EKS Anywhere
O Amazon EKS Anywhere é um software de código aberto que executa clusters Kubernetes em hardware em um data center ou ambiente de edge. O software em si está disponível como código aberto, mas a AWS vende Enterprise Subscriptions para suporte e capacidades adicionais:
- Uma Amazon EKS Anywhere Enterprise Subscription oferece suporte para clusters EKS Anywhere licenciados. Ela também dá acesso aos EKS Anywhere Curated Packages, que adicionam funções como balanceamento de carga, observabilidade e auto scaling.
- É necessário ter AWS Enterprise Support ou AWS Enterprise On-Ramp Support antes de adquirir uma EKS Anywhere Enterprise Subscription.
- As assinaturas podem ser adquiridas pelo console do Amazon EKS, pela API ou pela AWS CLI.
- O preço é fixo por cluster e não depende do tamanho do cluster. Um contrato de um ano custa US$ 24.000 por cluster, cobrado a US$ 2.000 por mês. Um contrato de três anos custa US$ 18.000 por cluster por ano, cobrado a US$ 1.500 por mês.
- É possível incluir uma ou mais licenças de cluster EKS Anywhere em uma única compra de assinatura.
- As assinaturas podem ser configuradas para renovação automática e podem ser canceladas nos primeiros sete dias sem custo.
Custos ocultos e adicionais do Amazon EKS
Além dos componentes básicos principais, há custos adicionais que você talvez não conheça e que também estão relacionados aos seus clusters EKS.
Custos de armazenamento
Executar workloads no Amazon EKS geralmente exige armazenamento persistente, o que gera custos adicionais. Esses custos normalmente vêm do uso de volumes Amazon EBS, Amazon EFS (Elastic File System) ou buckets S3 para armazenamento de objetos. O preço desses serviços de armazenamento é baseado na quantidade de armazenamento provisionada, no tipo de armazenamento (por exemplo, SSD vs. HDD) e nos requisitos de IOPS. Se os workloads exigirem armazenamento de alto desempenho ou grandes capacidades, os custos de armazenamento podem ultrapassar a taxa base do cluster EKS.
Os custos de armazenamento também incluem cobranças de backup, snapshots e transferência de dados. Por exemplo, criar snapshots regulares de EBS para recuperação de desastres ou conformidade pode gerar cobranças mensais adicionais. As organizações devem monitorar o uso de armazenamento, excluir volumes não utilizados e fazer right-sizing das classes de armazenamento para evitar gastos desnecessários. Entender o escopo completo dos custos de armazenamento ajuda a evitar estouros de orçamento em ambientes EKS.
Custos de transferência de dados
Os custos de transferência de dados no Amazon EKS costumam passar despercebidos, mas podem impactar sua fatura geral da AWS. A AWS cobra pelos dados transferidos dos clusters EKS para a internet, entre Zonas de Disponibilidade e, em alguns casos, entre serviços da AWS em Regiões diferentes. Para aplicações com alto tráfego de saída ou comunicação entre zonas, essas taxas podem se acumular e se tornar uma parcela significativa dos custos totais.
Projete seus workloads no EKS de forma a minimizar transferências de dados desnecessárias. Por exemplo, mantenha o tráfego dentro da mesma Zona de Disponibilidade sempre que possível, ou use o AWS PrivateLink para a comunicação entre serviços a fim de reduzir custos. Revise regularmente os padrões de transferência de dados e ajuste a topologia de rede para controlar essas despesas nas implantações do EKS.
Custos de NAT Gateway
Clusters Amazon EKS que precisam de acesso à internet a partir de sub-redes privadas normalmente usam NAT Gateways. A AWS cobra tanto pelo uso horário de cada NAT Gateway quanto pela quantidade de dados processados por eles. Em ambientes de alto tráfego ou em clusters com várias sub-redes privadas, as cobranças de NAT Gateway podem crescer rapidamente.
Para reduzir os custos de NAT Gateway, considere consolidar o tráfego em menos gateways ou usar instâncias NAT para requisitos de menor throughput. Monitore o uso dos NAT Gateways e revise a arquitetura de rede para identificar oportunidades de economia. Como as cobranças de NAT Gateway não estão incluídas no preço do control plane nem dos nós do EKS, inclua-as nos cálculos de custo total de propriedade do EKS.
Logs e monitoramento com CloudWatch
O Amazon CloudWatch é comumente usado para logs e monitoramento de clusters EKS, mas seus custos são separados do preço do EKS. As cobranças do CloudWatch são baseadas no volume de logs ingeridos, nas métricas armazenadas e nos dashboards criados. Logging de alta frequência, logs de aplicação verbosos ou métricas personalizadas em grande quantidade podem aumentar os custos, especialmente em ambientes EKS grandes ou dinâmicos.
As organizações devem implementar políticas de retenção de logs, filtrar logs desnecessários e agregar métricas para controlar as despesas com o CloudWatch. Usar amostragem de logs ou soluções de logging de terceiros também pode reduzir custos. Revise regularmente o uso do CloudWatch e otimize a coleta de logs e métricas para evitar cobranças inesperadas, mantendo observabilidade suficiente para os workloads no EKS.
Exemplos de preços do Amazon EKS
Exemplo 1: preço de cluster EKS com suporte padrão e estendido
Um cluster EKS executa a mesma versão do Kubernetes por 26 meses sem atualização do control plane. Nos primeiros 14 meses, a versão está em suporte padrão, custando US$ 0,10 por cluster por hora. Depois disso, entra em suporte estendido por 12 meses a US$ 0,60 por cluster por hora.
Para visualizar a diferença de custo de forma concreta: durante os 14 meses de suporte padrão, o cluster custa aproximadamente US$ 1.022 no total em taxas de cluster (14 × 730 horas × US$ 0,10). Durante os 12 meses de suporte estendido, esse valor sobe para US$ 5.256 (12 × 730 horas × US$ 0,60) — mais de cinco vezes o custo, com dois meses a menos. Na média do período completo de 26 meses, a taxa efetiva é de US$ 0,33 por cluster por hora.
Exemplo 2: preço do EKS Hybrid Nodes para várias unidades de negócio
Três unidades de negócio usam o EKS Hybrid Nodes, cada uma em um cluster EKS dedicado com suporte padrão de versão do Kubernetes, o que gera para cada uma um custo mensal de cluster de US$ 73 (730 horas × US$ 0,10).
A Unidade de Negócio 1 executa 8 nós com 8 vCPUs cada, gerando 46.720 vCPU-horas e uma cobrança de nós de US$ 934,40. A Unidade de Negócio 2 executa 4 nós com 16 vCPUs cada, gerando 46.720 vCPU-horas e uma cobrança de nós de US$ 934,40. A Unidade de Negócio 3 executa 6 nós com 4 vCPUs cada, gerando 17.520 vCPU-horas e uma cobrança de nós de US$ 350,40.
Juntas, as três unidades consomem 110.960 vCPU-horas no mês. Como isso está bem abaixo do teto do primeiro tier, de 576.000 vCPU-horas mensais, todo o uso é cobrado a US$ 0,02 por vCPU-hora. A fatura mensal total do EKS é de US$ 2.438,20, composta por US$ 219 em cobranças de cluster e US$ 2.219,20 em cobranças de nós.
Exemplo 3: exemplo de preço do Amazon EKS Auto Mode
Uma aplicação em contêineres roda no Amazon EKS Auto Mode na Região US West (Oregon). A aplicação tem pods de frontend, pods de backend e pods de processamento em lote. O EKS Auto Mode seleciona um mix de instâncias EC2 para atender aos requisitos desses workloads.
As instâncias selecionadas são c6a.2xlarge, c6a.4xlarge, m5a.2xlarge e m5a.xlarge. O custo combinado de EC2 é de US$ 1,434 por hora. O EKS Auto Mode adiciona uma taxa de gerenciamento separada de US$ 0,17208 por hora para essas instâncias.
Ao longo de um mês, isso equivale a US$ 1.046,82 em custos de instâncias EC2 e US$ 125,62 em taxas do EKS Auto Mode. Este exemplo mostra que o preço do EKS Auto Mode é adicionado ao custo subjacente do EC2, e não o substitui.
6 formas de reduzir e otimizar os custos do Amazon EKS
1. Faça right-sizing dos worker nodes e dos requests de pods
Worker nodes superprovisionados e requests de recursos de pods inflados são fontes comuns de desperdício de gastos no EKS. O Kubernetes agenda pods com base na CPU e memória solicitadas, não no uso real. Se os requests forem definidos muito altos, os clusters podem escalar horizontalmente sem necessidade, deixando grandes parcelas da capacidade dos nós sem uso, mas ainda gerando custos de EC2.
As equipes devem analisar regularmente o consumo real de recursos e ajustar requests e limits de acordo. Ferramentas como o metrics server do Kubernetes, Prometheus, Vertical Pod Autoscaler (VPA), KEDA e Goldilocks podem ajudar a identificar alocações ineficientes. Usar tipos de instância menores, grupos de instâncias mistas ou instâncias baseadas em Graviton também pode melhorar a eficiência de custos.
O autoscaling do cluster deve ser configurado para remover automaticamente nós não utilizados. Combinar o dimensionamento preciso dos pods com o autoscaling reduz a infraestrutura ociosa e mantém uma melhor densidade de workloads no cluster.
2. Use Spot Instances para workloads tolerantes a falhas
As Amazon EC2 Spot Instances podem reduzir os custos de computação do EKS porque usam capacidade ociosa da AWS a preços com desconto. O preço Spot costuma ser de 70 a 90% menor que o preço On-Demand padrão, tornando-o adequado para workloads que toleram interrupções.
Aplicações stateless, jobs em lote, pipelines de CI/CD, workers em segundo plano e tarefas de processamento de dados são fortes candidatos ao uso de Spot. Os node groups do Kubernetes podem misturar instâncias Spot e On-Demand, de modo que workloads críticos permaneçam estáveis enquanto workloads tolerantes a falhas usam capacidade de menor custo.
Para melhorar a confiabilidade, use vários tipos de instância e Zonas de Disponibilidade nos node groups Spot. Recursos do Kubernetes como Pod Disruption Budgets e Cluster Autoscaler ajudam os workloads a se recuperar automaticamente quando ocorrem interrupções de Spot.
3. Otimize load balancers e ingress
Cada serviço Kubernetes do tipo LoadBalancer no EKS normalmente provisiona um load balancer da AWS dedicado. Em ambientes grandes, load balancers desnecessários ou duplicados podem gerar custos mensais substanciais, especialmente ao usar Application Load Balancers ou Network Load Balancers.
Usar um ingress controller centralizado permite que várias aplicações compartilhem um único load balancer em vez de provisionar um por serviço. O AWS Load Balancer Controller suporta o roteamento de várias aplicações por meio de load balancers compartilhados, usando regras de roteamento baseadas em host ou em caminho.
Remova load balancers não utilizados e revise regularmente os recursos de ingress ociosos. Serviços apenas internos devem evitar load balancers voltados para a internet, a menos que o acesso externo seja necessário. Otimizar a arquitetura de ingress reduz tanto as cobranças de load balancer quanto os custos de transferência de dados relacionados.
4. Identifique recursos ociosos e subutilizados
Recursos Kubernetes não utilizados costumam continuar gerando cobranças na AWS mesmo quando as aplicações não estão mais ativas. Nós EC2 ociosos, volumes EBS desanexados, load balancers órfãos, Elastic IPs não utilizados e namespaces inativos são exemplos comuns de desperdício em ambientes EKS.
Revisões regulares de custo e utilização ajudam a identificar recursos que podem ser excluídos ou consolidados. O AWS Cost Explorer, o AWS Compute Optimizer, o Kubecost e ferramentas de monitoramento do Kubernetes podem rastrear o uso ineficiente de recursos nos clusters.
Automatizar processos de limpeza melhora o controle de custos. As organizações podem usar políticas de ciclo de vida, desligamentos programados para ambientes de não produção e regras de expiração de namespaces para reduzir gastos desnecessários. O monitoramento contínuo é importante porque os ambientes Kubernetes mudam com frequência à medida que os workloads escalam e as equipes implantam novos serviços.
5. Atualize as versões do Kubernetes antes do suporte estendido
O Amazon EKS aumenta o preço do cluster quando uma versão do Kubernetes passa do suporte padrão para o suporte estendido. A taxa horária do cluster sobe de US$ 0,10 para US$ 0,60 por hora de cluster, o que pode elevar os custos em vários clusters.
Atualizações regulares do Kubernetes ajudam as organizações a evitar essas cobranças adicionais, além de melhorar a segurança, a estabilidade e a disponibilidade de recursos. Estabelecer um cronograma de atualização previsível reduz o risco de clusters permanecerem em versões sem suporte por longos períodos.
Teste as atualizações em ambientes de staging antes do rollout em produção para reduzir o risco operacional. As equipes também devem acompanhar o calendário de lançamentos do Amazon EKS e planejar as atualizações com antecedência suficiente para evitar migrações apressadas perto dos prazos de fim de suporte.
6. Use o Karpenter para um provisionamento de nós mais inteligente
O Karpenter pode ajudar a reduzir os custos do Amazon EKS ao provisionar capacidade de computação com base nos requisitos reais dos pods, em vez de depender apenas de node groups predefinidos. Ele avalia os pods pendentes e inicia instâncias EC2 dimensionadas corretamente para as necessidades dos workloads, o que pode melhorar o bin packing, reduzir a capacidade ociosa e acelerar o escalonamento.
Diferentemente das configurações tradicionais do Cluster Autoscaler, que dependem fortemente de Auto Scaling Groups, o Karpenter pode escolher entre uma gama mais ampla de tipos de instância, tamanhos, Zonas de Disponibilidade, arquiteturas e tipos de capacidade. Essa flexibilidade permite que as equipes usem um mix mais diversificado de instâncias On-Demand, Spot e baseadas em Graviton, mantendo a disponibilidade das aplicações.
O Karpenter é especialmente útil para workloads dinâmicos ou variáveis, porque pode adicionar capacidade rapidamente quando os pods não conseguem ser agendados e consolidar nós subutilizados quando a demanda cai. As equipes devem configurar NodePools com requisitos de instância apropriados, controles de disrupção, políticas de consolidação e restrições de workload para equilibrar economia de custos e confiabilidade.
Otimizando os custos do EKS com o PerfectScale
O EKS oferece uma plataforma poderosa para executar workloads em contêineres, mas o modelo de preços faz com que configurações ineficientes de recursos se traduzam diretamente em faturas mais altas. Requests superprovisionados de CPU e memória fazem os clusters escalarem mais do que o necessário, mantendo nós EC2 em execução com baixa utilização enquanto os custos se acumulam. O PerfectScale, da DoiT, elimina esse desperdício analisando continuamente o consumo real dos workloads nos seus clusters EKS e fazendo, de forma autônoma, o right-sizing dos requests e limits de CPU e memória — sem exigir ajustes manuais nem tempo da equipe de engenharia.
Ao contrário de ferramentas que apenas geram recomendações — sugestões que as equipes raramente têm capacidade de colocar em prática —, o PerfectScale aplica as otimizações automaticamente, mantendo guardrails para proteger o desempenho e a disponibilidade. Ele detecta e corrige riscos de resiliência como OOM kills, throttling de CPU e evicção de pods em tempo real, de modo que a economia de custos não venha às custas da estabilidade. O resultado é um cluster mais enxuto e mais bem utilizado, que gasta menos com capacidade EC2 desnecessária, mantendo a confiabilidade que seus workloads exigem.
Saiba como o PerfectScale reduz os custos do EKS de forma autônoma