Guest memory is a separate collection path
The metrics available from an EC2 instance's platform monitoring do not automatically provide every in-guest signal an operator needs. The CloudWatch agent can collect additional operating-system metrics such as appropriate memory and filesystem measurements. Installing the agent is only the first stage of that telemetry path.
This guide covers a deliberate memory and disk collection setup and diagnosis. It does not select universal alarm thresholds or assume the same metric definitions apply to Windows and Linux. Name the operational question first: available memory, a particular filesystem's utilization or another explicitly supported metric.
Setup: define the signal and publishing contract
Record the operating system, agent version, AWS Region, intended namespace and workload identity. Select the required metrics and collection intervals in the supported agent configuration. Review dimensions and filesystem selection so that ephemeral mounts or unexpected device names do not create misleading series or unnecessary cost.
For a Linux installation using the documented standard location, an illustrative status check is:
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
-m ec2 -a status
Use the procedure appropriate to the installed platform. Apply a reviewed configuration through the supported agent workflow and give the runtime identity only the required publishing access. Avoid introducing static AWS credentials when an appropriate managed identity path is available.
Illustrative incident: the chart queries the wrong series
In this fictional example, an agent publishes disk metrics successfully, but a dashboard built for an earlier instance dimension shows no data. Operators reinstall the agent repeatedly. The real disagreement is between the published metric identity and the chart's selected dimension set.
The team compares the applied configuration, actual metric namespace and dimensions in the intended Region. It verifies a fresh sample before editing alarm behavior. A process marked running did not establish that the dashboard was asking for the same metric.
Troubleshooting: follow collection, publishing and selection
| Observation | Evidence | Boundary |
|---|---|---|
| Agent does not start | Agent status, configuration validation and logs | Local configuration or installation |
| Agent runs but expected metric is absent | Applied collection settings and source availability | Does the agent collect this signal? |
| Publishing fails | Runtime identity, errors and endpoint path | Permission or connectivity |
| Metric exists but chart is empty | Region, namespace and exact dimensions | Consumer selection |
Use the metric definition for the OS and signal in question. For example, interpreting used memory requires understanding how the platform accounts for caches and available capacity. A metric name alone is not a complete definition of business risk.
Correct one stage without masking missing telemetry
Repair the evidenced configuration, identity, endpoint or chart selection. Confirm that the running agent actually loaded the intended configuration revision. A configuration file edited on disk is not proof that the active collector uses it.
Choose collection frequency and dimension cardinality deliberately, with retention and cost ownership. Do not turn a missing signal into a permanent non-breaching alarm state merely to remove an operational warning. Monitor collector health separately so the team can distinguish a healthy host from a blind monitoring path.
Verification, alerting and SOP
Verify timestamp freshness, expected dimensions and a plausible comparison with a local OS measurement. Test an approved signal change or controlled alarm exercise in a safe environment. Confirm the notification path independently of metric ingestion.
An internal SLO can define telemetry freshness for enrolled servers; it is distinct from the monitored application's SLA. The SOP should document OS-specific metric meaning, agent configuration ownership, namespace and dimensions, identity, endpoint access, collection cost, rollout and the evidence that both the collector and dashboard observe the same signal.
See Clouvenix observability monitoring for a reviewed implementation and operational handover.
Technical reference
AWS CloudWatch agent collection setup, AWS collected metric definitions, AWS agent troubleshooting. Reviewed 19 October 2026; use documentation for the installed product and release.