Scheduling AWS Elastic Beanstalk Environment
elasticbeanstalk:UpdateEnvironmentCan ZopNight schedule AWS Elastic Beanstalk Environment?
Scheduling an Elastic Beanstalk environment scales its Auto Scaling group to zero through elasticbeanstalk:UpdateEnvironment, terminating every instance overnight. The environment and its URL stay up, but the load balancer keeps running and billing roughly $16-20 a month, and instances come back in the morning as fresh machines.
How the stop works
| Field | Value |
|---|---|
| Behaviour | the environment's Auto Scaling group is scaled to zero via elasticbeanstalk:UpdateEnvironment 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
UpdateEnvironment does the scaling
Beanstalk owns the Auto Scaling group it created, so the schedule goes through the front door:
elasticbeanstalk:UpdateEnvironment sets the capacity to zero at stop and writes the saved
min/max back at start. Editing the underlying group directly would be undone by Beanstalk, which
treats its managed resources as its own.
An empty environment still answers DNS
The environment is not terminated and its CNAME keeps resolving. The load balancer stays up with no healthy targets behind it, so overnight requests get 5xx responses from the balancer rather than connection failures. Health dashboards will show the environment as degraded, which is the expected shape of a scheduled night, not an incident.
The balancer is the residual charge
An Application Load Balancer bills by the hour whether it has zero targets or fifty. That is around $16-20 a month that the schedule does not touch. Single-instance environments have no balancer, so their scheduled cost genuinely reaches zero. That is worth knowing when choosing an environment type for a dev workload.
Environments fronted by a Network Load Balancer behave the same way; only the hourly rate differs. Check which balancer type the environment created before forecasting the saving.
Terminated, not stopped
Scaling an Auto Scaling group to zero terminates the instances. Anything written to local disk during the day is destroyed at the stop time, and the morning brings new instance IDs, new private IPs and a fresh deploy of the application version from Beanstalk’s own copy. If the app stores uploads or state on the instance, move that to S3 or EFS before scheduling.
Beanstalk’s own automation can collide
Two features deserve a check before the first scheduled night. Time-based scaling actions configured inside Beanstalk will fight an external schedule if both try to set capacity. And managed platform updates run in a maintenance window, and a window that falls inside the off-hours period finds zero instances to update and reschedules, which can leave environments on old platform versions longer than expected.