AWS Cloud Monitoring, Explained Simply

AWS gives you a whole toolbox of monitoring and observability services, and when you're starting out they're easy to mix up. The trick that finally made them click for me was to stop memorizing definitions and instead ask what question each service answers about your environment. Here's the whole set, framed that way.

CloudWatch Metrics — "How is my resource performing?"

Every AWS service publishes metrics: CPU usage, network in/out, disk activity, and so on. A metric is simply a variable tracked over time. By default AWS gives you basic metrics, but you can enable detailed monitoring for more frequent data points, and you can push your own custom metrics too.

CloudWatch Alarms — "Tell me when something crosses a line."

Alarms watch a metric and trigger an action when a threshold is breached, for example CPU going above 80%. An alarm has three states: OK, ALARM, and INSUFFICIENT_DATA. When it fires, it can send a notification via SNS, trigger an Auto Scaling action, or stop, terminate, or reboot an EC2 instance.

CloudWatch Logs — "What did my application write down?"

This is centralized storage for log files coming from your applications, from EC2 (via the CloudWatch agent), from Lambda, and more. Logs are organized into log groups and log streams, and you can set retention policies so old logs expire instead of piling up forever.

EventBridge (formerly CloudWatch Events) — "React automatically when something happens."

EventBridge lets you schedule jobs cron-style or respond to events in your AWS account. You might say "when the IAM root user signs in, send me an alert," or "every hour, run this Lambda." Under the hood it's an event bus that routes events to targets like Lambda, SNS, or SQS.

CloudTrail — "Who did what, and when?"

CloudTrail records all API calls and account activity, giving you a full audit and governance history. If a resource gets deleted, CloudTrail is how you find out who did it. This is the service people most often confuse with CloudWatch, so hold onto this distinction: CloudTrail is the audit of API calls; CloudWatch is performance monitoring.

X-Ray — "Why is my distributed application slow or failing?"

X-Ray provides tracing and visual analysis for microservices. It helps you pinpoint performance bottlenecks and errors as a request travels across services, which makes it your go-to when debugging a distributed application.

AWS Health Dashboard — "Is AWS itself having problems?"

There are two flavors. The Service Health Dashboard shows the general public status of all AWS services across regions. The Personal Health Dashboard — now the "Your account health" view — shows alerts and remediation guidance for issues affecting your specific resources.

The mental model that ties it all together

• Need a metric or performance number → CloudWatch Metrics
• Need to be alerted on a threshold → CloudWatch Alarm
• Need application logs → CloudWatch Logs
• Need to react to events or schedule jobs → EventBridge
• Need to know who called which API → CloudTrail
• Need to debug a distributed app → X-Ray
• Need AWS service outage status → AWS Health Dashboard

The single most common trap is CloudTrail versus CloudWatch. Whenever you see it, remember: CloudTrail is the audit log of actions and API calls, while CloudWatch handles performance and logs.