Scheduling Amazon EC2 Auto Scaling Group
autoscaling:UpdateAutoScalingGroupCan ZopNight schedule Amazon EC2 Auto Scaling Group?
An Auto Scaling group has no stop operation. ZopNight saves minimum, maximum and desired capacity, sets all three to 0, and restores them on start, which terminates every instance in the group rather than stopping them. Anything on local disk is destroyed, and instances return as fresh instances with new IDs.
How the stop works
| Field | Value |
|---|---|
| Behaviour | group scaled to zero via autoscaling:UpdateAutoScalingGroup; original min, max, and desired capacity are saved 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
Scale to zero means terminate, not stop
This is the important difference from scheduling an individual EC2 instance. There is no stop here. Setting desired capacity to zero terminates every instance in the group.
The consequences follow from that:
- Instance store and local disk data is gone. A stopped instance preserves it; termination destroys it.
- Instances come back as new instances, with new IDs, new private IPs and a fresh boot from the launch template.
- EBS volumes created by the launch template are deleted if
DeleteOnTerminationis true, which is the default for root volumes.
That last point is what makes this a genuinely cheaper schedule than stopping instances: the volumes go away too, so you are not paying for disks overnight.
Anything stateful must not be in the group
If instances in the group hold state (a cache warmed at startup, uploaded files on local disk, a database), scaling to zero destroys it nightly. That is usually a sign the state belongs in EFS, S3 or a managed datastore rather than that the group should not be scheduled.
Restoring the previous capacity
The schedule records minimum, maximum and desired capacity before scaling down and restores all three on start. If something changes those values while the group is at zero, whether a deployment or a manual edit, the restore uses the values captured at stop time, not the newer ones.
Warm-up time is real
Scaling from zero means instances boot, pass health checks and register with the load balancer. For a group running a container platform or an application with a long startup, that is minutes, not seconds. Set the start earlier than the first request.
A non-zero minimum does not block the schedule
Because the schedule sets MinSize to 0 along with desired and maximum capacity, a group with a
minimum of 2 is still parked overnight, and its minimum of 2 comes back at start.