Kubernetes can start more application replicas only if there are machines with room to run them. Cluster Autoscaler addresses that capacity problem by increasing or decreasing AWS Auto Scaling groups, which are managed sets of virtual machines. It is useful when you already organize workers into those groups and want capacity to follow scheduling needs. This entry records an older AWS-specific chart, not the end of AWS support in Cluster Autoscaler.
Deployment and operating notes
The recovered page already identifies this older aws-cluster-autoscaler chart as no longer maintained. Do not transfer that statement to the current Kubernetes Cluster Autoscaler AWS provider. Upstream documents managing EC2 Auto Scaling groups through a controller Deployment, with IAM permissions restricted to the intended groups.
For an existing AWS installation, distinguish the retired chart name from the image actually running and its Kubernetes compatibility. Inventory group discovery tags, node-group bounds, labels, taints and IAM role bindings before moving to the current chart. Scale-up is driven by pods that cannot be scheduled, so missing requests, constraints and unsuitable instance types can matter more than average CPU. Verify a deliberately pending workload can create the right capacity and that disruption budgets permit safe scale-down. Karpenter is an alternative capacity model, not a chart alias: moving to it changes provisioning objects and node lifecycle. Do not allow two controllers to resize the same capacity while testing a replacement.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub does not mark kubernetes/autoscaler archived or disabled; this does not establish active maintenance, support or compatibility. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
No longer maintained. Use http://kubedex.com/resource/cluster-autoscaler/
The cluster autoscaler on AWS scales worker nodes within any specified autoscaling group. It will run as a Deployment in your cluster. This README will go over some of the necessary steps required to get the cluster autoscaler up and running.
This chart bootstraps an aws-cluster-autoscaler deployment on a Kubernetes cluster using the Helm package manager.
Prerequisites
Kubernetes 1.3+ with Beta APIs enabled
Installing the Chart
In order for the chart to configure the aws-cluster-autoscaler properly during the installation process, you must provide
some minimal configuration which can’t rely on defaults. This includes at least one element in the autoscalingGroups array
and its three values: name, minSize and maxSize. These parameters cannot be passed to helm using the –set parameter at
this time, so you must supply these using a values.yaml file such as:
autoscalingGroups:
– name: your-asg-name
maxSize: 10
minSize: 1
To install the chart with the release name my-release:
$ helm install stable/aws-cluster-autoscaler –name my-release -f values.yaml
The command deploys aws-cluster-autoscaler on the Kubernetes cluster using the supplied configuration. The configuration
section lists the parameters that can be configured during installation.
Auto-Discovery Setup
To run a cluster-autoscaler which auto-discovers ASGs with nodes use the –node-group-auto-discovery flag. For example,
–node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/<YOUR CLUSTER NAME> will
find the ASGs where those tag keys exist. It does not matter what value the tags have.
Note that:
It is recommended to use the second tag like k8s.io/cluster-autoscaler/<YOUR CLUSTER NAME> when k8s.io/cluster-
autoscaler/enabled is used across many clusters to prevent ASGs from different clusters recognized as the node groups
There are no –nodes flags passed to cluster-autoscaler because the node groups are automatically discovered by tags
No min/max values are provided when using Auto-Discovery, cluster-autoscaler will respect the current min and max values
of the ASG being targeted, and it will adjust only the “desired” value.
Common Notes and Gotchas:
- The /etc/ssl/certs/ca-certificates.crt should exist by default on your ec2 instance. If you use Amazon Linux 2, use
/etc/ssl/certs/ca-bundle.crt instead. - Cluster autoscaler is not zone aware (for now), so if you wish to span multiple availability zones in your autoscaling
groups beware that cluster autoscaler will not evenly distribute them. - By default, cluster autoscaler will not terminate nodes running pods in the kube-system namespace. You can override this
default behaviour by passing in the –skip-nodes-with-system-pods=false flag. - By default, cluster autoscaler will wait 10 minutes between scale down operations, you can adjust this using the –scale-
down-delay-after-add, –scale-down-delay-after-delete, and –scale-down-delay-after-failure flag. E.g. –scale-down-
delay-after-add=5m to decrease the scale down delay to 5 minutes after a node has been added. - If you’re running multiple ASGs, the –expander flag supports three options: random, most-pods and least-waste. random will expand a random ASG on scale up. most-pods will scale up the ASG that will scheduable the most amount of pods. least-waste will expand the ASG that will waste the least amount of CPU/MEM resources. In the event of a tie, cluster autoscaler will fall back to random.
Sources & further reading
Spotted something that needs another look?
Help improve this page →