Auto Scaling groups that run without any scaling policy

An Auto Scaling group with nothing telling it to scale

An Auto Scaling group keeps a desired number of instances between a minimum and a maximum. It only changes that number when a scaling policy, a scheduled action or a person tells it to. The describe-policies reference lists four policy types: TargetTrackingScaling, StepScaling, SimpleScaling and PredictiveScaling. A group with none of them behaves like a fixed fleet: you pay for peak capacity around the clock, or you run short when traffic rises.

Finding groups with no policy

This loops over every group whose minimum and maximum differ and prints those with no policy:

for g in $(aws autoscaling describe-auto-scaling-groups \
    --query "AutoScalingGroups[?MinSize!=MaxSize].AutoScalingGroupName" --output text); do
  n=$(aws autoscaling describe-policies --auto-scaling-group-name "$g" \
      --query "length(ScalingPolicies)")
  [ "$n" = "0" ] && echo "$g"
done

When the finding fires

ZopNight counts the scaling policies attached to each group it discovered. The rule fires only when that count is known and equal to zero, and the group is not stopped. If the count was not collected, nothing is reported.

Two shapes where no policy is correct

Some groups are meant to have no policy, and the rule skips them:

• ECS capacity provider groups. When ECS manages a group it adds the AmazonECSManaged tag, and with managed scaling it creates and owns the target tracking policy itself; the ECS cluster auto scaling guide warns not to modify it. ZopNight treats a group carrying that marker as managed.
• Fixed-size groups. When the minimum equals the maximum, the group cannot scale whatever policy it has, so asking for one would be noise.

Both skips apply only when ZopNight has positively seen the marker; missing data never hides a finding.

A capacity-management gap, not a line item

The finding reports $0. The cost effect is real but indirect: a fleet sized for peak wastes money off-peak, and one sized for average fails under load. ZopNight’s remediation payload proposes a target tracking policy so the group can move in both directions.

Adding a target tracking policy

1. Open the group in the EC2 Auto Scaling console and choose the Automatic scaling tab.
2. Create a target tracking policy; 70% average CPU is a common starting point. From the CLI: aws autoscaling put-scaling-policy --auto-scaling-group-name GROUP --policy-name cpu70 --policy-type TargetTrackingScaling --target-tracking-configuration '{"PredefinedMetricSpecification":{"PredefinedMetricType":"ASGAverageCPUUtilization"},"TargetValue":70.0}'.
3. Use step scaling with CloudWatch alarms instead if the workload reacts better to a non-CPU signal.
4. Watch the group’s activity history to confirm it scales out and back in.