An ALB distributes load evenly across an EC2 Auto Scaling group. CPU reflects demand, one-minute detailed monitoring is enabled, and instance warmup is configured.
Increase and decrease capacity within the group's limits to move average CPU near 50%. AWS should also manage the alarms evaluating deviations. Exact, continuous 50% utilization is not required.
Which policy is most appropriate?
Use ASGAverageCPUUtilization target tracking at 50 to adjust capacity within the group's limits toward the CPU target.
Detailed explanation
Scale-out alone does not meet both directions of adjustment and differs from target-tracking alarm management.
Scale-out alone does not meet both directions of adjustment and differs from target-tracking alarm management.
Auto Scaling adjusts capacity toward average CPU utilization and creates and manages the associated alarms.
Auto Scaling adjusts capacity toward average CPU utilization and creates and manages the associated alarms.
A fixed capacity range prevents count changes; a target cannot override those limits.
A fixed capacity range prevents count changes; a target cannot override those limits.
Time-based capacity changes alone do not track unpredictable measured CPU demand toward the target.
Time-based capacity changes alone do not track unpredictable measured CPU demand toward the target.
Check official documentation
Compare the following points with the official documentation.
Review the predefined CPU metric, managed alarms, warmup, missing data, and capacity rounding.
Official references
What to confirm
Distinguish target tracking from step/scheduled scaling and explain why exact continuous 50% is not guaranteed.
Key points
- Target tracking
- ASGAverageCPUUtilization
- Instance warmup
Notes
- Environment: AWS SOA-C03 exam guide and the linked AWS documentation
- Reviewed against the linked AWS documentation on 2026-10-04.
Foundation review
Track observed utilization toward a target
ASGAverageCPUUtilization measures group-average CPU. With evenly distributed load, target tracking adds capacity above the target and scales in gradually when safe. Auto Scaling manages the associated CloudWatch alarms; do not edit them manually. Scheduled scaling uses time-based counts instead of the same feedback decision.
Check adjustment limits operationally
Capacity bounds, integer instance counts, and startup time cause deviations from the target. Check warmup behavior and missing data leading to INSUFFICIENT_DATA. If CPU stays high at maximum capacity, investigate capacity or application constraints rather than assuming the policy can always restore 50%.