# Scheduling Amazon EKS Node Group

> Node group schedules call eks:UpdateNodegroupConfig to scale the group to zero, writing the original size into a tag on the node group and reading that tag back at start. Zero requires the group's minimum to allow 0, evicted pods wait as Pending, and deleting the tag orphans the restore.

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

---

## The tag is the memory

At stop, `eks:UpdateNodegroupConfig` takes the group to zero and the previous size is saved as a
tag on the node group itself. The start run reads that tag and scales back. That design has a
sharp edge: the tag is visible, editable and deletable in the console like any other tag, and a
tidy-up that strips unknown tags also strips the restore value. Leave it alone.

## Zero must be legal for the group

A node group whose minimum size is 1 or higher cannot be taken to zero, because the minimum wins. Check
the group's scaling configuration once before enabling the schedule; otherwise the stop
quietly parks the group at its minimum and the invoice shows less saving than promised.

## Only this group goes dark

Scoping the schedule to one node group is the point: a GPU pool can sleep from 7pm while the
system pool keeps the cluster's plumbing alive. Pods that were pinned to the scheduled group by
node selectors or tolerations go Pending overnight. Pods without pinning may reschedule onto the
remaining groups instead. They keep running, and their cost moves rather than disappears.

## The cluster autoscaler has a vote

If the cluster autoscaler manages this group and Pending pods demand it, the autoscaler will
scale the group back up in the middle of the night. A scheduled group should either be excluded
from autoscaling or hold workloads that genuinely stop overnight, so nothing generates the
Pending pressure that reverses the stop.

## Terminated nodes, clean morning state

Scale-in terminates the EC2 instances, so anything on local NVMe or emptyDir volumes is gone at
19:00 sharp. The morning nodes are new machines with new IPs that must boot, join and pass
readiness before the backlog of Pending pods lands, so allow minutes between the start cron and
the first workload's deadline.

Budget for image pulls as well: fresh nodes arrive with empty container caches, so workloads built
on large images add minutes to the first morning pods.