A retail web tier runs on an EC2 Auto Scaling group behind an Application Load Balancer. Traffic doubles for an unpredictable hour around midday and falls away overnight, and the team wants capacity to track demand automatically so average CPU stays near a chosen value, while also tolerating the failure of a single Availability Zone. Which TWO actions together deliver this elastic and resilient behaviour with the least manual tuning? Select TWO.
- AAttach a target tracking scaling policy that keeps average CPU utilisation at the chosen value, letting the group add and remove instances as load moves. Correct
- BConfigure the Auto Scaling group across subnets in at least two Availability Zones so it can launch and balance instances in another zone if one fails. Correct
- CReplace the group with a fixed fleet of Reserved Instances sized for the midday peak so capacity is always present when traffic doubles.
- DAdd a simple scaling policy that adds one instance per alarm breach and waits out a cooldown before the next scaling action.
- EPlace all instances in a single Availability Zone inside a cluster placement group to reduce inter-instance latency during the peak.
Why A is correct: Target tracking adjusts capacity automatically to hold the metric near the target, so it tracks the midday surge without hand-set step thresholds.
Why B is correct: Spanning multiple Availability Zones lets the group keep healthy capacity running and rebalance when a zone is lost, giving the required resilience.
Why C is wrong: Reserved Instances discount steady baseline usage but a fixed peak-sized fleet does not scale in overnight, so it wastes capacity and is not elastic.
Why D is wrong: Simple scaling with a cooldown is tempting for reactive scaling but lags steep climbs and needs hand-tuned thresholds, unlike automatic target tracking.
Why E is wrong: A single-zone cluster placement group lowers latency but concentrates the fleet in one zone, so a zonal failure removes all capacity, breaking resilience.