Comparing CloudWatch Agent, SSM Agent, and Custom Daemon Scripts for Cloud Monitoring
CloudWatch agent, Systems Manager Agent (SSM Agent), and a custom monitoring process solve different parts of an AWS operations problem. Choosing among them starts with a specific data or management task: collecting host metrics, shipping application log files, executing managed-node actions, or reporting a signal that no existing collector can capture. Treating them as interchangeable can leave blind spots or create unnecessary privileges.
Choose the job before choosing an agent
The unified Amazon CloudWatch agent collects supported operating-system metrics and log files and publishes them to CloudWatch services. SSM Agent is the managed-node component that communicates with AWS Systems Manager so the service can run authorized actions and manage a node. A custom process is sometimes justified for a domain-specific health calculation, but then your team owns its failure handling, deployment, credential scope, buffering, and ongoing maintenance.
| Task | Appropriate starting point | Evidence to collect |
|---|---|---|
| Ship Nginx access/error logs | CloudWatch agent configured for the local files | Expected log events arrive in a named group and stream |
| Run approved maintenance on managed EC2 nodes | SSM Agent with a narrowly scoped Systems Manager action | Command association, authorization, and execution result |
| Measure memory/disk utilization not available in basic EC2 metrics | CloudWatch agent for required operating-system measurements | Known test workload changes the reported metric |
| Publish an application-specific queue age | Application instrumentation or a small supported collector | Known queue fixture produces the intended timestamped signal |
Avoid the retired SSM log-collection path
AWS documents that the old SSM Agent aws:cloudWatch plugin is not supported and recommends the unified CloudWatch agent for log collection. This is a concrete product distinction, not a reason to remove SSM Agent from managed nodes: SSM Agent still handles Systems Manager responsibilities. A migration may temporarily create a gap or duplicate log events, so verify collection before retiring the former path. The official AWS migration guidance explains the distinction.
Inspect the entire delivery chain
A running process is not proof of observability. Start at the producing application and follow one harmless test event through the local file, read permissions, collector configuration, endpoint/network path, AWS credentials and policies, target log group, and event timestamp. Compare what the collector says it sent with what CloudWatch Logs actually stores. A missing event may result from rotation or a wrong path rather than an IAM denial.
For a synthetic test, write a non-sensitive identifiable log line during a known time window. Check that line in the destination, confirm its timestamp and stream, then rotate the local log file and repeat. For metrics, change one harmless variable—such as a local CPU test under controlled load—and confirm aggregation dimensions and period are what you expect.
Security and cost boundaries
Give the collector only the destination permissions it needs; do not grant blanket administrative access to install a metrics agent. Inspect whether logs could contain session identifiers, authorization headers, customer payloads, or private file paths before forwarding them. Agree on retention and alarms as part of the setup. Excessive cardinality, redundant copies, and unexpectedly verbose logs can increase ingestion and storage costs.
Treat a custom daemon as production software: specify what happens during token rotation, network partitions, process restarts, and destination throttling. If AWS-managed telemetry covers the requirement already, avoid maintaining a duplicate data path.
A defensible choice
Use CloudWatch agent for host metrics and log shipping, SSM Agent for Systems Manager-managed operations, and application/custom instrumentation only for signals the managed tools cannot expose accurately. Validate the chosen system with a documented test event, not merely a successful installation screen.
The result should be a map from operational questions to a collection mechanism, an access boundary, and a verifiable observation. Those three facts are more useful than a generic ranking of agents.
- Category: All Certifications Cloud
- Tags: cloud, CloudWatch Agent, Monitoring, SSM Agent
