Monitoring
This section covers the AWS services that answer three questions about a running system: is it healthy, what did it do, and where did a request spend its time.
Start with CloudWatch
for metrics and alarms, CloudWatch Logs
and Logs Insights
for log storage and querying, X-Ray
for distributed tracing, and CloudTrail
for the audit record of who called which API. The pages under observability/
cover the services that sit alongside these: managed Grafana and Prometheus,
OpenSearch, and Amazon Quick Sight.
The three pillars
Section titled “The three pillars”Metrics are numeric values measured over time — CPU utilisation, request latency, error rates, queue depth, business counters. They are cheap to store and aggregate, which makes them the right basis for alarms and dashboards. Amazon CloudWatch is the AWS metric store. CloudWatch also ingests OpenTelemetry metrics directly and supports PromQL-based alarms over them.
Logs are timestamped records of individual events. They carry far more detail than a metric and are the right tool for reconstructing what actually happened during an incident. CloudWatch Logs is the default destination; Amazon OpenSearch Service is the alternative when you need full-text search, long retention over large volumes, or an existing Elasticsearch-shaped workflow.
Traces follow a single request across service boundaries, recording where the time went and which dependency failed. AWS X-Ray is the trace backend. New instrumentation should be written against OpenTelemetry rather than the X-Ray SDKs — see the X-Ray page for why.
Two things sit slightly outside the three pillars but belong in the same conversation: CloudTrail, which is an audit record rather than a monitoring signal, and CloudWatch Application Signals, which discovers services and tracks them against service level objectives, correlating metrics, logs and traces for a given service in one view.
CloudWatch metric retention
Section titled “CloudWatch metric retention”CloudWatch keeps metric data at decreasing resolution as it ages, and rolls it up automatically:
| Period the data was published at | Retained for |
|---|---|
| Under 60 seconds (high-resolution custom metrics) | 3 hours |
| 60 seconds (1 minute) | 15 days |
| 300 seconds (5 minutes) | 63 days |
| 3,600 seconds (1 hour) | 455 days (15 months) |
Data published at a short period is aggregated for long-term storage rather than discarded: 1-minute data is still there after 15 days, but is only retrievable at 5-minute resolution, and after 63 days only at 1-hour resolution. A metric with no new data points expires after 15 months.
CloudWatch compared with CloudTrail
Section titled “CloudWatch compared with CloudTrail”The two are routinely confused because both produce records in an AWS account. CloudWatch tells you how a system is behaving; CloudTrail tells you who asked it to.
| Amazon CloudWatch | AWS CloudTrail | |
|---|---|---|
| Purpose | Monitoring and observability | Auditing and governance |
| Records | Metrics, logs, events | AWS API calls and account activity |
| Latency | Metrics in near real time | Log files published roughly every 5 minutes; delivery typically averages about 5 minutes after the call, and is not guaranteed |
| Retention | Metrics on the schedule above; log groups default to never expire and retention is set per log group | Event history holds 90 days of management events; trails and Lake event data stores retain for as long as you configure |
| Alarms | CloudWatch alarms on any metric | No alarms of its own; route through CloudWatch Logs, EventBridge or Security Hub |
| Visualisation | Dashboards, metric graphs, Logs Insights | CloudTrail Lake dashboards, or query the S3 data with Athena |
| Analysis | Metric math, anomaly detection, pattern analysis | SQL queries over Lake event data stores; CloudTrail Insights for unusual call-rate and error-rate patterns |
| Cross-account | CloudWatch cross-account observability links source accounts to a monitoring account | Organization trails and organization event data stores cover every account in the organization |
| Non-AWS input | Custom metrics and any log you ship | CloudTrail Lake channels can ingest activity events from outside AWS |
| Cost | Ingestion, storage, retrieval and queries | One copy of management events to S3 is free; data events, network activity events, Insights and Lake are charged |
Services that have been retired
Section titled “Services that have been retired”Two components that older AWS observability material still lists are gone or going, and a reader who arrives searching for them should find that out here:
- Amazon Lookout for Metrics has been retired: support ended on 10 October 2025, sign-ups had already closed, and AWS has withdrawn the developer guide. For anomaly detection on operational and business metrics AWS points at capabilities that already exist elsewhere — CloudWatch anomaly detection on the metric directly, OpenSearch Service, Redshift ML, Quick Sight, and AWS Glue Data Quality. Amazon DevOps Guru is also still generally available if you want the same “learn the baseline, tell me when it breaks” shape applied across a whole account.
- AWS App Mesh has been closed to new customers since 24 September 2024 and reaches end of support on 30 September 2026, after which the console and App Mesh resources become inaccessible. AWS points ECS workloads at Amazon ECS Service Connect and EKS workloads at Amazon VPC Lattice.