Compute Optimizer reports that a retail web instance is oversized and recommends a smaller size. Memory metrics for the instance are already being collected. A teammate wants the resize done during the next business rush. When should that smaller size be applied?
Select an answer to reveal the explanation.
Short Explanation
You do not downsize the delivery truck in the middle of the route. Optimizer already called this instance oversized, and your memory metric is there to check, so apply the smaller size in a planned window after that check. The trap is resizing during the rush, or reading oversized as a cue to grow.
Full Explanation
Compute Optimizer recommends a smaller size when utilization shows the current type is larger than the workload needs. The memory metric is already being collected, so the safe sequence is to confirm that metric still has room at the smaller size and then apply the change in a planned window. Doing it during the rush stacks a resize on top of peak traffic. Reading an oversized finding as a request to move to a larger size inverts the recommendation. Converting the instance to a burstable type adds CPU credit behavior this web tier did not ask for and is not the smaller size Optimizer recommended. Changing the instance type of an EBS-backed instance stops and starts it, so connections drop even in a quiet window and the cutover still needs a short drain plan. Compare the memory metric's recent peak with the memory of the smaller size, apply the change in the window, and confirm the instance type afterward matches the size Optimizer recommended. Apply the smaller size Optimizer already recommended once the memory check agrees, rather than choosing a different type during the window.