# Amazon EC2 Auto Scaling Group

> An Auto Scaling group bills nothing itself. Every instance it keeps running bills the normal EC2 meter, so a group pinned at daytime capacity overnight wastes every off-hour. ZopNight sets min, max, and desired to 0 via autoscaling:UpdateAutoScalingGroup on stop and restores all 3 saved values at start.

Source: https://zop.dev/integrations/aws/asg
Updated: 2026-08-19

---

An Auto Scaling group maintains a fleet of EC2 instances at a configured size, scaling capacity up or down with demand. You pay for every instance the group keeps running, so groups left at daytime capacity overnight and on weekends quietly accumulate cost.

## The group multiplies the instance rate

An Auto Scaling group holds no meter of its own; its cost is the sum of its members' EC2 meters plus their EBS volumes. That makes group size the single cost input: a group holding 6 m5.large instances is six hourly meters, and minimum capacity is the floor under all of them; no scaling policy can take the group below it.

## Stop saves three numbers, not one

ZopNight parks a group by setting minimum, maximum, and desired capacity to zero via autoscaling:UpdateAutoScalingGroup, saving all three originals and restoring them together at start. Setting only desired would fail on groups whose minimum sits above zero, and restoring only desired would leave the scaling clamps wrong. The three values travel as a unit.

## Floor locks and missing policies

Two ASG-specific patterns recur. The floor lock: minimum capacity raised during an incident or a launch and never lowered, silently pinning the group above what demand needs, since scaling policies still exist but cannot act below the floor. And groups with no scaling policies at all, which are fixed-size fleets wearing an autoscaler's badge: they never scale down, so they behave like a row of always-on instances with extra steps.

## Native scheduled actions as an alternative

ZopNight's aws:asg autoscaler provider can manage capacity through the group's own scheduled actions instead of direct mutation; adopted native policies result in zero direct mutations, with the schedule living inside the ASG itself where operators expect to find it.

## Reading a group in the console

EC2 console, then Auto Scaling groups. The Details tab shows minimum, maximum, and desired side by side, and Activity history records every capacity change with its cause, which is where the origin of a floor lock is usually found.