AKS node pools running with the cluster autoscaler disabled
What does ZopNight detect here?
AKS node pools with the cluster autoscaler disabled hold a fixed node count whatever the workload does. Rule RC-1356 fires medium severity when the live agent-pool enableAutoScaling state, stamped by the discoverer as autoscaler_enabled, is explicitly "false"; an absent flag abstains. Unlike RBAC or network policy, autoscaling can be enabled in place.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1356 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | aks_node_autoscale.go |
Where it applies
Fixed node counts in an elastic platform
A node pool without the cluster autoscaler holds exactly the node count someone last typed in. Overnight and at weekends those nodes idle at full price; during a traffic spike, pods sit Pending because nothing adds capacity until a human notices. Kubernetes is built around the assumption that the node supply flexes with pod demand. A static pool quietly breaks that on both ends, and the failure mode at peak (unschedulable workloads) is the worse half.
Why compliance and not cost
ZopNight files this under compliance rather than attaching a savings estimate, because a disabled autoscaler is a configuration-posture gap, not a measured waste signal, and the pool might be perfectly sized today. No dollar figure is claimed. Separate metric-driven rules handle the cases where node utilization is measurably low; this one flags the missing mechanism, which matters even while the sizing happens to be right.
An agent-pool property, read live
The finding rests on the agent pool’s enableAutoScaling property, which the discoverer
reads from the live ARM API and stamps as autoscaler_enabled metadata; discovery runs
under the built-in Reader role. Rule RC-1356 fires only when that state is an explicit
"false" and fails safe when the flag is absent. A customer-editable autoscaler tag was
the old gate; the rule no longer reads tags at all, so labels cannot suppress or fake the
finding.
Enabling the autoscaler in place
No rebuild is needed. This is one of the AKS settings that changes on a running pool:
az aks nodepool update --cluster-name <cluster> -g <rg> -n <pool> \ --enable-cluster-autoscaler --min-count 1 --max-count 5Pick the minimum from your steady overnight load and the maximum from peak plus headroom. Pools running workloads that genuinely cannot tolerate node churn (stateful sets pinned to local disks, for instance) are the legitimate exception; document them where reviewers will look.
Inspect enableAutoScaling per pool
az aks nodepool list --cluster-name <cluster> -g <rg> \ --query "[].{pool:name, autoscale:enableAutoScaling, count:count, min:minCount, max:maxCount}" \ -o tablePools showing autoscale: false (with null min and max) are the ones this rule reports.