---
title: "Scale on usage"
description: "Set a TIR Auto Scaling Group to add and remove VMs by CPU, memory or network usage, with a target, a VM range and a scaling speed that suits your traffic."
content_type: "how-to"
product: "tir-auto-scaling"
platform: "TIR"
url: "/tir/tir-auto-scaling/how-to/scale-on-usage/"
topic: ["scale"]
---

# Scale on usage

A **Usage-based** Auto Scaling Group adds VMs when usage stays above the target you set, for example
when CPU utilization is high, and removes them when usage stays below it. The group always keeps between **Minimum VMs** and **Maximum VMs**.
Use this policy when your traffic is hard to predict. To change capacity at fixed times instead, see
[Scale on a schedule](/tir/tir-auto-scaling/how-to/scale-on-a-schedule/).

## Before you begin

- An Auto Scaling Group, or the **Create Auto Scaling Group** form open. See [Create an Auto Scaling
  Group](/tir/tir-auto-scaling/how-to/create-an-auto-scaling-group/).
- A usage level that one VM of your plan handles comfortably. You base the target on it.

## Choose the policy and the capacity range

The **Scaling** section is on the **Create Auto Scaling Group** form and on **Edit Auto Scaling
Group**. You can edit a group while it is running or stopped.

1. In **Scaling**, set **Minimum VMs** and **Maximum VMs**. They start at 2 and 5. The minimum can be 1 up to one less than the maximum, and the maximum can be at most 60.
2. Keep **Policy** on **Usage-based**, the default.

Left to itself, the group stays between **Minimum VMs** and **Maximum VMs**. A higher minimum
absorbs a sudden spike while new VMs boot. The maximum caps what the group can cost.

## Choose a metric and a target

Choose the metric to keep the group's average around, then the target for it.

| Metric                       | What the group watches                                                                                            | Target                         |
| ---------------------------- | ----------------------------------------------------------------------------------------------------------------- | ------------------------------ |
| **CPU utilization**          | The share of the VMs' vCPUs in use, over the last 2 minutes. This is the default.                                 | A percentage, 10 to 99         |
| **Memory utilization**       | The memory in use divided by the memory given to the VMs.                                                         | A percentage, 10 to 99         |
| **CPU + Memory utilization** | Both. The group adds VMs when either is over its target and removes them only when both are under.                | Two percentages, 10 to 99 each |
| **Network throughput**       | Bytes received plus bytes sent per second, averaged per VM, over the last 2 minutes. One MB/s is 1,000,000 bytes. | MB/s per VM, more than 0       |

The group averages the metric across all its VMs. The target
starts at 60, and for **CPU + Memory utilization** the memory target starts at 70. For **Network
throughput**, the target starts at 10 MB/s. Set the network target to what one VM handles comfortably, because the group adds capacity
once the average goes above it.

Each metric has one target, and that one target controls both adding and removing VMs.

## Choose how fast the group reacts

For a **Usage-based** group, **Scaling behavior** under **Advanced Settings** sets how long usage has
to stay past the target before the group acts. Pick a **Preset**:

| Preset                     | Use it for                                                       | Scale-out stabilization | Scale-in stabilization |
| -------------------------- | ---------------------------------------------------------------- | ----------------------- | ---------------------- |
| **Responsive**             | Sudden traffic spikes. It adds capacity fast.                    | 60 seconds              | 300 seconds            |
| **Balanced** (recommended) | A balance of stability and cost. This is the default.            | 150 seconds             | 600 seconds            |
| **Cost optimized**         | Fewer VMs for less of the time. It waits longer before changing. | 300 seconds             | 1,200 seconds          |

**Scale-out stabilization (seconds)** is how long usage must stay above the target before the group
adds VMs. It is at least 1. **Scale-in stabilization (seconds)** is how long usage must stay below the
target before the group removes VMs. It is at least 120, so that a new VM can finish booting. Any other pair of
numbers is a **Custom** preset.

## Check what the group will do

Before you save, read **How it will scale**. It sums up your choices in plain words, for example
"2 VMs to 5 VMs, targeting 60% CPU utilization", and says what the group does at each end.

Save with **Create Auto Scaling Group** or **Update Auto Scaling Group**. The change takes effect at
once on a running group.

Each time usage changes the group's size, **Scaling Activity** records how many VMs were added or
removed and why, such as "CPU utilization reached 72% (target 60%)." TIR also warns you when a group
changes size back and forth often, six or more times in 24 hours with three or more switches between
adding and removing, or reaches its maximum two or more times in 24 hours. Either is a sign to adjust
the target, the range, or the scaling behavior.

To add capacity at set times on top of this policy, see [Scale on a
schedule](/tir/tir-auto-scaling/how-to/scale-on-a-schedule/). To add VMs right now, see [Use Scale
Now](/tir/tir-auto-scaling/how-to/use-scale-now/). To replace VMs that stop responding, see [Set up
health checks](/tir/tir-auto-scaling/how-to/set-up-health-checks/).

For how the group decides when to add and remove VMs, see [How auto scaling
works](/tir/tir-auto-scaling/concepts/how-auto-scaling-works/).