# Cutting Kubernetes Dev/Test Cluster Cost: Tools Compared

> Dev clusters cost you a control-plane fee plus nodes. How EKS, GKE, AKS, Kubecost, CAST AI, Spot Ocean, Zesty and ZopNight each reduce one or both after hours.

Source: https://zop.dev/best/kubernetes-dev-cluster-cost-tools
Published: 2026-09-25 · Author: avinash-gaurav · Tags: zopnight, buyers-guide, kubernetes

---

A dev cluster that sits idle overnight still pays for its control plane and for any nodes left running. The tools below attack different parts of that bill at different grains.

## What we compared, and when

We compared the managed-Kubernetes controls from AWS, Google and Microsoft with five products: IBM Kubecost, CAST AI, Spot Ocean, Zesty and ZopNight (which publishes this page). All sources were read on 25 September 2026 and are linked inline. The native controls come first; the products follow in alphabetical order. That is not a ranking. The question for each was the same: when nobody is using a dev or test cluster, what can this tool turn off, and at what grain?

## Two bills, three grains

A managed cluster has two cost lines that behave differently.

- **The control plane.** EKS charges "$0.10 per hour for each Amazon EKS cluster that you create" on standard version support, and $0.60 an hour on extended support ([EKS pricing](https://aws.amazon.com/eks/pricing/)). GKE charges "a flat cluster management fee of $0.10 per cluster per hour", with a free tier of $74.40 a month per billing account, "equivalent to one free Autopilot or zonal Standard cluster" ([GKE pricing](https://cloud.google.com/kubernetes-engine/pricing)). Scaling nodes to zero does not remove this fee.
- **The nodes.** These stop costing only when the node VMs go away.

Off-hours tools work at one of three grains: the **cluster** (everything off), the **node pool** (capacity to zero, control plane stays), or the **namespace** (one team's workloads off inside a shared cluster). A namespace stop frees pods; whether nodes then disappear depends on your cluster autoscaler. On GKE Standard, Google says the cluster autoscaler "never automatically scales down a cluster to zero nodes" because "one or more nodes must always be available in the cluster to run system Pods" ([GKE cluster autoscaler](https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-autoscaler)).

| Tool | Off-hours grain | Platforms named | Continuous optimization |
|---|---|---|---|
| EKS (native) | Node group to zero (minSize 0) | EKS | Cluster Autoscaler honours min and max |
| GKE (native) | Node pool resize; autoscaler keeps a node on Standard | GKE | Cluster autoscaler |
| AKS (native) | Whole-cluster stop, control plane deallocated | AKS | Cluster autoscaler |
| CAST AI | Cluster hibernation to zero nodes | EKS, AKS, GKE, on-prem | Pod rightsizing, node autoscaling, spot |
| IBM Kubecost | Namespace turndown; cluster-turndown (alpha) | EKS, AKS, GKE, on-prem | Request sizing |
| Spot Ocean | Shutdown Hours: nodes to zero | ECS, EKS, AKS, GKE | Capacity blending |
| Zesty | None found; FastScaler hibernates nodes for spikes | EKS; Insights agent on AKS | CPU, memory and replica rightsizing |
| ZopNight | Cluster, node pool or namespace schedule | EKS, GKE, AKS | Recommendations; workload rules |

## Native controls

### Amazon EKS

EKS bills per cluster you create, so for an idle dev cluster the lever you control is nodes. A managed node group's `minSize` has a "minimum value of 0" ([NodegroupScalingConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_NodegroupScalingConfig.html)), so a scheduled job can take a dev node group to zero. The same page notes the Cluster Autoscaler "doesn't scale a managed node group lower than minSize". See <a href="https://zop.dev/integrations/aws/eks-nodegroup/schedule">EKS node group scheduling</a>.

- **Good fit if** you are happy to own the script or pipeline that sets the node group size twice a day.
- **Not a fit if** you want the $0.10-an-hour control plane gone too.

### Google Kubernetes Engine

You can resize a node pool with `gcloud container clusters resize --num-nodes` ([node pools](https://cloud.google.com/kubernetes-engine/docs/how-to/node-pools)), but on Standard clusters the autoscaler will not take the cluster to zero by itself. The management fee applies "irrespective of the mode of operation, cluster size, or topology", so one zonal dev cluster fits the free tier while a second one pays. See <a href="https://zop.dev/integrations/gcp/gke-nodepool/schedule">GKE node pool scheduling</a>.

- **Good fit if** one zonal dev cluster covered by the free tier is enough.
- **Not a fit if** you expected the autoscaler alone to empty a quiet Standard cluster.

### Azure Kubernetes Service

AKS documents a whole-cluster stop. "Stopping your cluster deallocates the control plane and releases the capacity", state is kept "for up to 12 months", and clusters using Node Autoprovisioning cannot be stopped. Microsoft warns that "in regions experiencing capacity constraints, customers may be unable to start a stopped cluster" ([AKS start and stop](https://learn.microsoft.com/en-us/azure/aks/start-stop-cluster)). AKS offers Free, Standard and Premium management tiers; the Free tier has "best-effort uptime (no financially backed SLA)" ([pricing tiers](https://learn.microsoft.com/en-us/azure/aks/free-standard-pricing-tiers)). See <a href="https://zop.dev/integrations/azure/aks-cluster/schedule">AKS scheduling</a>.

- **Good fit if** a dev cluster can go fully dark and you can tolerate a failed morning start in a busy region.
- **Not a fit if** you use Node Autoprovisioning, or only part of the cluster should go off.

## Products

### CAST AI

Hibernation scales "your cluster to zero nodes while preserving the control plane and cluster state". Schedules can automate hibernation and resumption, only hibernation ("manual resumption required"), or only resumption, in a time zone you pick ([hibernation docs](https://docs.cast.ai/docs/autoscaling-cluster-hibernation.md)). While clusters run, CAST AI rightsizes pods, scales nodes and optimizes spot on "EKS, AKS, GKE or on-prem" ([cast.ai](https://cast.ai/)). See <a href="https://zop.dev/compare/cast-ai-vs-zopnight">CAST AI compared</a>.

- **Good fit if** whole dev clusters sleep together and you also want daytime node packing.
- **Not a fit if** several teams share one cluster on different hours; hibernation works on the cluster.

### IBM Kubecost

Kubecost's product page lists "namespace turndown" and "automated request sizing" among its automated actions, and a free Foundations tier for clusters up to 250 cores ([IBM Apptio](https://www.apptio.com/products/kubecost/)). Its open-source cluster-turndown scales "non-prod environments (e.g. dev clusters) to zero during off hours" on GKE, EKS and kops, and is "currently in ALPHA" ([README](https://raw.githubusercontent.com/kubecost/cluster-turndown/master/README.md)). See <a href="https://zop.dev/compare/kubecost-vs-zopnight">Kubecost compared</a>.

- **Good fit if** you first need to know which namespace costs what, at no licence cost.
- **Not a fit if** you need a production-grade cluster turndown on AKS; the alpha project names GKE, EKS and kops.

### Spot Ocean

For Ocean-managed clusters, outside your running hours "the underlying instances of the cluster's nodes are scaled down to zero", and Spot recommends this for development, testing and staging ([Shutdown Hours](https://raw.githubusercontent.com/spotinst/help/HEAD/src/docs/ocean/features/running-hours.md)). Ocean integrates with ECS, EKS, AKS and GKE ([getting started](https://raw.githubusercontent.com/spotinst/help/HEAD/src/docs/ocean/getting-started/README.md)). See <a href="https://zop.dev/compare/spot-io-vs-zopnight">Spot compared</a>.

- **Good fit if** Ocean already manages your nodes and spot capacity.
- **Not a fit if** you do not want Ocean managing node capacity just to get a night schedule.

### Zesty

Zesty is built for clusters under live load. Multi-dimensional autoscaling will "continuously rightsize CPU, memory, and replica counts" ([product page](https://zesty.co/platform/multi-dimensional-autoscaling/)). FastScaler keeps "a pool of hibernated nodes ready to handle any traffic spike" ([FastScaler](https://zesty.co/platform/fastscaler/)), which speeds scale-up rather than switching dev clusters off. Its docs cover installing Kompass on EKS and the Insights agent on EKS and AKS ([docs index](https://docs.zesty.co/llms.txt)). See <a href="https://zop.dev/compare/zesty-vs-zopnight">Zesty compared</a>.

- **Good fit if** your test clusters run long load tests that need requests kept tight.
- **Not a fit if** the goal is nights and weekends off; we found no off-hours scheduling on its pages.

### ZopNight

ZopNight schedules Kubernetes at all three grains. It starts and stops EKS, GKE and AKS clusters, including node pools, and it can stop a single namespace. On a namespace stop, Deployments and StatefulSets scale to 0 and CronJobs are suspended. HPAs and PDBs are removed and restored on start, so an autoscaler does not undo the stop. System namespaces (`kube-*`, `zopnight-*`, `istio-*`, `helm-*`, `default`) are skipped. One implementation drives EKS, GKE and AKS. Each namespace can have its own cron schedule and timezone, and an override keeps it up for a set window with a reason. Outside off-hours, workload rules flag missing requests and limits, single replicas, privileged containers and unbound volumes; a single-replica fix is a guided manifest edit, never automatic. See <a href="https://zop.dev/integrations/kubernetes/namespace/schedule">namespace scheduling</a> and <a href="https://zop.dev/learn/namespace-vs-cluster-scheduling">namespace versus cluster scheduling</a>.

- **Good fit if** several teams share dev clusters on different hours, or the same schedule must also stop the VMs and databases the cluster talks to.
- **Not a fit if** what you need is continuous pod rightsizing and node bin-packing during the day.

## When not to pick ZopNight

- **Your cost is daytime over-provisioning.** CAST AI and Zesty rightsize pods and nodes continuously. ZopNight raises Kubernetes recommendations, and its autoscaler policies target Auto Scaling groups, VM scale sets, managed instance groups and ECS services, not pods.
- **You want spot node brokering.** Spot Ocean and CAST AI do this; it is not part of ZopNight.
- **Your clusters are on-prem or OpenShift.** ZopNight starts and stops EKS, GKE and AKS. It discovers Red Hat OpenShift on AWS (ROSA) clusters but cannot stop them, and on-prem clusters are not in its provider list.
- **You only need namespace cost allocation.** Kubecost's free tier does that inside the cluster.

## Frequently asked questions

### Does scaling my nodes to zero stop all Kubernetes charges?

No. EKS charges $0.10 per cluster per hour on standard support and GKE charges a $0.10 per cluster per hour management fee, whether or not nodes run. GKE's free tier covers one zonal or Autopilot cluster per billing account. AKS can stop a cluster, which deallocates the control plane.

### Why does my GKE dev cluster keep one node overnight?

Google documents that on Standard clusters the cluster autoscaler never scales a cluster down to zero nodes, because at least one node must run system Pods. Resize the node pool explicitly or use a scheduler that does.

### Is it better to stop a namespace or a whole cluster?

Stop the cluster when everything in it can go off together. Stop namespaces when teams share a cluster on different hours. A namespace stop only saves node cost if your cluster autoscaler then removes the emptied nodes.

### Can a stopped AKS cluster fail to start?

Yes. Microsoft warns that in regions with capacity constraints, customers may be unable to start a stopped cluster, and does not recommend stopping mission-critical workloads for that reason.
