Karpenter, Cluster Autoscaler, Autopilot or Fargate: what decides a 300-node bill

Idle capacity is the line item

A 300-node Kubernetes estate is rarely short of capacity. It is short of work for the capacity it already pays for, which is why the largest reconciliation on the bill is usually not a workload but the gap between what is requested and what is running. Every mechanism here attacks that gap differently, and the settings that govern it are the ones a platform team actually owns.

Google changed the floor on 24 September 2026 with GKE 1.37, which adds native scale-to-zero. The implementation pairs HorizontalPodAutoscaler with an AutoscalingMetric custom resource that reads external signals from Google Cloud Managed Service for Prometheus, and enables minReplicas zero through KEP-2021. Workloads that run sporadically, such as batch processors, event-driven workers and development environments, can now drop to zero replicas and restart on GKE capacity buffers when the metric shows pending work.

Karpenter consolidates, the autoscaler trims groups

Karpenter runs one automated disruption method at a time, in order: node repair when enabled, then drift, then consolidation. For each candidate node it checks the disruption budget, runs a scheduling simulation of the pods on that node to see whether replacements are needed, taints the node, pre-spins any replacement and only then deletes. Consolidation is where the saving sits, because it replaces several partly used nodes with fewer fuller ones instead of waiting for a node group to become empty.

The Cluster Autoscaler reasons about node groups instead. It resumes scale-down evaluation ten minutes after a scale-up by default, the value of the scale-down-delay-after-add flag, and the separate unneeded-time flag decides how long a node must stay underused before it is a candidate. A team that sets that window to hours has chosen stability over savings, and the invoice records the choice.

Autopilot prices requests, Fargate prices pods

GKE Autopilot general-purpose workloads use pod-based billing: $0.0445 per vCPU-hour, $0.0049225 per GiB-hour of memory and $0.0001389 per GiB-hour of ephemeral SSD, charged in one-second increments with no minimum duration, on top of a flat cluster management fee of $0.10 per cluster per hour. The catch is in the manifest. Autopilot sets a default request when none is defined and raises values that fall below its minimums or its required CPU-to-memory ratios, so an unset request is not a free one. Spot capacity for the same pod pricing is $0.0133 per vCPU-hour at the time of writing.

EKS Fargate is priced per pod on requested resources: $0.04048 per vCPU-hour and $0.004445 per GB-hour for Linux on x86 in the US East region, plus $0.000111 per GB-hour for ephemeral storage, rounded up to the nearest second. Neither model gives you a node to pack, and that is the point of both: the platform stops carrying headroom and starts charging for declared demand, at a per-unit rate above what a committed instance costs. The trade is invisible on a small cluster and material at 300 nodes, because every workload that could have shared a node now carries its own request, and every request above what the service actually uses is billed.

What the arithmetic looks like at 300 nodes

Take a mid-size estate of 300 nodes averaging 16 vCPU, so roughly 4,800 vCPUs, of which 60 percent is requested. At list price, the 2,880 requested vCPUs on Autopilot would be $0.0445 times 2,880 times 730 hours, about $93,600 a month before memory and before any committed-use discount. On Fargate the same requested vCPUs would be about $85,100 at $0.04048, and neither number includes the memory line or the cluster fee.

The comparison only turns when you ask what the estate actually needs. If the workload runs to a steady profile with a small overnight trough, consolidation on Karpenter or a well-tuned autoscaler unneeded-time window recovers little. If it swings by half across the week, the difference between a system that removes nodes and one that keeps them is the difference between paying for 4,800 vCPUs and paying for 3,000.

The decision rule

If the estate already runs EKS and the spend is dominated by nodes that are half empty at midday, Karpenter is the cheaper answer because consolidation is the only mechanism in this list that actively replaces a fleet with a denser one, and the disruption budget keeps it from doing so faster than the services tolerate. If the cluster is stable, small and unlikely to change shape, the Cluster Autoscaler costs nothing to run and its ten-minute delay is a feature rather than a defect. The trade works until the node groups stop matching the workloads, at which point the delay and the fixed instance type become the reason the estate stays at its peak size all month.

If the team does not want to own nodes at all, Autopilot and Fargate both convert the problem into a manifest review, and Autopilot is the more granular of the two because memory and ephemeral storage are priced separately and requests drive everything. For a 200 to 500 node estate the usual split is Karpenter where the platform team exists, Autopilot where the team is small and the workloads are predictable, and Fargate for the handful of services whose traffic is too spiky to schedule. Budget for the settings, not the vendor: a ten-minute delay and a half-empty node group cost more than the per-hour difference between the four.