EC2 Target Tracking Scaling

Target Tracking Scaling is a policy type for Amazon EC2 Auto Scaling that automatically adjusts the desired capacity of an Auto Scaling group (ASG) to keep a specific CloudWatch metric at a target value. It is one of three dynamic scaling policy types (the others being Simple Scaling and Step Scaling), but it is the simplest to configure because you only need to specify the metric and the target value. AWS handles the logic of adding or removing instances proportionally.

Before Target Tracking, you had to create CloudWatch alarms and define scaling adjustments manually. For example, you might create an alarm for CPU > 70% that adds 2 instances, and another for CPU < 30% that removes 1 instance. This required careful tuning to avoid oscillations and wasted capacity. Target Tracking automates this: you set a target (e.g., average CPU at 50%), and AWS calculates the number of instances needed to maintain that target, scaling smoothly up or down.

Target Tracking uses a proportional-integral (PI) controller algorithm, similar to a thermostat. The algorithm continuously computes the required capacity based on the current metric value and the target. The formula is:

RequiredCapacity = (CurrentMetricValue / TargetMetricValue) * CurrentCapacity

For example, if target CPU is 50%, current CPU is 75%, and current capacity is 10 instances:

RequiredCapacity = (75 / 50) * 10 = 15

So the system would scale up to 15 instances. If CPU drops to 25%:

RequiredCapacity = (25 / 50) * 10 = 5

It would scale down to 5. However, the actual scaling decision also considers a stabilization period to avoid flapping.

- Target Metric: The metric you want to track. AWS provides predefined metrics: - ASGAverageCPUUtilization - ASGAverageNetworkIn - ASGAverageNetworkOut - ALBRequestCountPerTarget (requires ALB) - Target Value: The desired value for the metric. For CPU, a common target is 50%. - Disable Scale-In: By default, Target Tracking can both scale out and scale in. You can disable scale-in if you want to only scale out and manage scale-in separately (e.g., with a scheduled action). - Cooldown Period: Default is 300 seconds (5 minutes). This is the time after a scaling activity before another scaling activity can begin. It prevents rapid oscillations. - Scale-in Cooldown Period: Default is 300 seconds, but you can set it separately if needed. - Estimated Instance Warmup: Default is 300 seconds. This is the time after an instance starts before it is considered healthy and included in metrics. This prevents premature scale-in. - CloudWatch Alarm: Target Tracking automatically creates a CloudWatch alarm for the metric. This alarm has a period of 60 seconds (default) and a threshold based on the target value. You can view the alarm in the CloudWatch console.

You can configure Target Tracking via AWS Console, CLI, or CloudFormation. Example CLI command to create a scaling policy:

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name my-asg \
  --policy-name cpu-target \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration TargetValue=50.0,PredefinedMetricSpecification={PredefinedMetricType=ASGAverageCPUUtilization}

To verify, describe the policy:

aws autoscaling describe-policies --auto-scaling-group-name my-asg

Output will show the policy type, target value, and the automatically created alarms.

A typical e-commerce application uses Target Tracking with CPU target of 50%. During a flash sale, traffic spikes cause CPU to rise to 80%. The policy calculates required capacity as (80/50)*current, say 1.6 times. It scales out by adding instances. After cooldown, CPU drops to 40%, so it scales in. Without Target Tracking, you'd need to manually adjust alarms. With it, the system automatically handles load changes.

SAA-C03 tests your ability to choose the right scaling policy for a given scenario. Key points:

Common wrong answers:

Check scaling activities:

aws autoscaling describe-scaling-activities --auto-scaling-group-name my-asg

Check policy details:

aws autoscaling describe-policies --auto-scaling-group-name my-asg --policy-names cpu-target

View CloudWatch alarm:

aws cloudwatch describe-alarms --alarm-name-prefix "TargetTracking-my-asg"

Target Tracking Scaling is a powerful, easy-to-use dynamic scaling policy. It automates capacity management by maintaining a target metric value. Understand its components, defaults, and limitations to ace SAA-C03 questions.

A large e-commerce company runs its web tier on an Auto Scaling group behind an Application Load Balancer. Traffic varies throughout the day, with peaks during lunch and evening hours. They use Target Tracking with the ASGAverageCPUUtilization metric set to 50%. This ensures that during low traffic, instances are minimized to save costs, and during spikes, capacity automatically increases. The cooldown period is kept at default 300 seconds to prevent oscillations. They also enable scale-in protection for instances running critical batch jobs to avoid being terminated prematurely. In production, they observed that during sudden flash sales, CPU could spike to 90% momentarily, but the policy would quickly add instances, bringing CPU back to 50% within 2-3 minutes. Misconfiguration: initially they set the target too low (30%), causing over-provisioning and wasted cost. After adjusting to 50%, they achieved a balance.

A SaaS provider uses a microservices architecture where each service runs on its own ASG. For a service that processes API requests, they use Target Tracking with the ALBRequestCountPerTarget metric, targeting 2000 requests per instance. This ensures each instance handles a consistent load. They specify the ALB target group ARN in the policy. During a marketing campaign, request volume tripled. The policy scaled out from 10 to 30 instances within minutes. However, they noticed that during scale-in, instances were terminated even if they were still processing requests. They added lifecycle hooks to delay termination until in-flight requests complete. They also set a separate scale-in cooldown of 600 seconds to be more conservative. Common pitfall: forgetting to specify the target group ARN, which causes the policy to fail.

A financial services company runs batch processing jobs on EC2 instances. They use a custom metric that tracks the queue depth of a job queue. They publish this metric to CloudWatch every 60 seconds. They create a Target Tracking policy with a custom metric specification targeting a queue depth of 100. As jobs pile up, the metric increases, triggering scale-out. When the queue drains, scale-in reduces capacity. They set the estimated instance warmup to 600 seconds because batch jobs take longer to initialize. They also disable scale-in to avoid terminating instances that are still processing. Instead, they use a separate scheduled action to scale in during off-hours. This combination ensures that the processing capacity matches the workload without manual intervention. A mistake they made was using a metric with a period longer than 60 seconds, causing slow response. They switched to a 60-second period for faster reaction.