Adopt Existing AWS Auto Scaling Policies Without Losing Them

An Auto Scaling group’s behaviour lives in three places: its capacity settings, its scaling policies and its scheduled actions. Any tool that manages scaling can overwrite all three. The first half of this guide saves them with the AWS CLI so you can always put the group back by hand; the second half covers the adopt-or-replace choice in ZopNight.

1. Save the capacity settings

aws autoscaling describe-auto-scaling-groups \
  --auto-scaling-group-names web-dev-asg \
  --query "AutoScalingGroups[0].{min:MinSize,max:MaxSize,desired:DesiredCapacity}" \
  > web-dev-asg.capacity.json

2. Save every scaling policy, by type

aws autoscaling describe-policies --auto-scaling-group-name web-dev-asg \
  > web-dev-asg.policies.json

aws autoscaling describe-policies --auto-scaling-group-name web-dev-asg \
  --policy-types PredictiveScaling StepScaling \
  --query "ScalingPolicies[].{name:PolicyName,type:PolicyType,steps:StepAdjustments}"

The four policy types are TargetTrackingScaling, StepScaling, SimpleScaling (the default) and PredictiveScaling. The second command tells you, before you open any wizard, whether the group has a predictive policy or a step policy with more than two steps. Those shapes matter in step 5.

3. Save scheduled actions

aws autoscaling describe-scheduled-actions --auto-scaling-group-name web-dev-asg \
  > web-dev-asg.scheduled-actions.json

Scheduled actions change min, max and desired capacity at set times, independently of the scaling policies, so they need their own backup.

4. ECS services use a different API

If the target is an ECS service rather than an EC2 group, its scaling lives in Application Auto Scaling:

aws application-autoscaling describe-scaling-policies \
  --service-namespace ecs --resource-id service/dev-cluster/orders-api
aws application-autoscaling describe-scheduled-actions \
  --service-namespace ecs --resource-id service/dev-cluster/orders-api

Permissions for all of the above are read-only: autoscaling:DescribeAutoScalingGroups, autoscaling:DescribePolicies, autoscaling:DescribeScheduledActions, plus the Application Auto Scaling describe actions for ECS. Keep the JSON files with the change ticket.

5. Adopt or replace in ZopNight

When the ZopNight autoscaler wizard opens on a group or ECS service that already has cloud-side policies, it shows them and makes you pick; it never silently overwrites them.

• Adopt records the existing policies as observed. Applying an adopted policy writes nothing to AWS; it only records the previous configuration. Removing it later also makes no AWS call.
• Replace hands scaling to ZopNight. On apply it describes the current policies, captures them in full, deletes them, and writes its own. Removing the ZopNight policy restores the captured originals.

Replace is refused, with no change made in AWS, for three shapes that cannot be rebuilt exactly: a PredictiveScaling policy, a StepScaling policy with more than two step adjustments, and a customised metric specification that uses metric math or more than one dimension. Policies with those shapes are shown as not editable; adopting them as they are is still possible.

Editing any field of an adopted policy converts it to a ZopNight-managed one in the same save, and the wizard tells you it needs a re-apply before the change takes effect. That is the moment AWS state actually changes, so check the saved JSON from steps 1 to 3 before you apply.

Verify

After an adopt, re-run step 2 and diff it against the saved file: it should be identical. After a replace, the same command shows the new policies; ECS policies written by ZopNight carry a zopnight-ecs- name prefix. If anything looks wrong, removing the policy in ZopNight restores the earlier configuration, and your JSON files are the manual fallback.

The autoscaler runs in monitor mode on read-only accounts; recommend and autopilot modes need read and write access. For how scaling interacts with off-hours scheduling, see the Auto Scaling group scheduling page, and for the policy types themselves, step scaling and predictive scaling.