EC2 Auto Scaling Calculator

Compute the desired Auto Scaling capacity from a target-tracking policy and see how long a full scale-out takes.

About EC2 Auto Scaling Calculator

Target tracking behaves like a thermostat: it solves for the instance count that puts the chosen metric back on its set point, which is load divided by the usable capacity per instance. The scale-out time matters just as much — each activity adds a step of instances and then waits out the warm-up before the next evaluation, so a large gap between minimum and desired is crossed in several slow rounds rather than one jump. Setting a target too high leaves no absorption for the warm-up window, so traffic that arrives faster than instances boot causes errors even though the policy is technically correct.

Formula

EC2 Auto Scaling

desired = ceil(load ÷ (capacity per instance × target utilisation)), clamped to the group's minimum and maximum.

target: Target-tracking set point, e.g. 70% of instance capacity
capacity per instance: Throughput one instance sustains at 100%
warmup: Seconds before a new instance counts toward capacity

Worked example

With the default values below, EC2 Auto Scaling Calculator returns Desired Capacity of 18. Change any input above and every figure here is recalculated in your browser.

Inputs used

Offered loadaccepts 0–10,000,000 requests/s: 4,800 requests/s
Capacity of one instance at 100%accepts 1–1,000,000 requests/s: 400 requests/s
Target tracking utilisationaccepts 10–100 %: 70 %
Minimum group sizeaccepts 0–10,000 instances: 2 instances
Maximum group sizeaccepts 1–10,000 instances: 20 instances
Instance warm-upaccepts 0–3,600 seconds: 180 seconds
Instances added per scaling activityaccepts 1–1,000 instances: 2 instances

Results

Desired Capacity: 18
Usable Capacity per Instance: 280 requests/s
Spare Capacity at Desired Size: 2,400 requests/s
Utilisation at Desired Size: 66.7%
Time to Reach Desired Size: 1,920 seconds
Maximum Size Check: The maximum size has room above the desired capacity

Step by step

1Values used
2EC2 Auto Scaling
3Desired Capacity= 18
4Usable Capacity per Instance= 280 requests/s
5Spare Capacity at Desired Size= 2,400 requests/s
6Utilisation at Desired Size= 66.7
7Time to Reach Desired Size= 1,920 seconds
8Maximum Size Check= The maximum size has room above the desired capacity

Assumptions and limits

The result is derived only from the 7 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax or compounding frequency into account.
Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

How is EC2 Auto Scaling calculated?

desired = ceil(load ÷ (capacity per instance × target utilisation)), clamped to the group's minimum and maximum. Target tracking behaves like a thermostat: it solves for the instance count that puts the chosen metric back on its set point, which is load divided by the usable capacity per instance. The scale-out time matters just as much — each activity adds a step of instances and then waits out the warm-up before the next evaluation, so a large gap between minimum and desired is crossed in several slow rounds rather than one jump.

Why does EC2 Auto Scaling matter?

Setting a target too high leaves no absorption for the warm-up window, so traffic that arrives faster than instances boot causes errors even though the policy is technically correct.

What values do I need to enter?

This calculator takes 7 inputs: Offered load, Capacity of one instance at 100%, Target tracking utilisation, Minimum group size, Maximum group size, Instance warm-up, Instances added per scaling activity. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Why add 60 seconds per scaling round?

CloudWatch alarms for target tracking evaluate on one-minute metrics, so even after the warm-up expires the group waits for the next evaluation period before it acts again. The extra minute approximates that detection lag.