AWS Elastic Beanstalk Environment
Does ZopNight manage AWS Elastic Beanstalk Environment?
Elastic Beanstalk environments bill through what they orchestrate: the EC2 instances, load balancer, and Auto Scaling capacity underneath. A staging environment left up all week bills 168 hours for roughly 45 of use. ZopNight schedules environments off-hours by scaling the Auto Scaling group to zero via elasticbeanstalk:UpdateEnvironment.
Rules that fire on AWS Elastic Beanstalk Environment
No active rule family targets AWS Elastic Beanstalk Environment today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Stop verb | elasticbeanstalk:UpdateEnvironment |
| Scheduling notes | the environment's Auto Scaling group is scaled to zero via elasticbeanstalk:UpdateEnvironment and restored on start. |
Elastic Beanstalk deploys and manages web applications on top of EC2, Auto Scaling, and load balancers. The environment’s underlying instances bill continuously, so staging and QA environments left running around the clock carry real cost.
An orchestrator billed by its parts
Beanstalk adds no service charge; every dollar flows through the resources an environment stands up: EC2 instances in an Auto Scaling group, a load balancer in front, EBS volumes underneath, sometimes an RDS instance created alongside. That indirection hides the cost: the bill shows EC2 and ELB line items, not “the QA environment”, and teams reason about environments while the invoice speaks in parts. The environment’s instance count and size settings are the real meter controls, and they run 24/7 by default.
Off-hours scheduling for whole environments
ZopNight discovers Beanstalk environments automatically on the 6-hour cycle, attributes cost through the environment’s underlying EC2 and load-balancer resources, and collects hourly CloudWatch metrics. Environments are schedulable: on stop, the environment’s Auto Scaling group is scaled to zero through elasticbeanstalk:UpdateEnvironment, and the previous capacity settings are restored on start. The environment object, its configuration, and its URL survive the night. What disappears is the instance-hours, which for a weekday-only staging environment is roughly two-thirds of the week.
Beanstalk-shaped waste
Environment sprawl is the pattern: Beanstalk makes environments easy to create, so applications accumulate a review environment per branch, a load-test environment from last quarter, and an old production clone kept “for comparison”, each a full EC2-plus-ELB stack. Terminated applications leave orphan environments when cleanup happens at the application level but an environment was created outside it. And single-instance dev environments quietly graduate to load-balanced configurations, doubling their floor.
Seeing the real footprint
The Elastic Beanstalk console lists environments per application with health and tier; the environment’s Configuration page shows instance type and capacity range. The EC2 console tells the truer story: filtering instances by the environment’s tags shows exactly what the abstraction is running, and what a schedule would switch off.