EKS Cluster Autoscaler: How It Works & Best Practices

By Ilya Pisatzkov
Solution Architect

Scaling Kubernetes infrastructure efficiently is one of the biggest challenges DevOps teams face. You don’t want to overprovision and waste money on idle resources, but underprovisioning can bring your apps to a grinding halt.

That’s where EKS Cluster Autoscaler (CA) automatically adds or removes nodes to match the demands of your workloads. But to get the most out of it, you need to understand how it works, configure it correctly, and optimize it for cost savings.

Let’s dive deep into how the EKS Cluster Autoscaler works, best practices for tuning it, and how it plays a key role in cloud cost optimization.

How Cluster Autoscaler Works

What Is the Cluster Autoscaler?

Cluster Autoscaler (CA) is an open-source Kubernetes component that automatically scales the number of nodes in your EKS cluster based on pending pods. Unlike the Horizontal Pod Autoscaler (HPA), which scales individual pods, CA focuses on scaling the infrastructure itself.

Think of it as a Kubernetes-native scaling brain that:

Adds nodes when there are pending pods with unsatisfied resource requests.
Removes nodes when they are underutilized and can be safely drained.
Balances workloads efficiently to avoid resource fragmentation.

How Does Cluster Autoscaler Decide to Add Nodes?

Let’s say you deploy an application, but there aren’t enough resources available on your existing nodes. The new pods stay in a Pending state because they can’t be scheduled.

Here’s how CA reacts:

It detects pending pods that can’t be scheduled due to resource constraints.
It evaluates existing node groups to see if increasing capacity would help.
It requests new nodes from AWS (using EC2 Auto Scaling Groups or Managed Node Groups).
New nodes join the cluster, and Kubernetes schedules the pending pods onto them.

Example Scenario:

Your cluster runs two m5.large nodes, each with 2 vCPUs and 8 GiB of RAM. You deploy a workload requiring 4 vCPUs and 16 GiB of RAM, but no existing node has enough capacity.

CA sees this and attempts to scale by adding a node from the available instance types in the ASG, such as an m5.2xlarge, if it has been configured as an option.

How Does Cluster Autoscaler Decide to Remove Nodes?

CA isn’t just about adding nodes—it also looks for opportunities to remove unneeded nodes to save costs.

Here’s how it decides when to remove a node:

Identifies underutilized nodes where no critical workloads are running.
Considers Pod Disruption Budgets (PDBs) and eviction policies before draining a node.
Evicts non-essential pods from those nodes and reschedules them elsewhere.
If the node is empty, it removes it from the cluster to cut costs.

Example Scenario:

You scaled up to 10 nodes during peak traffic, but now it’s midnight, and demand has dropped. CA finds that 3 nodes are mostly idle and safely removes them.

Result: Your cluster automatically scales down, saving money while keeping services running smoothly.

Best Practices for Optimizing Autoscaling

Cluster Autoscaler is powerful, but misconfigurations can lead to inefficient scaling, high costs, or performance issues. Here’s how to fine-tune it:

1. Set the Right Resource Requests for Your Pods

CA scales based on pod requests (not limits). If your pods don’t specify CPU and memory requests, CA won’t know how many nodes are needed

Example: Correct Pod Resource Requests

resources:
  requests:
    cpu: "500m"
    memory: "256Mi"

What happens if I don’t set resource requests?

CA underestimates if requests are too low → Pods might not get enough resources.
CA overestimates if requests are too high → You might overpay for unused capacity.

2. Use Multiple Node Groups for Flexibility

Instead of a single instance type, create multiple node groups with different sizes (e.g., small, medium, and large nodes). This gives CA more options to pick the best instance.