Scheduling Amazon EKS Node Group
eks:UpdateNodegroupConfigCan ZopNight schedule Amazon EKS Node Group?
Node group schedules save the group's minimum, maximum and desired sizes as tags on the node group, call eks:UpdateNodegroupConfig to scale it to zero, and restore all three at start. The group's minimum does not need changing first. Evicted pods wait as Pending, and deleting the tags 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.
The minimum is handled for you
EKS requires the minimum to sit at or below the desired size, so lowering only the desired size fails on a group whose minimum is 1 or higher. ZopNight therefore saves all three sizes and sets the whole scaling configuration to zero at stop, then writes the saved values back at start. No change to the group’s minimum is needed before enabling the schedule.
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.