Create an EC2 Auto Scaling Target Tracking Policy with ALB – SAP-C02 Study Guide

Purpose of This Lesson

This lesson demonstrates how to configure dynamic scaling for an Amazon EC2 Auto Scaling group behind an Application Load Balancer (ALB). The policy uses the ALBRequestCountPerTarget metric to add capacity when request volume per target rises and remove capacity more cautiously when demand falls.

The lab also highlights an important high-availability requirement: the Auto Scaling group and the load balancer should use compatible subnets across multiple Availability Zones.

Key Concepts

Auto Scaling capacity must have room to change

A dynamic scaling policy cannot provide useful elasticity when the Auto Scaling group has identical minimum, desired, and maximum capacities. For example:

• Minimum: 2
• Desired: 2
• Maximum: 2

The group has no ability to scale out. A more useful configuration might be:

• Minimum: 2
• Desired: 2
• Maximum: 4

The exact values depend on workload requirements, but the maximum must be greater than the desired capacity if scale-out is expected.

Spread the Auto Scaling group across Availability Zones

An Auto Scaling group should normally reference subnets in multiple Availability Zones. This allows instances to be distributed across independent failure domains and gives the group more placement options during scaling.

Adding Availability Zones to the Auto Scaling group is only part of the design. The ALB must also be enabled in subnets belonging to those Availability Zones. Otherwise, new instances may exist in zones that the load balancer cannot use effectively.

Target tracking with ALBRequestCountPerTarget

Target tracking automatically adjusts the desired capacity so a selected metric stays near a target value. For an ALB-backed application, ALBRequestCountPerTarget is often more relevant than average CPU utilization because it measures request volume received by each registered target.

A typical configuration is:

• Scaling policy type: Target tracking
• Metric: Application Load Balancer request count per target
• Target group: the group containing the Auto Scaling instances
• Target value: an application-specific request rate, such as 50

If the request rate per target remains above the target, the policy increases capacity. As new instances become healthy and are registered in the target group, traffic is redistributed across more targets and the per-target request rate should decrease.

The target value is not a universal performance limit. It must be selected through load testing and application observability. A request that is computationally expensive may require a much lower target than a simple static response.

CloudWatch alarms are created by the policy

A target tracking policy creates and manages CloudWatch alarms automatically. These alarms monitor the selected metric and initiate scaling activities when the metric deviates from the target.

Important operational characteristics include:

• The alarms may initially show INSUFFICIENT_DATA while metrics are being collected.
• Scale-out generally reacts more quickly than scale-in.
• Scale-in is intentionally conservative to reduce oscillation and avoid removing capacity during a brief demand spike or temporary metric fluctuation.
• Scaling is not instantaneous: an instance must launch, pass health checks, and register as healthy in the target group before it can serve traffic.

The exact evaluation periods, cooldown behavior, and alarm details are managed by the scaling policy and can vary with configuration and AWS implementation changes. Do not treat one lab’s alarm thresholds as universal defaults.

ALB health checks and target registration matter

A newly launched instance does not immediately receive production traffic. The normal sequence is:

1. EC2 launches the instance from the Auto Scaling group’s launch template or launch configuration.
2. The instance starts its application.
3. The instance registers with the target group.
4. The ALB health check succeeds.
5. The target becomes healthy and begins receiving requests.

This delay is why scaling policies should account for instance startup time. A policy that reacts faster than the application can initialize may launch additional instances before the first scaling action has had an opportunity to help.

Generating test load

For a basic lab, repeated HTTP requests to the ALB DNS name can produce enough traffic to test the policy. A command-line loop using curl can send requests from a local terminal or AWS CloudShell.

The test should be interpreted carefully:

• High request volume does not necessarily mean high CPU utilization.
• A simple webpage may generate many requests while consuming little compute capacity.
• Testing through the ALB validates the complete path: client, load balancer, target group, health checks, and Auto Scaling policy.

Exam-Relevant Takeaways

• Use target tracking when the requirement is to keep a workload metric near a desired level automatically.
• ALBRequestCountPerTarget is useful when scaling should follow request volume rather than instance CPU.
• The metric is associated with a specific ALB target group; selecting the correct target group is essential.
• The Auto Scaling group needs a maximum capacity above the current desired capacity to scale out.
• Configure the ALB and Auto Scaling group across multiple Availability Zones for resilience.
• A new instance must become healthy in the target group before it contributes to serving traffic.
• Target tracking policies create CloudWatch alarms automatically; manually duplicating those alarms can produce conflicting or redundant behavior.
• Scale-in is normally slower or more conservative than scale-out to protect availability and prevent thrashing.
• Request-based scaling can be a better fit than CPU-based scaling when request volume directly represents workload demand.
• Scaling policies change capacity; the ALB distributes traffic to healthy registered targets. They solve different problems and are commonly used together.

Architecture Decision Guide

Requirement	Suitable approach	Key consideration
Keep a metric near a desired value	Target tracking scaling	Simple operational model; AWS manages the associated alarms
Apply different capacity changes at different metric ranges	Step scaling	Useful when scaling urgency varies by breach magnitude
Use a basic one-action response to an alarm	Simple scaling	Less flexible; generally less preferred for modern dynamic workloads
Scale based on incoming web request volume	ALBRequestCountPerTarget	Requires an ALB target group and meaningful per-target request behavior
Scale based on compute saturation	Average CPU utilization	Appropriate when CPU is the primary bottleneck
Protect against an AZ failure	Multi-AZ Auto Scaling and ALB subnets	Both services must be configured to use the required Availability Zones
Avoid premature scale-in after a traffic spike	Conservative scale-in and stabilization	Preserve capacity until demand has clearly subsided
Validate a scaling configuration	CloudWatch metrics, alarms, ASG activity, and target health	Confirm both the scaling decision and the traffic-serving path

Common Exam Traps

• Changing only the Auto Scaling group subnets: Instances may launch in additional AZs, but the ALB will not necessarily use those zones unless its subnet mappings are also updated.
• Confusing request count with CPU utilization: A high request count can exist with low CPU usage, and CPU can be high with relatively few expensive requests.
• Expecting immediate scale-out: Launch time, application initialization, health checks, and target registration introduce delay.
• Assuming every launched instance receives traffic immediately: The ALB routes traffic only to healthy targets.
• Setting minimum, desired, and maximum to the same value: This prevents elasticity even if a scaling policy exists.
• Treating the target value as a hard request limit: Target tracking attempts to maintain an average, not enforce an absolute per-request ceiling.
• Expecting scale-in to mirror scale-out timing: Scale-in is deliberately cautious and may occur much later.
• Using test traffic as a production capacity benchmark: A curl loop may test request processing but may not reproduce realistic payloads, sessions, concurrency, or backend dependencies.
• Assuming ALB distribution means equal traffic at every instant: Distribution depends on target health, connection behavior, request patterns, and load balancer algorithms.

Real-World Engineer Notes

• Choose the scaling metric based on the actual bottleneck. For a CPU-heavy service, CPU utilization may be more predictive. For a web tier with relatively uniform requests, request count per target may be more useful.
• Establish the target value with load testing. Measure latency, error rate, saturation, and downstream limits—not just instance count.
• Account for warm-up time. If instances take several minutes to initialize, configure scaling behavior and capacity buffers so users are not exposed to the startup delay.
• Keep a baseline minimum capacity across multiple AZs. A minimum of two instances is not automatically resilient if both can be placed in one AZ or if the ALB is not enabled in the relevant zones.
• Monitor more than the policy metric. Useful signals include ALB TargetResponseTime, HTTP 5xx errors, rejected connections, target health, EC2 status checks, and downstream database or queue saturation.
• Consider predictive scaling or scheduled scaling when demand follows a known pattern. Reactive scaling is not always fast enough for highly predictable traffic surges.
• During lab cleanup, delete or scale down resources that incur charges, especially ALBs and running EC2 instances. Removing an Auto Scaling group normally terminates its instances, but connection draining and deregistration can delay termination.

Quick Reference Summary

• Configure the Auto Scaling group with a maximum capacity greater than desired capacity.
• Select subnets across multiple Availability Zones.
• Enable the ALB in the same intended Availability Zones.
• Create a target tracking policy using ALBRequestCountPerTarget when request volume is the right scaling signal.
• Select the correct target group.
• Expect CloudWatch alarms to begin in INSUFFICIENT_DATA until metrics are available.
• Generate traffic through the ALB, then inspect metrics, alarm state, Auto Scaling activity, and target health.
• Remember that scale-out and target registration take time; scale-in is intentionally more conservative.

Flashcards

1. Q: What must be true of an Auto Scaling group’s maximum capacity for dynamic scale-out to occur?

A: It must be greater than the current desired capacity.

1. Q: What does ALBRequestCountPerTarget measure?

A: The request volume handled per registered target in an ALB target group.

1. Q: When is request-count scaling preferable to CPU-based scaling?

A: When incoming request volume is a better indicator of capacity demand than CPU utilization.

1. Q: What AWS service distributes requests to the scaled instances?

A: The Application Load Balancer, through its target group.

1. Q: Why must ALB subnet mappings be updated when additional AZs are added to an Auto Scaling group?

A: The ALB must be enabled in those AZs to use targets there and maintain the intended multi-AZ design.

1. Q: What happens before a newly launched instance receives ALB traffic?

A: It must start its application, register with the target group, and pass the ALB health check.

1. Q: What does a target tracking policy create automatically?

A: CloudWatch alarms and the associated scaling actions needed to pursue the target metric.

1. Q: Why is scale-in usually slower than scale-out?

A: To avoid removing capacity during short-lived demand reductions and to prevent scaling oscillation.

1. Q: Does a high request count always imply high CPU utilization?

A: No. Lightweight requests can generate high request volume with little CPU consumption.

1. Q: What does INSUFFICIENT_DATA mean for a newly created scaling alarm?

A: The alarm does not yet have enough metric data to determine its state.

Practice Questions

Question 1

A web application runs on an EC2 Auto Scaling group behind an ALB. Requests are lightweight, but traffic varies significantly throughout the day. CPU utilization remains below 20% even during peak traffic. Which scaling metric is most appropriate for this workload?

A. Average CPU utilization
B. ALBRequestCountPerTarget
C. EBS burst balance
D. Network packets dropped by the NAT gateway

Correct answer: B. ALBRequestCountPerTarget

Explanation: CPU is not tracking demand for this workload. Request count per target is a more direct indicator of how much traffic each instance must handle, provided the target value is selected through testing.

Question 2

An engineer adds two Availability Zones to an Auto Scaling group’s subnet list but leaves the ALB enabled in only its original two Availability Zones. What is the primary design issue?

A. The Auto Scaling group cannot launch instances in the new zones.
B. The ALB cannot use its normal multi-AZ configuration to distribute traffic to targets in the new zones.
C. Target tracking is disabled automatically.
D. CloudWatch cannot collect metrics from the new instances.

Correct answer: B. The ALB cannot use its normal multi-AZ configuration to distribute traffic to targets in the new zones.

Explanation: The Auto Scaling group and ALB have separate subnet and AZ configuration. Both must be configured consistently for the intended resilient architecture.

Question 3

A target tracking policy changes to an alarm state after a traffic test, but the desired capacity increases and users do not immediately see traffic distributed to the new instances. What is the most likely explanation?

A. Target tracking never changes desired capacity.
B. The new instances must boot, pass health checks, and register as healthy targets.
C. ALBs route traffic only to the oldest instances.
D. The target group must be deleted and recreated after every scale-out.

Correct answer: B. The new instances must boot, pass health checks, and register as healthy targets.

Explanation: Scaling activity and traffic serving are separate stages. An instance becomes useful to the ALB only after it is healthy and registered in the target group.

Question 4

A team configures an Auto Scaling group with minimum, desired, and maximum capacity all set to 2, then creates a target tracking policy. During a load test, no additional instances launch. Why?

A. Target tracking supports only scale-in.
B. The ALB cannot forward traffic to Auto Scaling groups.
C. The group’s maximum capacity prevents scale-out.
D. CloudWatch alarms cannot monitor ALB metrics.

Correct answer: C. The group’s maximum capacity prevents scale-out.

Explanation: The scaling policy cannot exceed the group’s configured maximum. The maximum must be raised above the desired capacity before the group can add instances.

Question 5

A target tracking policy scales out during a brief spike and then immediately scales in as the spike ends. Which design adjustment best reduces this oscillation while preserving responsiveness?

A. Make scale-in more conservative through stabilization or cooldown behavior.
B. Remove the ALB health checks.
C. Set the maximum capacity equal to the minimum.
D. Disable CloudWatch alarms.

Correct answer: A. Make scale-in more conservative through stabilization or cooldown behavior.

Explanation: Scale-in should generally wait for sustained lower demand. Conservative scale-in behavior helps prevent capacity from being removed too soon after a transient spike.