A web tier runs in an EC2 Auto Scaling group, and operators want the group to keep average CPU utilisation across the fleet close to 50 percent, adding or removing instances automatically as traffic rises and falls throughout the day. They want the simplest policy that maintains this set point without them defining individual thresholds for each capacity step. Which scaling policy meets this requirement with the least ongoing tuning?
- AA simple scaling policy that adds two instances whenever a CPU alarm breaches and then waits for a cooldown before evaluating again.
- BA step scaling policy with several CPU alarm bands that each add a different number of instances as utilisation climbs higher.
- CA scheduled scaling action that sets desired capacity higher during the day and lower at night based on the usual traffic curve.
- DA target tracking scaling policy on the average CPU utilisation metric with the target value set to 50 percent. Correct
Why A is wrong: Simple scaling reacts to one alarm with a fixed change and a blocking cooldown, so it cannot hold a continuous set point and needs the team to hand-tune the threshold and step.
Why B is wrong: Step scaling reacts faster than simple scaling but still forces operators to design and maintain every alarm band and step, which is exactly the per-threshold tuning they want to avoid.
Why C is wrong: Scheduled scaling changes capacity on a clock and is blind to the live CPU metric, so it cannot track an actual utilisation set point as traffic varies unpredictably.
Why D is correct: Target tracking creates and manages the CloudWatch alarms for you and adjusts capacity to hold the metric at the chosen set point, which is the lowest-effort way to keep CPU near 50 percent.