Compute Optimizer shows no memory data for a university fleet, so the rightsizing view uses CPU only. The CloudWatch agent is not installed on those instances. What must happen before anyone trusts a rightsizing decision that depends on memory?
Select an answer to reveal the explanation.
Short Explanation
Judging a backpack by the books you can see leaves the bricks at the bottom. You have no memory data because the CloudWatch agent is absent, so install it and let memory metrics arrive before you trust a rightsizing call. The trap is resizing from CPU alone and calling it a memory decision.
Full Explanation
Compute Optimizer can judge memory only when memory metrics are published for the instances. For this fleet those metrics are absent because the CloudWatch agent is not installed, so a rightsizing call that depends on memory is not supported yet. Installing the agent and letting it publish memory metrics is what gives Optimizer the missing signal. Applying the CPU-only recommendation treats the gap as proof that memory is fine and can shrink a fleet that is actually memory bound. Disabling Compute Optimizer hides the empty column and does not create metrics. Moving the fleet to burstable instances changes how CPU credits work and still does not publish memory utilization. After the agent is installed, the next recommendation can still be based on the older CPU-heavy view until memory metrics have been ingested, so wait until the memory metric is visible before accepting a size. Graph the memory metric for a sample instance, then reopen Optimizer and only then accept a change that depends on memory.