EC2 Has No Memory or Disk Alarms Until You Install the CloudWatch Agent

An EC2 instance can run at 40% CPU, healthy network throughput, and a passing status check right up to the moment a process gets OOM-killed or the root volume fills up and every write starts failing. None of the standard AWS/EC2 alarms would have shown a single warning sign — because none of them measure memory or disk usage in the first place. That's not a configuration mistake; it's how EC2 works by default, and most teams don't find out until the first outage it causes.

• What metrics does EC2 collect by default?
• Why doesn't EC2 report memory or disk usage on its own?
• What actually happens when nobody's watching memory and disk?
• How do you install the CloudWatch Agent on EC2?
• What should the CloudWatch Agent config.json look like?
• What alarms should you set on the new metrics?
• Does an audit tool catch this automatically?

What metrics does EC2 collect by default?

Out of the box, EC2 publishes CPU utilization, network in/out, EBS I/O, and instance/system status checks to the AWS/EC2 namespace — all hypervisor-visible, hardware-level signals. Nothing in that list touches memory usage or filesystem free space, because those live inside the guest operating system, which the hypervisor can't see into.

Why doesn't EC2 report memory or disk usage on its own?

The hypervisor sits below the guest OS and can measure what crosses the virtual hardware boundary — CPU cycles, network packets, disk I/O requests. It has no visibility into what's happening inside the OS itself: how much of that memory is actually in use versus cached, or how full a specific filesystem is. Getting those numbers requires an agent running inside the instance, reading them the same way `free` or `df` would.

That's exactly what the CloudWatch Agent is: a small process installed on the instance that reads OS-level stats (`/proc/meminfo`, `df`, and equivalents) and pushes them to CloudWatch as custom metrics under the CWAgent namespace — separate from the free AWS/EC2 namespace metrics, and billed accordingly.

What actually happens when nobody's watching memory and disk?

By the time StatusCheckFailed fires from a memory or disk problem, the failure has already happened — the metric only tells you the instance is now unreachable, not that it was heading there. Memory and disk alarms exist to catch the problem in the 15-30 minutes before that point, while there's still time to act.

This isn't hypothetical for EC2 specifically — AWS's own status-check documentation lists memory exhaustion and disk I/O errors as two of the direct causes of a failed instance status check: the OOM killer terminates critical OS processes, or a corrupted root volume forces the filesystem read-only. Both are preceded by a period of rising memory or disk usage that a CWAgent-based alarm would have caught, and both currently show as a completely clean CPUUtilization/NetworkIn/StatusCheckFailed dashboard right up until the moment they don't.

How do you install the CloudWatch Agent on EC2?

Four steps: attach the right IAM permissions, install the agent package, write a config file describing which metrics to collect, then start the agent pointed at that config. All four are one-time setup per instance (or per AMI/launch template, for fleets).

1. Attach the AWS-managed CloudWatchAgentServerPolicy to the instance's IAM role — this is what authorizes the agent to write metrics to CloudWatch.
2. Install the package: sudo yum install amazon-cloudwatch-agent on Amazon Linux 2/2023, or the equivalent apt/dpkg install on Ubuntu/Debian after adding the AWS package repo.
3. Save a config.json describing which metrics to collect (see the next section) — either as a local file or in SSM Parameter Store for fleet-wide rollout via Systems Manager.
4. Start the agent against that config with the amazon-cloudwatch-agent-ctl command, shown below.

What should the CloudWatch Agent config.json look like?

The minimum config to close the memory/disk gap is small — three metric categories (mem, disk, swap), each with a measurement array. The published metric name is the category and measurement joined together, so mem + used_percent becomes mem_used_percent in CloudWatch, and disk + used_percent becomes disk_used_percent.

{
  "agent": {
    "metrics_collection_interval": 60
  },
  "metrics": {
    "append_dimensions": {
      "InstanceId": "${aws:InstanceId}"
    },
    "metrics_collected": {
      "mem": {
        "measurement": ["used_percent"]
      },
      "disk": {
        "measurement": ["used_percent"],
        "resources": ["/"]
      },
      "swap": {
        "measurement": ["used_percent"]
      }
    }
  }
}

"resources": ["/"] scopes the disk metric to the root volume — add more mount paths to that array (or use ["*"] for every mounted filesystem) if the instance has separate data or log volumes worth tracking independently. Save this as /opt/aws/amazon-cloudwatch-agent/etc/cloudwatch-agent.json, then start the agent:

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config -m ec2 -s \
  -c file:/opt/aws/amazon-cloudwatch-agent/etc/cloudwatch-agent.json

The first datapoints typically appear under the CWAgent namespace in the CloudWatch console within one collection interval — 60 seconds with the config above.

What alarms should you set on the new metrics?

Once mem_used_percent, disk_used_percent, and swap_used_percent are flowing, the alarms themselves are ordinary CloudWatch alarms — same as any AWS/EC2 metric, just on the CWAgent namespace instead. A reasonable starting point for most general-purpose workloads:

Does an audit tool catch this automatically?

Not fully, and it's worth being direct about the limitation: Nuberio Audit checks whether your running EC2 instances have alarms on the standard AWS/EC2 namespace metrics — CPUUtilization, StatusCheckFailed, and the rest of the table above. It doesn't currently detect whether the CloudWatch Agent is installed or whether CWAgent-namespace memory/disk alarms exist, because that requires knowing the agent is running in the first place, not just reading CloudWatch's alarm list.

That's exactly the kind of gap worth checking by hand even after running an automated coverage tool — the standard-namespace alarms an audit finds tell you the instance is being watched at the hardware level; they don't tell you anything about what's happening inside the OS.