# AKS Node Pool Autoscaler Not Enabled

> 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.

Source: https://zop.dev/integrations/azure/recommendations/aks-node-pool-autoscaler-not-enabled
Updated: 2026-08-19

---

## 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:

```bash
az aks nodepool update --cluster-name <cluster> -g <rg> -n <pool> \
  --enable-cluster-autoscaler --min-count 1 --max-count 5
```

Pick 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

```bash
az aks nodepool list --cluster-name <cluster> -g <rg> \
  --query "[].{pool:name, autoscale:enableAutoScaling, count:count, min:minCount, max:maxCount}" \
  -o table
```

Pools showing `autoscale: false` (with null min and max) are the ones this rule reports.