Kubernetes Optimization
How CostLens finds savings in Kubernetes node pools — idle nodes to remove, over-provisioned nodes to right-size, and steady workloads to move to Spot — across EKS, AKS, and GKE.
Node pools are where Kubernetes money is spent, and they're easy to over-provision — a pool sized for a peak that rarely comes, or left running long after its workload moved. CostLens analyses the real CPU utilisation of every managed node pool and recommends one of three levers, depending on how busy the pool actually is.
It works identically across the three managed-Kubernetes services:
| Cloud | Node pools are backed by |
|---|---|
| Amazon EKS | EC2 instances in an Auto Scaling Group |
| Azure AKS | A Virtual Machine Scale Set in the node resource group |
| Google GKE | A Managed Instance Group |
The three levers
CostLens measures each node pool's average CPU over 14 days and sorts it into exactly one bucket — so a pool is never double-counted across recommendations.
| Average CPU | Recommendation | What it means |
|---|---|---|
| Under 5% | Remove the idle node pool | The pool is doing almost nothing — scale it to zero or delete it |
| 5%–25% | Right-size to a smaller node | The pool is used but over-provisioned — move to the next size down |
| 25% and up | Move to Spot | The pool is genuinely busy — the saving is cheaper capacity, not fewer nodes |
Utilisation comes from the cloud, not the cluster
CostLens derives node CPU from each cloud's own metrics — CloudWatch for EKS, Azure Monitor for AKS, Cloud Monitoring for GKE — by following the node pool down to the VMs backing it. No metrics-server, Container Insights, or in-cluster agent is required.
Idle node pool
A node pool averaging under 5% CPU over 14 days is effectively idle — you're paying for VMs that aren't doing meaningful work.
CostLens maps the pool to its VMs
Each managed node pool is traced to its backing compute — the EC2 Auto Scaling Group (EKS), the Scale Set in the MC_ node resource group (AKS), or the Managed Instance Group (GKE).
It reads 14 days of CPU
Average CPU across the pool's nodes is pulled from the cloud's monitoring service.
Idle pools are flagged
Pools under 5% average CPU are flagged, with an estimated monthly saving of the full node cost (node count × hourly rate × 730 hours). Pools already scaled to zero, or not in a running state, are skipped.
What to do: confirm the workloads on that pool are genuinely unused, then scale the pool to zero or delete it. This is an advisory recommendation — CostLens does not delete node pools automatically.
Node right-sizing
A pool that runs at 5%–25% CPU is doing real work but on more hardware than it needs. CostLens recommends the next size down.
To avoid a bad call on spiky workloads, a pool must also meet two guardrails before it's flagged:
- Its peak daily-average CPU must stay below 50% — so a pool that spikes hard some days is left alone.
- The node must be at least xlarge, so there's a clean smaller size to drop to.
The recommended type is one size smaller, and the estimated saving is the price difference across the whole pool (rate difference × node count × 730 hours).
Right-sizing replaces nodes
Moving a node pool to a smaller machine type recycles its nodes. Kubernetes reschedules the pods, but confirm the workloads tolerate a rolling node replacement and that the smaller size still has enough memory before applying.
Move to Spot
A pool at 25% CPU or higher is well-utilised — removing or shrinking it would hurt. The saving here is cheaper capacity: running the same nodes on Spot (AWS / Azure) or Spot VMs / Preemptible (GCP) cuts roughly 70% off the compute price. On EKS, moving suitable workloads to Fargate is an alternative.
This is an advisory recommendation with no automatic fix, because Spot capacity can be reclaimed by the cloud at short notice — you confirm the workload tolerates interruption before switching. Pools already running on Spot are skipped.
Severity and savings
Every Kubernetes recommendation is prioritised by its estimated monthly saving, the same way the rest of CostLens ranks findings:
| Severity | Estimated monthly savings |
|---|---|
| critical | >$500 |
| high | $100–$500 |
| medium | $20–$100 |
| low | <$20 |
Where to find them
Kubernetes recommendations appear alongside every other finding on the Recommendations page. Filter by the check name or resource type to see just your node-pool recommendations, and open any one for its full explanation and estimated saving.
Advisory by design
The Kubernetes node-pool checks are advisory — CostLens recommends the change and quantifies the saving, but you apply it in your own tooling (Terraform, the cloud console, or your cluster autoscaler config). This keeps capacity decisions, which affect availability, firmly in your hands.
Required permissions
These checks use the read-only compute and monitoring access already granted when you connected the account — no extra permissions beyond the standard CostLens setup for AWS, Azure, and GCP.
Limitations
- Utilisation is based on the previous 14 days; pools with variable or seasonal load may need a human sanity-check.
- Savings are list-price estimates from each cloud's rate card, not a quote — treat them as a prioritisation signal.
- Right-sizing only fires for node pools at xlarge or larger, so there's a clean smaller size to recommend.
Related
- Kubernetes Costs — see cluster, namespace, and workload cost
- EC2 Rightsizing — the same idea for standalone EC2 instances
- Recommendations — how CostLens surfaces and prioritises savings