Kubernetes autoscaling cost does not arise at the pod autoscaler itself but at the nodes its decisions pull in: the Horizontal Pod Autoscaler (HPA) changes the number of replicas, the Vertical Pod Autoscaler (VPA) their requests, KEDA scales down to zero, and each change moves the sum of requests by which the node autoscaler adds and removes nodes. The bill therefore follows with a delay, and only as far as nodes actually disappear. This page describes how the three pod autoscalers change node demand, what the VPA's recommendation mode delivers for free, what scale-to-zero really saves in a cluster with nodes, and what happens when an HPA scales and no node has room. The node autoscalers' mechanics are under Cluster autoscaler, Karpenter and node provisioning, the cross-provider view of scheduling and auto-scaling in the optimisation chapter.

How it works

The HPA is part of core Kubernetes and computes, every sync period (15 seconds by default), the desired replica count from the ratio of measured to desired metric: the new count is the current count times the quotient of current and target value, rounded up. A CPU utilisation target is a percentage of the request; if a container lacks a CPU request, the pod's utilisation is undefined and the HPA takes no action for that metric. It does not apply to DaemonSets, which cannot be scaled. Every added replica brings its requests along: it occupies room on a node or forces a new one.

The VPA is an add-on and must be installed separately. It derives requests from observed usage and applies them according to its mode: Off only writes the recommendation into the VPA object's status, Initial sets it when a pod is created, Recreate evicts pods whose requests differ from the recommendation, InPlaceOrRecreate changes them in the running pod where possible. For cost the direction matters: when the VPA lowers requests, more pods fit on a node and the node autoscaler can remove nodes; when it raises them because usage was higher than assumed, the cluster needs nodes it did not pay for before. Off delivers these numbers without touching a pod, which is why measurement starts there (rightsizing).

KEDA extends the HPA with event sources (queues, topics, cron, metrics) and with zero: by default a ScaledObject scales to zero replicas when no trigger is active, and KEDA itself handles the step between zero and one; from one replica on, the HPA that KEDA creates for it decides. The cooldownPeriod (300 seconds by default) waits after the last active trigger before scaling to zero; pollingInterval (30 seconds by default) sets how often the trigger is checked; idleReplicaCount allows an idle size below the minimum.

All three reach the bill only through the nodes. In a cluster with nodes, one replica fewer is cheaper only once a node becomes unneeded and the node autoscaler removes it, which minimum sizes, waiting periods and blocking pods can prevent. In a model billed per pod, such as GKE Autopilot or AWS Fargate, every replica and every request is a line item at once: there scale-to-zero saves in the second the pod disappears, and a VPA change alters the price with no node moving.

by nodeby pod: Autopilot,FargateHPA, VPA or KEDA changesreplicas or requestsHow is thecluster billed?One replica fewer is cheaper onlyonce a node becomes unneeded andthe node autoscaler removes itPrevented by minimum sizes,waiting periods and blocking podsEvery replica and every requesta line item at once: scale-to-zerosaves the second the pod disappears
Pod autoscalers reach the bill only through the nodes in a cluster with nodes, and at once where the pod itself is billed

What it means for your cost

Pod autoscaling is the cluster's demand side, node autoscaling its supply side, and the bill arises on the supply side. Three consequences follow. First, an HPA needs node headroom or a fast node autoscaler: without free capacity new replicas stay Pending until a node is ready, and the capacity that absorbs this is paid idle (capacity planning and headroom). Second, the VPA's effect on the bill is its effect on the node count; a recommendation that saves ten percent of requests saves nothing if the same nodes run afterwards. Third, the value of scale-to-zero depends on the billing model: immediate on Autopilot and Fargate, on nodes only together with consolidation or a pool allowed to reach zero.

HPA and VPA on the same CPU and memory metrics work against each other: the VPA lowers the request, the HPA measures utilisation against the request and starts more replicas at the same load. They are combined with separate metrics instead, say HPA on requests per second and VPA on memory. What an autoscaler has saved shows only in the nodes' instance hours or the billed pod resources (from estimated to verified savings); the replica count is no evidence.

The VPA lowers the requestThe HPA measures utilisationagainst the requestMore replicas at the same loadSeparate metrics instead: HPA onrequests per second, VPA on memoryThe evidence: the nodes' instancehours or the billed pod resources,never the replica count
HPA and VPA on the same metric work against each other, so they get separate metrics, and the saving shows only in the nodes' hours

Where it goes wrong

  • HPA scales, pods stay Pending. Symptom: at load peaks new replicas sit without a node for minutes. Cause: no headroom, and the node autoscaler needs minutes for a new node; the peak is over before the capacity arrives, and the capacity stays until scale-down.
  • HPA does nothing. Symptom: the replica count stays flat under load. Cause: a container lacks a CPU request; utilisation is undefined.
  • VPA recommendation applied, bill unchanged. Symptom: requests fell, instance hours did not. Cause: no node became unneeded, or the pool's minimum size holds the nodes.
  • VPA and HPA feed each other. Symptom: after a VPA reduction the replicas rise. Cause: both react to the same metric; the HPA measures against the lowered request.
  • Scale-to-zero without effect. Symptom: deployments sit at zero overnight, node cost stays. Cause: the nodes keep running because the pool's minimum is above zero or another pod holds them.
  • Cooldown too short. Symptom: a worker starts and stops every few minutes. Cause: cooldownPeriod is shorter than the gap between events, and every start pays its startup time.

Example

List prices read on 2026-10-21: in Frankfurt (eu-central-1) an m6i.large (2 vCPU, 8 GiB) costs USD 0.115 per hour on demand under Linux; in GKE Autopilot in Frankfurt (europe-west3) a vCPU costs USD 0.0573 and a GiB USD 0.0063421 per hour.

A deployment with two replicas, each requesting 1 vCPU and 3 GiB, runs on two m6i.large. An HPA raises it to six replicas under load; four new pods need two more nodes, which the node autoscaler creates only after the pods are Pending. After the peak the HPA holds the replicas through its stabilisation window (300 seconds by default), and the Cluster Autoscaler removes a node only after it has been unneeded for ten minutes: every peak pays at least that tail for two nodes, at ten minutes 2 × (10/60) × 0.115 = USD 0.0383, for 30 peaks a month USD 1.15, plus the minutes the nodes ran before scale-down. A worker waiting with one replica of 0.5 vCPU and 2 GiB on Autopilot costs 0.5 × 0.0573 + 2 × 0.0063421 = USD 0.0413 per hour idle, USD 30.17 in a 730-hour month; scaled to zero by KEDA it costs nothing while no event is pending. On a node cluster the same step saves only once the node it occupied is removed.

Sources

Read on 2026-10-21. Kubernetes Horizontal Pod Autoscaling and Vertical Pod Autoscaling, KEDA scaling deployments and ScaledObject specification, Cluster Autoscaler FAQ, AWS Price List bulk API, offer AmazonEC2, eu-central-1, GKE pricing.