--- title: "Edit an Auto Scaling Group" description: "Change the name, size, scaling policy, schedules and health checks of a TIR Auto Scaling Group, and see what an edit does to the VMs that are running." content_type: "how-to" product: "tir-auto-scaling" platform: "TIR" url: "/tir/tir-auto-scaling/how-to/edit-an-auto-scaling-group/" topic: ["manage"] --- # 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](/tir/tir-iam/). ## 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](/tir/tir-auto-scaling/how-to/scale-on-usage/) and [Scale on a schedule](/tir/tir-auto-scaling/how-to/scale-on-a-schedule/). - **Advanced settings**: **Scaling behavior** and **Health & recovery**. See [Set up health checks](/tir/tir-auto-scaling/how-to/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](/tir/tir-auto-scaling/how-to/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](/tir/tir-auto-scaling/how-to/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](/tir/tir-auto-scaling/how-to/view-scaling-activity-and-logs/).