Kubernetes Cost Optimization: Right-Sizing EKS Clusters with Karpenter

Quick Summary & TL;DR (Answer-First)

Karpenter replaces the Kubernetes Cluster Autoscaler node-group model with direct, just-in-time EC2 provisioning matched to actual pod requests — typically cutting EKS compute spend by 30-60% while improving scheduling latency. Combined with Vertical Pod Autoscaler right-sizing and Spot-first consolidation, clusters carrying 3x more headroom than needed get trimmed back within a single sprint. This is FinOps applied at the orchestration layer — see the broader CloudLink FinOps optimization hub for how Kubernetes cost work fits into a full cloud bill review.

For an emergency cluster cost review, message the CloudLink SRE team on WhatsApp at +1 (945) 387-6031 (wa.me/19453876031).

Why Cluster Autoscaler Falls Short at Scale

The classic Cluster Autoscaler scales pre-defined node groups up or down based on pending pods, but cannot mix instance types within a group or choose the cheapest instance that satisfies a pod resource request. Teams end up running homogeneous, oversized node groups for safety margin, with 35-50% of provisioned CPU sitting idle at any given time.

Because node groups are provisioned ahead of demand, Cluster Autoscaler also reacts slowly to bursty workloads — a 60-90 second scale-up lag is common, which teams compensate for by keeping extra buffer nodes running around the clock. That buffer is pure waste on the monthly bill.

Migrating a production cluster to a different autoscaler is a change worth taking seriously rather than rushing. Run Karpenter alongside the existing Cluster Autoscaler on a subset of node pools first, validate scheduling behavior and cost under real traffic for one to two weeks, then cut over the remaining node pools once the team trusts the new provisioning behavior.

Figure 2: Why Cluster Autoscaler Falls Short at Scale Infrastructure Architecture Diagram

Karpenter: Just-in-Time Node Provisioning

Karpenter watches for unschedulable pods and provisions the cheapest EC2 instance type and size that satisfies their combined resource requests directly — no pre-defined node groups, no instance-type allowlists to maintain. It typically launches a new node in under 30 seconds and can bin-pack multiple pending pods onto a single larger instance rather than one node per pod.

Configure NodePools with broad instance-type flexibility (allow c, m, and r families across several generations) and let the bin-packing algorithm pick the true least-cost option per scheduling event. Accounts migrating from Cluster Autoscaler to Karpenter commonly see 30-45% lower EC2 spend in the first month purely from eliminating idle buffer capacity.

Set explicit NodePool limits on maximum CPU and memory to cap total spend during a runaway scaling event, such as a misconfigured job that creates thousands of pending pods. Karpenter will provision aggressively to satisfy demand by design, so a budget ceiling at the NodePool level is the safety net that keeps a bug from turning into a five-figure surprise on the monthly bill.

Right-Sizing Pods with VPA and Goldilocks

Node-level savings only go so far if pod resource requests are guessed rather than measured. Deploy the Vertical Pod Autoscaler in recommendation mode alongside Goldilocks to get a dashboard of actual P50/P99 CPU and memory usage per deployment, then set requests to P50 and limits to P99 plus 20% headroom.

Most teams initially over-request memory by 2-3x out of caution. Correcting this shrinks the bin-packing footprint Karpenter has to solve for, which compounds directly into fewer and smaller nodes — the node-level and pod-level optimizations reinforce each other rather than acting independently.

Roll VPA out in recommendation-only mode first across every namespace before switching any deployment to auto-update mode. Auto-update mode restarts pods to apply new resource requests, which is safe for stateless replicas behind a load balancer but can cause visible disruption for singleton or stateful workloads if enabled without a gating review.

Spot Consolidation Without Sacrificing Availability

Karpenter continuously re-evaluates running nodes and terminates ones that could be replaced by a cheaper combination, including migrating workloads onto Spot Instances automatically when a PodDisruptionBudget allows it. Configure Spot-to-On-Demand fallback for stateful or latency-sensitive pods, and Spot-first for stateless API and batch workers.

For workloads split between serverless functions and containers, this is also the point to revisit which compute model actually fits each service — see the Serverless vs Containerized tradeoffs guide for the cost crossover thresholds between Fargate, Lambda, and EKS.

Measuring the Win: Before/After Metrics That Matter

Do not judge a Karpenter migration purely by the invoice total, which is noisy month to month. Track EC2 cost per vCPU-hour actually consumed by scheduled pods, node count versus pending-pod count over a rolling 7-day window, and the percentage of nodes running on Spot versus On-Demand.

A healthy post-migration cluster typically shows node count tracking pod demand within minutes rather than sitting flat regardless of load, Spot coverage above 50-60% for stateless workloads, and CPU request utilization above 65-70% cluster-wide, up from the 35-50% baseline most teams start from before adopting just-in-time provisioning.

EKS Cost Optimization Support

The CloudLink SRE team implements Karpenter migrations, VPA rollouts, and Spot consolidation policies as part of a broader FinOps engagement — see the full playbook in How Enterprises Reduce AWS Bills by 45% in 2026.

Reach the team on WhatsApp at +1 (945) 387-6031 (wa.me/19453876031) or book a free cluster cost review at cloudlink.us/solutions/finops.