# Scheduling 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.

Source: https://zop.dev/integrations/aws/beanstalk-env/schedule
Updated: 2026-08-19

---

## 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.