EKS Cost Optimization: 8 Ways to Cut AWS Kubernetes Costs in 2026

Amazon EKS is the most widely deployed managed Kubernetes service, running workloads for tens of thousands of organizations on AWS. That popularity comes with a cost reality most teams discover only after their first AWS bill: EKS is cheap to start and expensive to leave unmanaged.

The problem isn't usually the workloads you're actively running. It's the waste that accumulates invisibly underneath them. EBS volumes that outlived the Pods they served. Elastic Load Balancers attached to Services that were deleted six months ago. CloudWatch log groups streaming from namespaces that no longer exist. Node groups provisioned for a peak that never came and never scaled back down.

This guide covers 8 concrete ways to reduce your EKS bill. The first step for most teams is an orphaned resource audit — a read-only scan that identifies what you're paying for and no longer using, before touching anything in production.

Understanding EKS Cost Components

EKS costs are distributed across several AWS services. Before optimizing, you need to know where the money goes.

EC2 instances (node groups) are almost always the largest line item. Each worker node is a standard EC2 instance — m5.large, m5.2xlarge, r5.4xlarge — and you pay the full on-demand or spot price regardless of how much of the node's capacity your Pods actually use. A node running at 15% CPU utilization costs exactly the same as one running at 90%.

EKS control plane costs $0.10/hour per cluster — $72/month. For a single cluster that's modest. For organizations running separate clusters per team, per environment, or per region, control plane fees multiply quickly.

EBS volumes back PersistentVolumeClaims. A gp3 volume costs roughly $0.08/GB/month; io1 and io2 volumes cost significantly more. The critical issue: EBS volumes are not deleted when Pods or Deployments are removed. They persist until someone explicitly deletes the PVC, and even then, volumes with a Retain reclaim policy stay until manually cleaned up.

Elastic Load Balancers are provisioned whenever you create a Kubernetes Service of type LoadBalancer. Each ALB or NLB costs roughly $0.008–$0.016/LCU-hour on top of a base hourly fee. Unused load balancers — pointing at Services with no backend Pods — still bill at the full hourly rate.

NAT Gateways process all outbound traffic from private subnets at $0.045/GB. In a typical EKS setup, every Pod in a private subnet sends all outbound traffic through a NAT Gateway. Data-heavy workloads can drive NAT Gateway costs to hundreds of dollars per month.

CloudWatch Logs accumulate from container logging, control plane audit logs, and VPC Flow Logs. Ingestion costs $0.50/GB; storage is $0.03/GB/month. Log groups from deleted workloads continue accruing retention costs until explicitly removed.

8 Ways to Cut EKS Costs

1. Audit and Delete Orphaned EBS Volumes

Orphaned EBS volumes are the fastest, safest cost reduction for most EKS clusters. They provide zero value and carry zero risk to delete — once you've confirmed no active workload is using them.

A PVC becomes orphaned when its associated Pod or Deployment is deleted without deleting the PVC. The underlying EBS volume keeps running. In clusters with active development, frequent migrations, or StatefulSet teardowns, orphaned volumes accumulate fast. A cluster running for 12 months might have 20–40% of its EBS spend tied to volumes nothing is reading or writing.

To find them: list all PVCs and cross-reference with running Pods. Any PVC not mounted by a running or pending Pod is a candidate for deletion. Check PV status for Released state — these are volumes whose claims were deleted but the underlying disk was retained.

KorPro surfaces this automatically. Connect your AWS account with read-only permissions and the orphaned PVC/PV report runs in under a minute, with estimated monthly savings per volume.

For more detail on the mechanics, see How to Find Orphaned PVCs and PVs Before They Inflate Your Cloud Bill.

2. Remove Unused Elastic Load Balancers

Every Kubernetes Service of type LoadBalancer provisions an AWS load balancer. When the Service is deleted, the load balancer is not always cleaned up — especially if the Service was deleted manually via kubectl delete without waiting for the cloud controller to deprovision the LB, or if the AWS Load Balancer Controller was uninstalled.

Check your AWS console or run aws elb describe-load-balancers and aws elbv2 describe-load-balancers to list all LBs. Cross-reference with active Kubernetes Services. Any load balancer that doesn't correspond to a running Service is waste. At $15–25/month per idle LB, a few stale ones add up to hundreds per year.

3. Right-Size Node Groups

Over-provisioned nodes are the most expensive inefficiency in most EKS clusters. Teams frequently provision large instance types — m5.4xlarge, c5.2xlarge — without measuring actual workload resource consumption.

Check actual CPU and memory utilization per node using kubectl top nodes or CloudWatch Container Insights. A m5.2xlarge (8 vCPU, 32 GB RAM) costing $0.384/hour and running at 12% CPU utilization is paying for 7 vCPU that are idle. Moving those workloads to m5.large (2 vCPU, 8 GB) instances and running more of them can cut node costs by 50–60% for CPU-light workloads.

Compare resource requests against actual usage — Pods often request 4x–8x what they actually consume. Right-sizing requests lets Kubernetes pack more Pods per node, improving bin-packing and reducing total node count.

4. Use Spot Instances for Stateless Workloads

EC2 Spot Instances run at 60–80% discounts compared to on-demand pricing for the same instance type. For stateless workloads — web servers, API handlers, batch processors, CI runners — Spot is the single highest-impact cost reduction available in EKS.

Configure a mixed node group with on-demand instances as a base (for critical, stateful workloads) and Spot instances for scalable, stateless capacity. Use --balance-similar-node-groups in Cluster Autoscaler or configure Karpenter with a Spot-preferred provisioner. Tag Spot-tolerant Pods with tolerations so they schedule onto the Spot node group.

The main risk — Spot interruption — is manageable for stateless workloads. Use PodDisruptionBudgets and configure graceful termination handlers.

5. Enable Cluster Autoscaler or Karpenter

Static node groups waste money during off-peak hours. If your production traffic peaks at 2x baseline, a static node group sized for peak runs at 50% utilization for the majority of the day.

Cluster Autoscaler scales node groups based on pending Pods — when Pods can't be scheduled, it adds nodes; when nodes are underutilized, it removes them. It's the standard approach and works well with managed node groups.

Karpenter is AWS's open-source node provisioner, designed specifically for EKS. It provisions individual nodes in response to unschedulable Pods (rather than scaling groups), selects the right instance type based on actual Pod requirements, and consolidates existing nodes when utilization is low. Karpenter typically achieves better bin-packing and faster scale-up than Cluster Autoscaler.

For clusters with variable load, either tool can reduce average node count by 30–50% compared to static sizing.

6. Clean Up Stale ConfigMaps and Secrets

ConfigMaps and Secrets don't carry compute costs themselves, but they're a signal of accumulated waste and can increase etcd size (which affects API server performance and backup costs). More importantly, removing them is part of the discipline of keeping clusters clean.

Stale ConfigMaps accumulate from Helm releases that were uninstalled without cleanup, CI/CD pipelines that create per-deployment configs, and deprecated feature flags. Run kubectl get configmaps --all-namespaces and sort by age — ConfigMaps that haven't been accessed in 90+ days are candidates for review.

For a systematic approach to finding orphaned ConfigMaps, see How to Find and Remove Orphaned ConfigMaps in Kubernetes.

Secrets left over from deleted Deployments can also be surfaced with KorPro's read-only scan, which cross-references Secrets against all active workloads across namespaces.

7. Use Namespace Budgets to Enforce Cost Governance

Without visibility into per-namespace costs, individual teams over-provision and the bill grows unchecked. Namespace-level cost allocation makes waste visible and attributable.

Use LimitRanges to set default resource requests and limits for Pods that don't specify them. Use ResourceQuotas to cap total CPU, memory, and storage per namespace. This prevents any single team or deployment from consuming unbounded resources.

For a detailed guide on namespace-level cost governance, see Kubernetes Cost Audit by Namespace.

Pairing namespace quotas with per-namespace cost reports creates a feedback loop: teams see what they're spending and have guardrails preventing runaway consumption.

8. Consolidate Small Clusters

Every EKS cluster costs at minimum $72/month in control plane fees — before a single node is provisioned. Teams that created separate clusters for dev, staging, QA, feature testing, and production often find they're paying $300–500/month in control plane fees alone.

Evaluate whether workloads in separate clusters could share a cluster using namespace isolation, RBAC boundaries, and network policies. A well-structured multi-tenant cluster with proper isolation typically costs significantly less than multiple single-purpose clusters.

When consolidation isn't appropriate (e.g., compliance requirements, separate AWS accounts), ensure that dev and staging clusters auto-scale to zero during off-hours using cluster autoscaler with a scale-to-zero-capable node group.

The EKS Cost Audit Workflow

An audit before cleanup prevents deleting the wrong things. Here's the recommended sequence:

1. Connect KorPro to your AWS account with read-only IAM permissions. No write access, no agents to install. Setup takes under 5 minutes — see the AWS setup guide for the exact IAM policy.

2. Review the orphaned PVC/PV report. KorPro lists every PVC not mounted by a running Pod, with the underlying EBS volume size and estimated monthly cost. Sort by cost to prioritize.

3. Review unused ConfigMaps and Secrets. The scan cross-references every ConfigMap and Secret in every namespace against active Deployments, StatefulSets, DaemonSets, Jobs, and ServiceAccounts. Anything not referenced is flagged.

4. Review unused Services and LoadBalancers. Services with no selector, or with selectors that match no running Pods, are surfaced with their associated load balancer cost.

5. Get estimated monthly savings. KorPro aggregates findings into a total estimated savings figure before you delete anything. Share the report with your team and decide what to clean up first.

For more on the cost recovery workflow and specifically orphaned PV/PVC cost recovery, see the KorPro use case pages.

EKS vs Self-Managed Kubernetes: Cost Comparison

Teams occasionally ask whether EKS is worth the $72/month control plane fee compared to running self-managed Kubernetes (kubeadm on EC2 or kops).

The answer depends on scale and operational capacity. Self-managed Kubernetes eliminates the control plane fee but introduces operational overhead: managing etcd, API server upgrades, control plane HA, and security patches. At small scale (2–3 engineers, 1–2 clusters), self-managed can save $144–432/year in control plane fees. At any meaningful engineering team size, that saving is outweighed by the operational cost of maintaining the control plane.

EKS with Fargate eliminates node management entirely but charges per Pod resource request — it costs more than managed node groups for high-density workloads. The right answer is almost always EKS with managed node groups, Cluster Autoscaler or Karpenter, and a proportion of Spot instances based on workload tolerance.

Conclusion

EKS cost optimization doesn't require a complete infrastructure redesign. The fastest wins — orphaned EBS volumes, unused load balancers, stale resources — are low-risk and immediate. Right-sizing and Spot instances deliver the largest sustained savings.

Start with the audit. Connect KorPro to your EKS clusters with read-only access, get a complete picture of what you're spending on resources that serve no workload, and build your cleanup list before touching anything. See the AWS setup guide to get started in under 5 minutes.