Cost-Effective Scaling — Target Tracking Policy Based on CPU Utilization

• A.Replace the existing instances with larger instance types to handle peak load.
• ✓ B.Implement a target tracking scaling policy based on average CPU utilization.
• C.Manually scale down the number of instances during off-peak hours.
• D.Purchase Reserved Instances for the baseline capacity.

Why B: Implementing a target tracking scaling policy based on average CPU utilization allows the Auto Scaling group to automatically scale the number of EC2 instances in response to demand. This ensures that during low traffic periods, the group reduces instance count to minimize costs, while during high traffic it adds instances to maintain performance. Option A is incorrect because using larger instance types would not reduce the number of running instances during low traffic and could increase costs. Option C is incorrect because manual scaling is not automated and may not respond quickly to traffic changes. Option D is incorrect because Reserved Instances provide a discount but do not address the issue of over-provisioning during low traffic; they lock in capacity that may still be unused.

• A.Purchase Reserved Instances for the current number of instances to reduce hourly cost.
• ✓ B.Implement an Auto Scaling group with a target tracking scaling policy based on ALB request count per target.
• C.Replace on-demand instances with Spot Instances for all traffic.
• D.Increase the instance size to a compute-optimized type to handle spikes.

Why B: Option B is correct because implementing an Auto Scaling group with a target tracking scaling policy based on ALB request count per target automatically adjusts the number of EC2 instances to match traffic patterns. During spikes, it adds instances to handle the load without performance degradation, and during low traffic, it reduces instances to optimize costs. Option A (Reserved Instances) lowers hourly cost but locks in a fixed capacity, which cannot handle variable traffic efficiently. Option C (Spot Instances) can be interrupted, risking performance degradation during spikes. Option D (increasing instance size) may handle spikes but is expensive and does not dynamically scale down.