How auto scaling works

A TIR Auto Scaling Group keeps a set of identical VMs and changes how many run. It has one plan, one disk size for each VM, one set of SSH keys, one Security Group, and one scaling policy, and all of them apply to every VM in the group.

Usage-based and Scheduled scaling

The Policy setting offers two choices, and Usage-based is the default.

• Usage-based adds and removes VMs on its own, based on real-time usage. You pick a metric: CPU utilization, Memory utilization, CPU + Memory utilization, or Network throughput, and a target. The group adds VMs when usage stays above the target and removes them when it stays below. The group measures the metric as an average across all its VMs, including VMs that are still starting. For CPU + Memory utilization, the group adds VMs when either metric is over its target and removes them only when both are under.
• Scheduled changes capacity only at the times you set, whatever the usage. Each run sets the number of VMs to the schedule’s count exactly, up or down.

You can also add schedules to a Usage-based group. The group is then shown as “Usage-based · CPU utilization + Scheduled”, with the metric you chose. A schedule sets the minimum for a chosen time, and usage scaling works above it. When the time comes, the group raises the VM count at once if it is below the new minimum, and usage scaling handles any decrease. Schedule times are in UTC. When several schedules hold at the same moment, the highest minimum wins. See Scale on usage and Scale on a schedule.

Minimum, maximum, and the starting number

Minimum VMs is the fewest VMs the group runs, and Maximum VMs is the most it runs. The minimum is at least 1. The maximum is at most 60 and at least one more than the minimum. The defaults are 2 and 5.

A new group starts with the number of VMs set in Minimum VMs. A higher minimum helps with a sudden spike, because the VMs are already running while new ones boot. A lower maximum caps what the group can cost. If you lower Maximum VMs below the number now running, the group removes the extra VMs.

Stabilization: how long the group waits

Stabilization is the wait, in seconds, before the group changes its size. Scaling behavior, under Advanced Settings, has two numbers. Scale-out stabilization is how long usage has to stay above the target before the group adds capacity. Scale-in stabilization is how long usage has to stay below the target before the group removes VMs. Only Usage-based groups have these two settings.

A preset sets both at once:

Preset	Scale-out stabilization	Scale-in stabilization	Use it when
Responsive	60 seconds	300 seconds	Traffic has sudden spikes and the group must add fast.
Balanced	150 seconds	600 seconds	You want stability and cost in balance. This is the default.
Cost optimized	300 seconds	1,200 seconds	You prefer to run fewer VMs and accept a longer wait.

Any other pair of numbers is a Custom preset. Scale-in stabilization has to be at least 120 seconds. While the group waits to remove VMs, its State is Cooling down.

Scale Now and its hold

Scale Now asks a Running group to run a number of VMs right away. The number stays between the group’s minimum and maximum. On a Usage-based group, a number above the saved minimum is temporary. The group holds it for a short time. After that, the group goes back to its own range. It removes the extra VMs if usage is below the target, and keeps them if usage is still above it. To keep more VMs for good, raise Minimum VMs from Edit. See Use Scale Now.

How a group replaces an unhealthy VM

Infrastructure health checks are always on. The group detects VM and host failures, and it replaces an unhealthy VM so that the group keeps its size. You can add an Application health check that is HTTP or TCP. The default is VM status only, where a VM counts as healthy when it reports ready.

• With an HTTP or TCP check, a VM has to fail the Unhealthy after number of checks in a row before the group replaces it.
• The group ignores health checks while a new VM is starting, so a slow application has time to start before any replacement. For an HTTP or TCP check, you set how long to ignore them with the question “How long does your app take to start?”, and the default is 5 minutes.
• A VM that passed a check and then failed is replaced.

The group builds the new VM from the source snapshot, so the new VM starts with only what the snapshot holds. Scaling Activity records “Replaced an unhealthy VM” with the reason. See Set up health checks.

What each VM keeps

Every VM is a copy of the source snapshot, with the disk contents, installed software, and files that the source VM had when the snapshot was taken. Changes you make on the source VM later stay on the source VM. The group keeps its own copy of the plan, disk size, SSH keys, and source name, so it keeps working after the source VM is deleted.

Each VM has its own disk, made as a copy of the snapshot. Disk per VM starts at 30 GB, or at the disk size of the source snapshot if that is larger, and it is fixed when you create the group. A new VM starts from the source snapshot, so keep data that has to last somewhere else.

Public IP addresses

Every VM in a group gets its own public IP address once it is ready. A public IP address is released when the VM is removed. Each VM also has a private IP address. The Security Group has to open port 22 for the SSH keys to work. To give clients one shared address for the whole group, see Connect a load balancer. To manage keys and Security Groups, see Manage SSH keys and security groups.

For the charges of a group, see Billing for TIR Auto Scaling Groups.