How to Cut Amazon EKS Costs: A Practical Checklist

Amazon EKS bills grow quietly. A cluster that started lean picks up oversized nodes, forgotten load balancers, idle environments, and pods that reserve far more CPU and memory than they use. The good news: most EKS overspend comes from a short list of fixable causes. Here is the checklist we work through on real clusters, in the order that usually returns the most savings for the least risk.

1. Right-size pod requests and limits

This is where most Kubernetes waste hides. Every pod reserves the CPU and memory set in its requests, and the scheduler packs nodes based on those numbers, not on actual usage. If your requests are double what the app really uses, you are paying for roughly twice the nodes you need.

• Pull real usage from the Kubernetes Metrics Server, Prometheus, or your APM.
• Set requests close to steady-state usage and limits high enough to absorb spikes.
• Use a Vertical Pod Autoscaler in recommendation mode to surface good values before you apply them.

Getting requests right often shrinks the node count more than any other single change.

2. Scale the nodes, not just the pods

The Horizontal Pod Autoscaler adds pods, but something has to add and remove nodes underneath them. Two common options:

• Cluster Autoscaler adjusts node group size based on pending pods.
• Karpenter provisions right-sized nodes on demand and consolidates underused ones, which usually bin-packs more tightly than fixed node groups.

Either way, make sure nodes scale down aggressively during quiet periods. A cluster that only ever scales up is a cluster that only ever costs more.

3. Use Spot capacity for the workloads that tolerate it

Spot Instances are the same EC2 capacity at a large discount, with the tradeoff that AWS can reclaim them. Batch jobs, CI runners, stateless services, and dev environments are usually fine on Spot with a couple of on-demand nodes as a floor. Karpenter and managed node groups both support Spot with automatic fallback to on-demand when capacity is tight.

4. Commit to a baseline with Savings Plans

Whatever compute you run around the clock should not be paying on-demand rates. Compute Savings Plans discount steady EC2 and Fargate usage in exchange for a one or three year commitment. Cover your baseline with a Savings Plan and let Spot and on-demand handle the variable top layer.

5. Find and kill idle spend

Idle resources rarely announce themselves. Common culprits:

• Load balancers left behind by deleted Services.
• Unattached EBS volumes and old snapshots.
• Non-production clusters running full size overnight and on weekends.
• Over-provisioned managed add-ons and logging you no longer read.

Scaling dev and staging down outside working hours alone can remove a meaningful slice of the bill.

6. Make cost visible by team and service

You cannot optimize what you cannot see. Turn on cost allocation with Kubecost or OpenCost, or AWS split-cost allocation for EKS, so spend is attributed by namespace, team, and workload. Once engineers can see what their service costs, the conversation shifts from "the cloud is expensive" to "this job does not need that much."

Do it in the right order

Chase visibility and right-sizing first, because they cut the base you are about to buy Savings Plans against. Buying a large commitment on top of an over-provisioned cluster just locks in the waste.

This is exactly the work we do as an AWS Advanced Tier Partner. On a recent healthcare platform migration to Amazon EKS, this approach cut cloud costs by roughly 35% while keeping performance and uptime intact. If you want a second set of eyes on your EKS bill, book a free audit and we will send back prioritized, no-obligation recommendations, or read more about our FinOps and cost optimization and Kubernetes and EKS work.