Collecting system-level metrics from EC2

The metrics EC2 publishes to CloudWatch by default are collected from outside the instance — CPU utilisation, network and EBS I/O, status checks. They do not include anything the hypervisor cannot observe, which means memory use, swap use and filesystem free space are absent. Alarms built only on default EC2 metrics will miss the exhaustion failures that most often take an instance down.

The CloudWatch agent closes the gap. Installed on the instance and granted a role that permits cloudwatch:PutMetricData, it publishes memory and swap utilisation, disk space by mount point, and process-level counters, alongside the log streams you configure it to ship. It runs on both Linux and Windows and is configured from a single JSON document, which can be held in Systems Manager Parameter Store and applied to a fleet.

Two practical points:

• Put the agent and its configuration into the AMI or the launch template’s user data, so every instance an Auto Scaling group creates reports the same metrics. An instance that launches without the agent looks healthy because it is silent.
• Custom metrics are billed per metric per Region. Publish the handful you will actually alarm on rather than the full default set across a large fleet.