Compute Optimizer and CloudWatch show an Auto Scaling group for a library catalog tier chronically underutilized on oversized instance types. Which rightsizing action is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
Paying for a moving van to haul a backpack is classic chronic underuse. Compute Optimizer plus CloudWatch are waving the receipt—shrink the instance type in the launch template and roll the group. Rightsizing is continuous improvement, not a one-time purchase order.
Full Explanation
Compute Optimizer and CloudWatch showing an Auto Scaling group for a library catalog tier chronically underutilized on oversized instance types call for rightsizing, not more capacity. Rightsizing to a more appropriate instance type or size—updating the launch template and rolling the ASG—based on Optimizer and utilization evidence reduces cost while preserving headroom. That action works because elastic fleets still waste municipal money when each member is larger than demand requires. Doubling the maximum group size without changing instance types fails by growing unused capacity further. Ignoring Optimizer because ASGs supposedly cannot change instance types after creation fails conceptually: launch templates are updated and instances refreshed or replaced. Pinning the group to the largest bare-metal instance available fails as the opposite of rightsizing. Exam caveat: validate memory and network needs under peak catalog search before shrinking; rightsizing below working-set memory creates latency regressions that erase savings. Operational check: apply Optimizer’s recommended type in a staging ASG, run peak search load, compare latency and cost, then rolling-update the production launch template with CloudWatch watchpoints during the change window.