A DevOps team runs a fleet of Amazon EC2 instances behind an Auto Scaling group and needs to alarm when an instance is short of available memory or when its root disk passes 85 percent used. The default Amazon EC2 metrics that Amazon CloudWatch publishes do not expose either value, and the team wants these metrics in CloudWatch with the least ongoing maintenance so existing CloudWatch alarms can act on them. Which approach should they implement?
- AWrite a cron job on each instance that reads memory and disk usage from the operating system and calls the CloudWatch PutMetricData API with custom metric values on a fixed schedule for every host.
- BInstall the Amazon CloudWatch agent on the instances and bake a unified agent configuration into the launch template so memory and disk metrics are published to CloudWatch as the group scales. Correct
- CEnable detailed monitoring on the Auto Scaling group so Amazon CloudWatch collects memory and disk metrics from each instance at one-minute resolution without any additional software on the hosts.
- DEnable AWS Compute Optimizer on the account so it analyses the Auto Scaling group and publishes the memory and disk utilisation of each instance into Amazon CloudWatch for alarming.
Why A is wrong: A hand-rolled cron and PutMetricData script does surface the values, but it is bespoke code the team must patch, secure, and maintain on every host, which is the high-maintenance path the requirement explicitly rules out.
Why B is correct: The CloudWatch agent is the managed way to collect guest-level memory and disk metrics, and shipping its configuration in the launch template means every scaled instance self-configures with no per-host code to maintain.
Why C is wrong: Detailed monitoring only raises the publishing frequency of the existing hypervisor-level EC2 metrics to one minute; it never adds guest memory or disk-usage metrics, which the hypervisor cannot observe.
Why D is wrong: Compute Optimizer produces right-sizing recommendations from historical data and does not stream live memory or disk metrics into CloudWatch, so no CloudWatch alarm could fire from its output.