# Scheduling Amazon EKS Cluster

> EKS cluster schedules scale every managed node group's Auto Scaling group to zero and restore the saved sizes at start. The control plane cannot be stopped and keeps billing $0.10 an hour, about $73 a month. Clusters running Fargate or hybrid-node profiles are refused outright.

Source: https://zop.dev/integrations/aws/eks-cluster/schedule
Updated: 2026-08-19

---

## The $73 floor

An EKS control plane runs whether or not any nodes exist, at $0.10 an hour, roughly $73 a
month, per cluster. No schedule touches that. What the schedule drives to zero is the worker
compute, which on most clusters dwarfs the control-plane fee, but the floor is worth stating
because a fully scheduled cluster still shows up on the invoice every single day.

## Managed node groups are the reachable surface

The stop walks each managed node group and scales its Auto Scaling group to zero, recording the
sizes for the morning restore. Self-managed node groups, the Auto Scaling groups a team wired up
by hand, are invisible to this fan-out and keep running. If a cluster mixes both, the schedule
alone will not empty it.

## Why Fargate profiles block the schedule

ZopNight refuses to schedule clusters running Fargate or hybrid-node profiles. Fargate pods do
not live on node groups, so scaling node groups to zero would leave those pods running and the
"stopped" cluster still billing, a half-truth worse than no schedule. Hybrid nodes sit outside
AWS's scaling controls entirely. The refusal is deliberate: better an explicit no than a
schedule that appears to work.

## Eviction without a destination

Scaling to zero evicts every pod with nowhere to reschedule, including cluster add-ons like
CoreDNS and the metrics stack. They sit Pending overnight and start fresh when nodes return.
Workloads holding local state on node disks lose it, because node group scale-in terminates the
instances.

Stateful pods backed by EBS-based persistent volumes reattach cleanly once nodes return, though
the volumes themselves bill all night like any other disk.

## The morning is sequential

The restore sets each group back to its recorded size, then nodes must boot, join the cluster
and pass readiness before Pending pods place. On a cluster with several groups and slow-starting
daemonsets that is easily 5-10 minutes from cron to healthy, so start the schedule ahead of the
first team's morning.