Scheduling Amazon EKS Node Group
eks:UpdateNodegroupConfigCan ZopNight schedule 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.
How the stop works
| Field | Value |
|---|---|
| Behaviour | node group scaled to zero via eks:UpdateNodegroupConfig on stop; the original size is saved as a tag and restored on start. |
Example schedules
- 0 8 * * 1-5 — Business Hours Start: Start at 8:00 AM on weekdays
- 0 18 * * 1-5 — Business Hours Stop: Stop at 6:00 PM on weekdays
- 0 22 * * * — Night Shutdown: Stop at 10:00 PM every day
- 0 6 * * 1-5 — Morning Startup: Start at 6:00 AM on weekdays
- 0 20 * * 5 — Weekend Shutdown: Stop at 8:00 PM on Friday
- 0 7 * * 1 — Weekend Startup: Start at 7:00 AM on Monday
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.