Edit an Auto Scaling Group

Edit an Auto Scaling Group to rename it, change how many VMs it runs, or change when and why it scales. The plan, the disk size and the source snapshot are fixed when you create the group.

Before you begin

• An Auto Scaling Group that is Running or Stopped. You can edit a Failed group from its row menu in Auto Scaling Groups.
• Permission to update VMs in the project. See TIR Access Control.

Change the group

1. In Auto Scaling Groups, open the row menu of the group and choose Edit. On the group’s details page, select Edit.
2. Make your changes and select Update Auto Scaling Group.

On a Running group, the changes take effect at once. If the save fails, TIR says why.

You can change:

• Auto Scaling Group Name. The name follows the same rules as at create.
• Scaling: Minimum VMs, Maximum VMs, the Policy and the schedules. The fields show the saved range, even when a schedule is holding a higher minimum. See Scale on usage and Scale on a schedule.
• Advanced settings: Scaling behavior and Health & recovery. See Set up health checks. Scale-in stabilization must be at least 120 seconds.

Use another plan, disk size, or source snapshot

The plan and the disk size are fixed because changing them would mean replacing every VM. To use another plan, disk size or source snapshot, create a new group. To start from this group’s settings, choose Clone in the row menu. The create form starts from the group’s settings, among them the snapshot, capacity, policy, health checks, SSH keys and security group, and with a new name. Clone is available while the group’s source snapshot exists. See Create an Auto Scaling Group.

You change SSH keys and security groups on the Network & Security tab of the details page. See Manage SSH keys and security groups.

Lower the maximum below the running count

Raising Minimum VMs above the number of VMs that are running adds VMs, and lowering Maximum VMs below it removes them. When the new maximum is below the running count, a Reduce capacity? dialog opens. It says how many VMs the group is running and how many the save will terminate, and that anything stored on those VMs’ disks is deleted with them. Tick “I understand and want to reduce capacity.” and select Save changes.

Maximum VMs must stay at least one more than Minimum VMs, and at least one more than the highest schedule’s VM count. When a schedule is what holds the maximum up, the form tells you which schedule to lower first.

A Scheduled group must keep at least one schedule. If you remove the last one, the form says “A scheduled group needs at least one schedule”. In a Usage-based group, removing all the schedules and saving deletes them.

When the change takes effect

• A Running group uses an edit at once.
• For a Stopped group, the scaling thresholds and policy apply at once. Anything that matters only to running VMs applies at the next Start.

Each edit is recorded in Scaling Activity as “Configuration updated”, with what changed, such as “CPU threshold changed from 60% to 70%”. See View scaling activity and logs.