Target Tracking Scaling: How the Thermostat Model Works
Pick a metric, pick a number, and let the autoscaler hold it there. Here is what happens underneath.
Target tracking scaling is an autoscaling policy in which you choose one metric and a target value for it, and the autoscaler adds or removes capacity so the metric stays at or near that value. AWS describes it with a thermostat analogy: you set 50% average CPU, and the Auto Scaling group scales out when CPU rises above 50% and scales in when it falls below, without you defining any thresholds or step sizes.
What the provider does for you
On Amazon EC2 Auto Scaling, a target tracking policy creates and manages its own CloudWatch alarms. AWS tells you not to create, edit, or delete those alarms, because the service may replace them as it tunes the policy. That is the main operational difference from step scaling, where you own the alarms and the step table.
EC2 Auto Scaling supports four predefined metrics:
ASGAverageCPUUtilization: average CPU of the group.ASGAverageNetworkInandASGAverageNetworkOut: average bytes received or sent per instance.ALBRequestCountPerTarget: average Application Load Balancer requests per target.
You can also track custom CloudWatch metrics, including high-resolution metrics published every few seconds for faster reaction, and use metric math to reshape a metric first.
Google Cloud’s managed instance group autoscaler works the same way by default. You set a target utilization (for example 75% CPU), and the autoscaler keeps the group at or close to it. It can track average CPU, HTTP load balancing serving capacity, or Cloud Monitoring metrics. Amazon ECS services use the same model through Application Auto Scaling, with CPU and memory metrics that ECS publishes to CloudWatch at one-minute intervals.
Choosing a good metric
Target tracking assumes that adding capacity pushes the metric down proportionally. AWS says the metric should decrease when capacity increases and increase when capacity decreases. Average CPU and requests per target behave that way. Queue age, error rate, or total requests across the whole fleet usually do not, and are better handled by step scaling or by converting them into a per-instance figure.
Two data-quality details matter. If the metric stops reporting, the CloudWatch alarm goes to INSUFFICIENT_DATA and EC2 Auto Scaling cannot scale until data returns; for sparse metrics AWS suggests metric math such as FILL(m1,REPEAT). And for metrics published by EC2 itself, such as CPU, AWS recommends enabling detailed monitoring.
Why the actual value misses the target
You will see gaps between the target and reality, especially in small groups. EC2 Auto Scaling rounds conservatively: if 1.5 instances would bring CPU back to 50%, it cannot launch half an instance, so it rounds in the direction that avoids under-provisioning. It also prioritises availability during fluctuating traffic by scaling in more gradually than it scales out.
Scale-in is also blocked while a scale-out is in progress, until the new instances finish their warmup. If you need a floor during deployments, you can temporarily disable the scale-in portion of the policy. On Google Cloud, the autoscaler sizes the group for the peak load observed over a stabilization period before scaling in, so capacity comes down gradually after a spike.
Picking the number
A lower target buys headroom for sudden bursts and costs more instance-hours; a higher target runs hotter and cheaper but leaves less slack while new instances boot. The right value depends on how long your instances take to become useful, which is why warmup and initialization settings should be measured rather than guessed. Google defines its initialization period as the time it takes for applications to initialize on a new VM, because usage data from a VM that is still initializing might not reflect normal load.
ZopNight’s autoscaler recommendations flag Azure scale set targets set above 90% or below 30%, and its smart defaults suggest min, max, and target values from the resource’s own CPU statistics, including P90, P95, and P99. For how target tracking compares with the other policy types, see autoscaling fundamentals, and for group-level scaling on AWS see Auto Scaling groups.