Amazon EKS Cost Optimization

By Illusio Platform Engineering Team · Last reviewed: 2026 · 10 min read

Amazon Elastic Kubernetes Service (EKS) gives engineering teams immense scaling power, but without active FinOps guardrails, Kubernetes clusters become a major source of invisible cloud waste.

Where Does the Money Go in Amazon EKS?

While the AWS managed control plane costs a modest $0.10/hour ($73/month per cluster), 90%+ of total EKS expenditure lies in data plane infrastructure: EC2 worker nodes, provisioned EBS volumes, load balancers, cross-AZ traffic, and observability ingestion.

1. The "Slack Capacity" Trap: Pod Requests vs. Limits

In Kubernetes, the scheduler places pods onto worker nodes based strictly on pod resources.requests, not actual usage. When application developers arbitrarily set cpu: 2000m and memory: 4Gi as safety buffers, Kubernetes reserves those resources completely. If the pod actually uses 200m CPU and 800Mi RAM, 80% of the underlying EC2 instance sits idle while forcing the cluster to provision additional worker nodes.

See our detailed guide on Kubernetes Resource Rightsizing for safe tuning strategies using VPA and Goldilocks.

2. Modernizing Autoscaling: Why Karpenter Replaces Cluster Autoscaler

The legacy Kubernetes Cluster Autoscaler operates by expanding existing EC2 Auto Scaling Groups (ASGs). This creates structural inefficiencies because ASGs force homogeneous instance sizing (e.g. all m5.2xlarge).

Karpenter bypasses ASGs and provisions EC2 instances directly from the entire AWS instance catalog. When unscheduled pods request resources, Karpenter calculates the exact mathematical combination of compute and memory required, provisioning the cheapest eligible instance in seconds.

Crucially, Karpenter features active consolidation: it continually monitors worker nodes and automatically replaces underutilized instances with smaller ones or consolidates workloads onto fewer nodes. Read our deep dive: Karpenter Cost Optimization for EKS.

3. Leveraging Spot & Graviton on EKS Data Planes

Stateless microservices, asynchronous workers, and CI/CD runners should run on EC2 Spot Instances, delivering up to 70–90% discounts over on-demand rates. With Karpenter, Spot capacity can be diversified across dozens of instance types (e.g. c6g, c7g, m6g, m7g), ensuring zero downtime even if AWS reclaims a specific instance pool.

Furthermore, transitioning node pools to AWS Graviton (ARM64) instances lowers compute cost by up to 20% while providing superior memory bandwidth.

4. Persistent Storage (EBS CSI Driver)

Stateful workloads running on EKS frequently provision default gp2 StorageClasses. Migrating your storage classes to gp3 provides an immediate 20% price reduction per provisioned GB while delivering 3,000 baseline IOPS without paying for volume size overprovisioning. See EBS & Snapshot Cost Optimization.

5. Ingress & Load Balancing Consolidation

Creating a Kubernetes Service of type LoadBalancer for every internal microservice provisions an individual AWS Network Load Balancer (NLB) or Application Load Balancer (ALB). At ~$20–$25/month base charge per load balancer plus LCU metrics, having 30 microservices can generate $800+/month in idle ingress charges.

Instead, use the AWS Load Balancer Controller with target-group binding or deploy ingress controllers (e.g. Ingress-Nginx or Envoy Gateway) that consolidate hundreds of routing rules behind a single redundant ALB.

6. Log Ingestion & Observability Costs

Unfiltered container stdout logs forwarded indiscriminately to Amazon CloudWatch Logs often cost more than the EC2 compute hosting the application. Standard CloudWatch ingestion costs $0.50 per GB ingested. Implementing log level filtering (dropping DEBUG logs in production) or forwarding logs to S3-backed architectures like Grafana Loki reduces observability spend by up to 80%.