Scheduling Amazon EC2 Auto Scaling Group
autoscaling:UpdateAutoScalingGroupCan ZopNight schedule Amazon EC2 Auto Scaling Group?
An Auto Scaling group has no stop operation. ZopNight sets desired capacity to 0 and restores the previous value 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 desired capacity before scaling down and restores that number on start. If something changes desired capacity while the group is at zero, whether a deployment or a manual edit, the restore uses the value captured at stop time, not the newer one.
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.
Min size must allow zero
A group with MinSize greater than zero cannot scale to zero. The schedule adjusts desired
capacity, and the minimum overrides it, so a group with a minimum of 2 keeps two instances
running all night regardless.