Amazon CloudWatch

Amazon CloudWatch review details

This Amazon CloudWatch review covers AWS's native observability service for data engineers, DevOps teams, and SREs running workloads on AWS. CloudWatch is the default monitoring layer for every AWS account — metrics, logs, events, and alarms for EC2, Lambda, RDS, S3, and nearly every other AWS resource, plus custom metrics for your own applications. We evaluated it against the observability stack most data teams actually assemble (Datadog, New Relic, Grafana, Prometheus) to answer the real question: when is CloudWatch enough on its own, and when does it need help?

Overview

Amazon CloudWatch is AWS's built-in observability service, sitting at the foundation of the Observability & Monitoring category. It ingests metrics from AWS resources automatically, accepts custom metrics over an API, stores application and infrastructure logs, and triggers alarms and automated responses. Most teams running on AWS already have CloudWatch configured whether they realized it or not — every Lambda invocation, every RDS instance, every ELB writes to it by default.

The service matters because it's the fastest and lowest-friction way to get observability on AWS. There's no agent to deploy for AWS-native metrics, no separate billing relationship, and IAM controls apply out of the box. For a team starting on AWS, CloudWatch is the default — the question is whether you stay with it as you scale. Amazon positions CloudWatch as a monitoring service for DevOps engineers, developers, SREs, IT managers, and product owners; in practice it lands hardest with the first three groups.

Key Features and Architecture

CloudWatch organizes its capabilities around four primitives: metrics, logs, events, and alarms. AWS services push metrics and logs in automatically; for workloads outside AWS or for custom application telemetry, you push via the CloudWatch Agent or the PutMetricData / PutLogEvents APIs.

The feature set beyond the primitives is where CloudWatch has matured. Container Insights gives you deep visibility into ECS, EKS, and Fargate — pod-level CPU, memory, and network without deploying a sidecar. Application Insights auto-discovers the components of a running application (RDS, ELB, EC2) and configures monitoring automatically. Cross-account observability lets a monitoring account aggregate metrics and logs from many linked AWS accounts — important for any org with an AWS Organizations structure. Composite alarms combine multiple metric alarms with AND/OR logic so you alert on meaningful conditions, not noisy individual metrics. Metric Streams pushes metrics into Kinesis Data Firehose for near-real-time forwarding to a third-party backend — useful when you want to centralize data in Datadog or Splunk while keeping CloudWatch as the collection layer.

Log and metric correlation is built in through CloudWatch Logs Insights — a SQL-like query language for log search plus the ability to derive metrics from log patterns. For AWS-native workloads this is the fastest path from "something broke" to "here's the line that caused it." The flip side: Logs Insights queries are charged per GB scanned, so ad-hoc exploration on high-volume logs can get expensive fast.

Ideal Use Cases

Best for:

• AWS-centric data teams and SRE organizations running EC2, Lambda, RDS, ECS, or EKS as their primary platform. CloudWatch captures the default metrics every team needs with zero configuration.
• Teams of any size on AWS Organizations using cross-account observability to consolidate monitoring into a central account.
• Data pipeline teams using Glue, EMR, Redshift, or Kinesis — CloudWatch metrics plus Logs Insights cover pipeline health without additional tooling.
• Cost-sensitive early-stage teams that want real observability without a separate vendor contract. The free tier and pay-per-use model are genuinely usable for small workloads.

Not suitable for:

• Multi-cloud or hybrid teams running significant workloads outside AWS. CloudWatch can ingest external metrics but it's awkward and you lose the zero-config advantage that's the whole point.
• Teams wanting polished APM or distributed tracing as a primary workflow — CloudWatch has ServiceLens and integrates with X-Ray, but purpose-built APM tools (Datadog, New Relic, Dynatrace) have more mature tracing UIs.
• Organizations with heavy SIEM or security-analytics needs. CloudWatch Logs works, but Splunk or a dedicated SIEM handles correlation, retention, and compliance workflows better.

Pricing and Licensing

CloudWatch has a free tier and a pay-for-what-you-use model: AWS states there is no up-front commitment or minimum fee, and usage is charged at the end of the month. Pricing varies by Region; AWS provides a Pricing Calculator for estimating monthly costs.

The free tier includes 5 GB of CloudWatch Logs data across ingestion, archive storage, and data scanned by Logs Insights queries; 1,800 minutes of Live Tail usage per month; 10 custom or detailed-monitoring metrics; 1 million API requests, excluding GetMetricData, GetInsightRuleReport, and GetMetricWidgetImage; three custom dashboards referencing up to 50 metrics each per month; and 10 standard-resolution alarm metrics that list metrics directly and do not use a Metrics Insights query.

For classic CloudWatch metrics, charges are prorated by the hour and occur only when metrics are sent to CloudWatch in that hour. In addition to metric storage charges, metrics published through PutMetricData incur an additional charge of $0.01 per million requests.

Some CloudWatch capabilities have their own usage measures. For example, OpenTelemetry metric publishing is charged at $0.50 per GB ingested, including 15 months of storage, while PromQL API queries are charged at $0.01 per million samples scanned. AWS notes that query charges can also apply to alarms and API calls that use query features.

Pros and Cons

Pros:

• Zero-config coverage for AWS resources — EC2, Lambda, RDS, ECS, and dozens of other services emit metrics and logs automatically.
• IAM-native access control — no separate auth system, no API keys to rotate outside AWS.
• Cross-account aggregation scales cleanly for organizations using AWS Organizations.
• Composite alarms reduce alert noise materially once you invest in designing them.
• Free tier is genuinely usable for small teams or non-production environments.
• Metric Streams integration means CloudWatch can be the collection tier even if you're shipping to another backend.

Cons:

• Log ingestion and query costs can surprise you — the highest-leverage cost optimization is aggressive retention limits and scoped queries.
• Dashboard UX is functional, not polished — Grafana or Datadog dashboards are more expressive.
• Limited usefulness outside AWS — hybrid workloads fight the tool rather than benefiting from it.
• APM and tracing story is fragmented across CloudWatch, X-Ray, and ServiceLens, where competitors offer a single surface.

Alternatives and How It Compares

CloudWatch is the default; the question is what pairs well with it or replaces it.

• Datadog — the go-to upgrade when teams outgrow CloudWatch's dashboards and want polished APM + tracing + log search in one product. Choose Datadog when multi-cloud or when you want a single observability surface that also handles non-AWS workloads.
• New Relic — closest competitor on feature breadth, with stronger APM and application-centric workflows. Choose New Relic if your teams are application-developer-first rather than infra-first.
• Grafana Cloud — the best choice if your team already lives in Grafana dashboards and open-source exporters. Pairs well with CloudWatch via Metric Streams — use CloudWatch for AWS-native collection, Grafana for visualization.
• Dynatrace — enterprise-grade APM with automated root-cause analysis. Choose Dynatrace when compliance, large-enterprise support, and automated diagnostics matter more than cost.
• Splunk — the right answer when log analytics for security or compliance is the primary need. CloudWatch Logs is serviceable for operational log search but was never designed for the SIEM workflows Splunk handles natively.

For most AWS-centric data teams, the practical answer is CloudWatch for infra + logs, plus one specialized tool — typically Datadog or Grafana for dashboards, or Splunk for security logs. Full replacement rarely makes sense while the workload is on AWS; augmentation almost always does.