AWS gives you building blocks, and each one reports its own health. Amazon CloudWatch collects basic metrics for most services by default, but it shows each resource on its own. Useful AWS monitoring connects those resource metrics with application performance, logs and user impact, so you can tell whether a CPU spike on an instance actually slowed down checkout.
What to monitor on AWS
| Service | Signals worth watching |
|---|---|
| EC2 | CPU utilization, CPU credit balance on burstable instances, network and disk I/O, status check failures. Memory and disk space need an agent. |
| RDS and Aurora | CPU, freeable memory, free storage space, read and write latency, database connections, replica lag, slow queries. |
| Lambda | Invocations, errors, duration, throttles, concurrent executions, cold starts. |
| Load balancers (ALB, NLB) | Request count, target response time, 5xx errors from the load balancer and from targets, healthy and unhealthy host counts. |
| SQS | Messages visible and age of the oldest message, which show a consumer falling behind. |
| DynamoDB | Consumed vs. provisioned capacity, throttled requests, latency. |
Where CloudWatch stops
- Gaps in default metrics. EC2 doesn't report memory or disk space without the CloudWatch agent, and basic monitoring samples every five minutes; one-minute detailed monitoring costs extra.
- Separate views. Tying a metric spike to the exact request and log line often means moving between CloudWatch metrics, CloudWatch Logs and X-Ray.
- Cost at scale. Custom metrics, log ingestion and metric API calls are billed, so monitoring costs grow with the estate.
- No application view. CloudWatch sees the instance or function, not which endpoint, query or user was slow.
Good practices
- Tag every resource with service, environment and team, so dashboards and alerts can be grouped the way you work.
- Alert on what users feel (error rate, latency) and use resource metrics to diagnose.
- Watch service quotas such as Lambda concurrency, which fail quietly until you hit them.
- Track spend next to performance, so scaling decisions use both.
AWS monitoring with Atatus
Atatus connects to AWS with a read-only IAM role and collects CloudWatch metrics without an agent, as part of infrastructure monitoring. Serverless monitoring tracks Lambda invocations, duration, errors and cold starts with distributed traces, database monitoring covers RDS and Aurora, and AWS CloudTrail, VPC Flow Logs and GuardDuty can feed security logs and SIEM. See AWS monitoring with Atatus and the serverless definition.