EKS Cost Optimization: 12 Ways to Cut Amazon EKS Spend

Amazon EKS has a famous price and a hidden one. The famous price is $0.10 an hour for the control plane, about $73 a month, which is the number every comparison quotes and the smallest number on the bill. The hidden one is everything underneath: the EC2 nodes the pods run on, the EBS volumes behind every persistent claim, the load balancers and NAT Gateways and public addresses the cluster needs to talk to anything, and a six-fold control-plane penalty that switches on by calendar when a Kubernetes version ages out of support. None of it is labeled EKS on the invoice, and none of it is attributed to the namespaces that consumed it.

This guide covers how EKS pricing really works in 2026, including the extended-support trap and Auto Mode's management fee, why cost is a black box per namespace, and twelve levers that cut EKS spend, ordered by impact and with worked US figures. It applies the general practice in our Kubernetes cost optimization guide to the specific economics of EKS. Rates are from the official EKS pricing page and vary by region.

Key Takeaways

• EKS bills $73 a month per cluster for the control plane and far more for everything underneath, none of it attributed to namespaces on the invoice.
• The extended-support penalty, $0.60 an hour instead of $0.10, switches on automatically 14 months after a Kubernetes version's release; version 1.33 crossed on July 29, 2026.
• Over-provisioned pod requests are the largest source of EKS waste, because requests reserve node capacity whether or not it is used.
• Karpenter, Spot, and Graviton together commonly cut node cost by half; EKS Auto Mode bundles Karpenter for a management fee of about 12 percent on EC2.
• Allocation per namespace is the lever that makes the other eleven stick, because waste with no owner is waste nobody removes.

How EKS Pricing Really Works

EKS has two kinds of cost: what EKS charges directly, and what the cluster consumes from other AWS services. The first is small and fixed; the second is large, variable, and spread across the bill.

Two lines deserve emphasis. Extended support is a calendar event, not a decision: a cluster that was $73 a month on a Monday is $438 on the Tuesday its version ages out, and several guides in 2026 flag it as the most common EKS surprise, especially for infrastructure-as-code clusters whose defaults allow extended support rather than forcing an upgrade. And the networking lines, which we cover in our guides to Elastic IP charges and the hidden cloud costs around Kubernetes, are where a cluster that looks cheap on compute quietly is not.

Why EKS Cost Is a Black Box per Namespace

AWS bills what it provisions: nodes, volumes, gateways. The scheduler's decision to place a payment service's pods and a batch job's pods on the same m6i.xlarge happens inside Kubernetes and is never sent to billing. So the invoice can say what the node cost and cannot say which namespace consumed it, and the finance question that every platform team eventually gets, what does the data team's namespace cost, has no answer in any AWS console. Answering it requires joining billing data to per-pod resource usage over time, allocating each node's cost by the share of it each pod reserved or used, and deciding explicitly how idle capacity and system pods are split. That is the method in our guides to container cost visibility and allocating Kubernetes costs, and it is the precondition for most of the levers below, because a namespace with no cost has no owner and no incentive.

Twelve Ways to Cut EKS Spend

1. Right-size pod requests to measured usage

Requests reserve node capacity whether or not the pod uses it, and the autoscaler adds nodes to satisfy requests, not usage. Most clusters run requests two to four times actual consumption. Measure p95 and p99 usage per container over several weeks, set requests with headroom above the p99, and use the Vertical Pod Autoscaler in recommendation mode to keep them honest. This is the largest single lever and the one most often skipped.

2. Stay inside standard support

Upgrade Kubernetes versions on a cadence that never lets a cluster reach month 15. A quarterly upgrade schedule eliminates the $365-a-month-per-cluster penalty entirely; on twenty clusters that is $87,600 a year for doing upgrades you should be doing anyway.

3. Replace Cluster Autoscaler with Karpenter

Karpenter reads pending pods and launches exactly the nodes they need from the full EC2 catalog, including Spot and Graviton, in seconds, and consolidates workloads onto fewer nodes as demand falls. Cluster Autoscaler's fixed node groups do none of that. Teams moving to Karpenter commonly see node cost fall 20 to 30 percent from consolidation and instance selection alone.

4. Or use EKS Auto Mode, with eyes open

Auto Mode bundles Karpenter, the EBS CSI driver, the load balancer controller, and managed node lifecycle for a fee of about 12 percent on top of the EC2 price. For a team without the capacity to operate Karpenter it is worth it; for one that already runs it well, it is 12 percent for convenience. Decide per cluster.

5. Run interruptible workloads on Spot

Stateless services behind a load balancer, batch and CI workloads, and dev and test namespaces tolerate two-minute interruptions, and Spot cuts their node cost by 60 to 70 percent in practice. Karpenter diversifies across pools and handles replacement automatically; keep a floor of on-demand or committed nodes for what cannot be interrupted. Our comparison of On-Demand, Spot, Reserved, and Savings Plans covers the portfolio.

6. Move to Graviton

ARM-based Graviton instances cost about 20 percent less than their Intel equivalents for comparable performance, and most container images already have ARM builds. Let Karpenter prefer m7g and c7g families and watch the per-pod cost fall.

7. Consolidate and remove idle clusters

Each cluster costs $73 a month before it runs anything, plus its own system pods, NAT, and load balancers. Development clusters per team, proof-of-concept clusters nobody deleted, and per-environment clusters that could be namespaces all pay that overhead. Audit for clusters with no recent deployments; consolidate where isolation requirements allow.

8. Cover the steady baseline with Savings Plans

Once requests are right-sized and the fleet has settled, commit the always-on node baseline to a Compute Savings Plan for up to about 66 percent off. Commit after optimization, not before, or the plan locks in the oversized fleet.

9. Keep traffic in-zone and use VPC endpoints

Multi-AZ pods talking to a database or each other across zones pay $0.02 per GB round trip; enable topology-aware routing so services prefer same-zone endpoints. Replace NAT Gateway paths to S3, ECR, and other AWS APIs with VPC endpoints, which removes $0.045 per GB on image pulls and data access that most clusters never notice.

10. Drop unneeded public IPs and load balancers

A Service of type LoadBalancer per microservice creates an ALB with two or three public IPv4 addresses each, about $27 a month before traffic. Consolidate behind one ingress controller, and remove public IPs from nodes that sit behind it.

11. Tier and clean EBS

Persistent volumes bill on provisioned size and persist after the pods that used them are gone. Set the StorageClass to gp3, size claims to what is used, and reclaim orphaned volumes on a schedule.

12. Schedule non-production down and allocate everything

Scale development and test namespaces to zero outside working hours; a cluster running eight hours on weekdays costs a quarter of one running all month. Then allocate the whole cluster, nodes, idle capacity, system overhead, and the networking around it, to namespaces and teams, because the eleven levers above are only applied by teams that can see what their namespace costs. Our guide to finding and eliminating idle Kubernetes resources covers the cleanup; allocation is what makes it recur.

A Worked Example

A company runs a production EKS cluster of 30 m6i.xlarge nodes at $0.192 an hour, about $4,200 a month, on Kubernetes 1.33, which entered extended support in July. The control plane is $438. The cluster has 18 ALBs with 50 public addresses, two NAT Gateways processing 8 TB a month, and 4 TB of gp3 volumes, half orphaned. Requests average three times usage. Total: roughly $4,200 nodes, $438 control plane, $290 load balancers, $180 IPv4, $430 NAT, $320 EBS, and about $200 in cross-zone transfer, near $6,060 a month.

Right-sizing requests lets Karpenter consolidate the fleet to 14 nodes: about $1,950. Upgrading to a supported version returns the control plane to $73. Moving the 40 percent of workloads that are stateless to Spot and the rest to Graviton takes the node line to about $1,150. One ingress controller replaces the 18 ALBs, cutting load balancers and IPs to about $35. VPC endpoints for ECR and S3 halve NAT processing to about $215. Reclaiming orphaned volumes halves EBS to $160. Topology-aware routing trims transfer to about $80. The cluster now costs roughly $1,710 a month, a 72 percent reduction, serving the same workloads. The largest single step was the first one, requests, and it was only possible because someone could see that the data namespace was reserving nine times what it used.

How Opslyft Does This

The black box is the problem Opslyft opens first. Explorer breaks Kubernetes cost down by pod, service, or namespace, and shows it in the same view as the EC2 nodes, EBS volumes, load balancers, NAT Gateways, and public addresses around the cluster, so a namespace's cost is its share of the nodes it ran on plus the infrastructure it depends on, tracked over time, with a spike visible before the invoice. Canvas puts the cluster's cost on the platform team's screen and the per-team view on each team's, from the same numbers.

Dimension Studio handles the parts of a cluster bill that have no obvious owner: idle node capacity, system pods, the control plane, and the shared networking, which it allocates to teams and products by rule, fixed or proportional, without every workload needing a perfect label, and which is how a Kubernetes-heavy estate reports cost per customer or per feature rather than cost per node. Atlas keeps the inventory, every node, volume, load balancer, and address with an owner and a cost, and its change history ties a cost movement to the change behind it, a node group's size, a version upgrade missed, a new Service of type LoadBalancer. Its recommendations surface the request-versus-usage gap per workload and weigh purpose and criticality, so the payment service and the batch job get different advice at the same utilization.

Monitor detects anomalies at namespace level with a root-cause explanation, a deployment whose replicas tripled, a cluster that crossed into extended support, a NAT Gateway suddenly processing ten times its usual traffic, and routes them to the owning team's Slack channel; budgets at namespace, team, or cluster level hold the result. Tickets makes each finding an assigned item in Jira, ServiceNow, or Asana tracked to a measured saving, and Iris answers which namespaces grew fastest this month and why in plain English. The result is that the twelve levers above stop being a one-time project and become what each team does with its own number.

That is the pattern behind Disprz's result: six platforms including AWS, Azure, GCP, and OCI, 50 to 60 shared services, and many untagged resources, brought into one view with 100 percent automated attribution and 40 hours a month of manual allocation returned to the team.

The Bottom Line

EKS is cheap to run and expensive to run badly, and the difference is almost entirely in things the invoice does not show: requests reserving capacity nobody uses, versions aging into a six-fold penalty, load balancers and addresses multiplying per service, and traffic crossing zones and NAT for no reason. Right-size requests, stay in support, let Karpenter or Auto Mode place nodes, use Spot and Graviton, consolidate, commit the baseline, fix the networking, clean the storage, schedule non-production down, and allocate every dollar to a namespace with an owner. Done in that order the cluster commonly costs half what it did, and the allocation is what keeps it there. For the general method across any Kubernetes platform, see our Kubernetes cost optimization guide; for the GPU-specific version, allocating GPU costs in shared clusters.