A data analytics team runs a memory-intensive Java application on a fleet of EC2 instances across an AWS Organizations environment. AWS Compute Optimizer is enabled organisation-wide and recommends downsizing many of these instances to smaller types based on their low CPU usage. The team is worried that acting on these recommendations would trigger out-of-memory failures, because the workload is constrained by heap usage rather than processor time, and Compute Optimizer is not currently seeing any memory data. Which action BEST ensures the rightsizing recommendations protect performance for this memory-bound fleet?
- AInstall the CloudWatch agent to publish memory utilisation metrics and enable Compute Optimizer enhanced infrastructure metrics, so its recommendations account for memory before any instance is downsized. Correct
- BDisable Compute Optimizer for these accounts and instead rely on AWS Cost Explorer rightsizing recommendations, which always factor in application heap usage when proposing smaller EC2 instance types for Java workloads.
- CSet the Compute Optimizer CPU utilisation lookback window to the maximum length, on the assumption that a longer history of processor metrics alone is sufficient to reveal the memory pressure the workload is experiencing.
- DSwitch the instances to burstable T-family types and let CPU credits absorb demand, trusting that the burst model removes the need to measure memory utilisation before downsizing the fleet.
Why A is correct: Compute Optimizer only models memory when the CloudWatch agent supplies memory utilisation metrics and enhanced infrastructure metrics are enabled, so providing that data makes the recommendations memory-aware and prevents it from proposing instances too small for the heap.
Why B is wrong: Cost Explorer rightsizing suggestions are driven mainly by CPU and cost and do not ingest memory data either, so switching to them would suffer the same blind spot and still risk recommending instances that starve the heap.
Why C is wrong: A longer lookback period gathers more CPU history but never introduces memory data, so it cannot expose heap pressure and the recommendations would remain based only on the low CPU usage that is misleading here.
Why D is wrong: Burstable instances address short CPU spikes, not sustained memory demand, and moving a heap-constrained workload to a smaller burstable type would make out-of-memory failures more likely rather than protecting performance.