--- title: "TIR Auto Scaling Group FAQ" description: "Short answers about TIR Auto Scaling Groups, from what a group is built from to scaling, schedules, disks, public IPs, load balancers, billing, and access." content_type: "faq" product: "tir-auto-scaling" platform: "TIR" url: "/tir/tir-auto-scaling/faq/" --- # TIR Auto Scaling Group FAQ For fixes to a problem you are seeing, see [Troubleshooting TIR Auto Scaling Groups](/tir/tir-auto-scaling/troubleshooting/tir-auto-scaling/). ## Basics ### What is an Auto Scaling Group? An Auto Scaling Group runs a set of identical VMs and grows and shrinks automatically, between **Minimum VMs** and **Maximum VMs**. It is a resource of its own, with its own pages. The [TIR Auto Scaling Group overview](/tir/tir-auto-scaling/) describes the product. ### What is a group built from? A snapshot of one of your VMs. Every VM in the group is a copy of that snapshot, with the same operating system, packages, and files as when the snapshot was taken. Pick a VM on **Select Source**, and TIR takes the snapshot for you, or pick a snapshot you already have. See [Create an Auto Scaling Group](/tir/tir-auto-scaling/how-to/create-an-auto-scaling-group/). ### Can I build a group from an image? No. A group is built from a VM or from a snapshot of a VM. ### Does a group use GPU or CPU? CPU only. The create form shows CPU plans, and the source must be a CPU VM or a snapshot of one. Every VM in a group uses the one plan you choose at create, and the plan must be billed by the hour. ### Which regions can I use? You can use Delhi and Chennai. **Auto Scaling Groups** is in the side menu under **Compute**. ### Who can use Auto Scaling Groups? Anyone whose role grants the permission for Virtual Machines and Containers (Instances). Auto Scaling Groups use that same permission. You need create permission to create a group, update permission to change one, and delete permission to delete one. See [TIR Access Control](/tir/tir-iam/). ## Scaling ### How many VMs can a group have? From 1 to 60. **Minimum VMs** starts at 2 and **Maximum VMs** at 5, and the form needs a maximum at least one above the minimum. See [Scale on usage](/tir/tir-auto-scaling/how-to/scale-on-usage/). ### How does a group decide when to add or remove VMs? It follows its policy. A **Usage-based** group adds VMs when usage stays above your target and removes them when usage stays below it, always within **Minimum VMs** and **Maximum VMs**. A **Scheduled** group changes its capacity only at the times you set. See [How auto scaling works](/tir/tir-auto-scaling/concepts/how-auto-scaling-works/). ### What can a Usage-based group watch? **CPU utilization**, **Memory utilization**, **CPU + Memory utilization**, or **Network throughput**. The group measures the average across all its VMs. See [Scale on usage](/tir/tir-auto-scaling/how-to/scale-on-usage/). ### Can I use usage and a schedule together? Yes. Add schedules to a **Usage-based** group, and each schedule sets the minimum the group works above for its window. To combine them, keep the **Usage-based** policy and add schedules to it. See [Scale on a schedule](/tir/tir-auto-scaling/how-to/scale-on-a-schedule/). ### What time zone do schedules use? UTC. The **Runs at** time is a cron expression in UTC, so convert your local time to UTC when you enter it. TIR spells the time out in plain words, with the next run. See [Scale on a schedule](/tir/tir-auto-scaling/how-to/scale-on-a-schedule/). ### How long does a group wait before it adds or removes a VM? Usage has to stay past the target for the whole stabilization time. The **Balanced** preset, the default, waits 150 seconds before adding and 600 seconds before removing. **Responsive** waits 60 and 300 seconds, and **Cost optimized** waits 300 and 1,200 seconds. ### What is Scale Now? **Scale Now** asks a **Running** group to run a number of VMs right away. On a **Usage-based** group, a count above the saved minimum is temporary: the group holds it for a short time, then goes back to its own range. To keep a higher number, raise **Minimum VMs** from **Edit**. See [Use Scale Now](/tir/tir-auto-scaling/how-to/use-scale-now/). ### Can I change the plan of a group? No. The plan, the disk size, and the source snapshot are fixed when you create the group, because changing them would mean replacing every VM. You can change the name, the capacity, the policy, the schedules, and the health checks. To get a different plan, create a new group, for example with **Clone**. See [Edit an Auto Scaling Group](/tir/tir-auto-scaling/how-to/edit-an-auto-scaling-group/). ## Health and replacement ### What happens to a VM that is unhealthy? The group always watches for VM and host failures, and it replaces a VM that was running and then fails. You can also add an **HTTP** or **TCP** check of your own application. The group builds the new VM from the source snapshot. See [Set up health checks](/tir/tir-auto-scaling/how-to/set-up-health-checks/). ## Data and access ### What happens to the data on a VM when the group removes it? Treat it as lost. A new VM starts from the source snapshot, so data written on a VM after it started exists only on that VM. To keep data, store it outside the VM. See [How auto scaling works](/tir/tir-auto-scaling/concepts/how-auto-scaling-works/). ### Do changes I make on the source VM reach the group? No. Every VM is a copy of the snapshot as it was when taken. To use later changes, take a new snapshot and create a new group. ### What if I delete the source VM? The group keeps working. It holds its own copy of the plan, disk size, SSH keys, and source name, so **Retry Launch** still works too. **Clone** is available only while the snapshot itself exists. ### Does every VM get a public IP address? Yes. Every VM gets its own public IP address once it is ready, and the address is released when the VM is removed. A load balancer gives the group one shared address. See [Manage SSH keys and Security Groups](/tir/tir-auto-scaling/how-to/manage-ssh-keys-and-security-groups/). ### How do I sign in to a VM of the group? Use SSH as the root user with the VM's public IP address: `ssh root@`. The command is under **Connect** on **Overview**, and the group needs an SSH key and a Security Group that opens port 22. See [Manage SSH keys and Security Groups](/tir/tir-auto-scaling/how-to/manage-ssh-keys-and-security-groups/). ### Can I use a load balancer? Yes, a Web traffic (HTTP/HTTPS) load balancer. See [Connect a load balancer](/tir/tir-auto-scaling/how-to/connect-a-load-balancer/). ## Billing ### What does a group cost? Each VM is billed at the hourly price of the plan you chose, plus its disk above the first 30 GB. The cost follows the number of VMs the group runs. For prices, see [E2E Networks pricing](https://www.e2enetworks.com/pricing). The create and edit forms show an **Estimated cost** before you save. See [Billing for TIR Auto Scaling Groups](/tir/tir-auto-scaling/concepts/billing-options/). ### Is a VM billed while it starts? No. Compute is billed by the minute, and only from the moment the VM is ready until it is removed. ### Am I billed while a group is stopped? Compute billing for its VMs ends when you stop the group. Each VM's disk above the free 30 GB keeps billing while the group is stopped. See [Stop and start an Auto Scaling Group](/tir/tir-auto-scaling/how-to/stop-and-start-an-auto-scaling-group/). ### Who receives the bill? The owner of the project's team, even when another member created the group. ### Does deleting a group delete the source snapshot? No. Deleting a group terminates the group's VMs. The source snapshot, the source VM, the SSH keys, and the Security Groups stay. See [Delete an Auto Scaling Group](/tir/tir-auto-scaling/how-to/delete-an-auto-scaling-group/). ## Monitoring ### How do I see what the group did? Open the group's **Scaling Activity** tab. It lists every scaling change and configuration change, newest first, with the reason and who or what did it, and you can export the list as CSV or JSON. See [View scaling activity and logs](/tir/tir-auto-scaling/how-to/view-scaling-activity-and-logs/).