Buying snapshot
Scroll sideways to see all columns. With a keyboard, focus this table and use the arrow keys.
| Decision point | What AWS states |
|---|---|
Operating model | Fully managed by AWS. AWS says CloudWatch integrates natively with virtually every AWS service. Install the CloudWatch agent with AWS Systems Manager, or publish logs with the PutLogData API. |
Workloads outside AWS | The OpenTelemetry-compatible CloudWatch agent ingests telemetry from on-premises servers and other clouds. Ingestion charges are the same whether data starts in AWS or elsewhere. |
Open standards | Native OpenTelemetry metric ingestion and PromQL queries, so existing Prometheus dashboards and alerts move over without rewriting queries. Metrics can also be queried from Amazon OpenSearch, Prometheus, Azure Monitor or a custom source built on AWS Lambda. |
Retention and resolution | 15 months of metric data; up to one-second visibility of metrics and logs. |
Log classes | Logs Standard for real-time monitoring with Live Tail, metric extraction, alarming and data protection. Logs Infrequent Access keeps managed ingestion, cross-account analytics and encryption, for ad-hoc queries and forensic analysis. |
Agent license | The CloudWatch agent is open source under the MIT License and collects host-level metrics and logs on Linux or Windows Server. Health data it sends about itself costs nothing and can be turned off. |
Our take
Choose CloudWatch when most of your workloads run on AWS and you want metrics, logs and alarms without running a separate monitoring stack. It also suits mixed estates that already use OpenTelemetry or Prometheus. Before a wide rollout, estimate your metric, log and query volumes, because they set the bill.
Evaluate Amazon CloudWatch
Comparisons
Where it stands out
AWS telemetry with no setup. More than 70 AWS services, including EC2, DynamoDB, S3, Lambda and API Gateway, publish infrastructure metrics with no action on your part, and more than 30 services publish logs. Container Insights adds CPU, memory, disk, network and container restart data for ECS, EKS, Fargate and standalone Kubernetes.
One view across accounts. A central monitoring account can search log groups, run Logs Insights queries and alarm on metrics from other accounts. Viewing and querying metrics and logs across accounts carries no additional charge. Composite alarms send one notification for an application instead of one for each affected resource.
AI help for troubleshooting. CloudWatch investigations offer AI-powered root cause analysis, Logs Anomaly Detection finds unusual log patterns without configuration parameters, and natural-language log queries (in preview) write the query for you. MCP servers connect your own agents to CloudWatch data.
Observability for AI agents. CloudWatch traces agent execution paths and runs continuous evaluations, with native support for LangChain, LangGraph, CrewAI, OpenAI Agents SDK, Vercel AI SDK and Strands through OpenTelemetry. With CloudWatch Omni this works inside VS Code, Kiro or Cursor.
Product screenshot
Trade-offs to weigh
Classic metric counts grow with dimensions. CloudWatch treats each unique combination of dimensions as a separate metric, even under the same metric name, and Detailed Monitoring is priced by the number of custom metrics. Adding a dimension such as host or customer can multiply the metric count you pay for.
Features add charges of their own. Metric alarms are billed for each metric they list (up to 10 with metric math), and PromQL and log query alarms add query charges. A dashboard that loads a logs query is charged for the query, a shared dashboard is charged for the GetMetricData calls that render it, and Metric Streams add Amazon Data Firehose charges.
Cross-account views stay in one Region. Cross-account observability covers accounts within one AWS Region. Copies of metrics to additional Regions go through metric centralization, which is charged per GB (see Pricing).
Pricing and plan conditions
There is no up-front commitment or minimum fee: you pay for what you use and are charged at the end of the month. Pricing varies by Region, and AWS points to its Pricing Calculator for estimates. CloudWatch Omni uses standard CloudWatch rates for ingestion and storage, and you pay for queries above an included allowance. Custom metrics, dashboards and alarms are prorated by the hour.
Scroll sideways to see all columns. With a keyboard, focus this table and use the arrow keys.
| Area | Free allowance |
|---|---|
Logs | 5 GB of data (ingestion, archive storage and data scanned by Logs Insights queries); 1,800 minutes of Live Tail per month. |
Metrics | Basic Monitoring metrics sent by AWS services; 10 custom or Detailed Monitoring metrics; 1 million API requests. GetMetricData, GetInsightRuleReport and GetMetricWidgetImage are always charged. |
Dashboards | 3 custom dashboards with up to 50 metrics each per month; all Automatic Dashboards. |
Alarms | 10 alarm metrics, only for Standard resolution alarms that list metrics directly and do not use a Metrics Insights query. |
Traces and canaries | First 100,000 X-Ray traces recorded and first 1,000,000 retrieved or scanned each month; 100 Synthetics canary runs per month. |
Scroll sideways to see all columns. With a keyboard, focus this table and use the arrow keys.
| What is charged | Published rate | Condition |
|---|---|---|
OpenTelemetry metric ingestion | $0.50 per GB ingested | Includes 15 months of storage, with no separate charge for API calls, metric storage or unique metric series. Volume is the uncompressed OTLP payload. |
OTel vended metric enrichment | $0.50 per GB | Converts AWS metrics such as EC2, RDS and ELB into OpenTelemetry format with resource tags. |
PromQL queries | $0.01 per million samples scanned | Queries run in the CloudWatch console, including dashboards, are free. |
PutMetricData requests | $0.01 per million requests | Charged in addition to the classic metric storage charge. |
EC2 Detailed Monitoring (AWS example) | Up to $3.60 per month at the highest price tier, or $0.24 per month at the lowest | For one EC2 instance publishing 12 additional metrics. |
Metric centralization | $0.05 per GB copied | The first copy to a destination account is free. |
Public signals
About these signals
Verified factual signals from public sources. They indicate observable activity or interest, not total adoption, product quality, or cost.
64 GitHub commits 90d556 GitHub stars0 vulnerabilities across 1 package
See all signals from 6 sources
npm · aws-embedded-metrics@4.2.1
Alternatives to Amazon CloudWatch
The reviewed substitutes for Amazon CloudWatch among the cloud-native monitoring, and what would make each one the better answer.
Other approaches
A different approach to the same problem. Each substitutes only for the workload named beside it.
- Datadog
- Datadog and Amazon CloudWatch both collect metrics, logs and alerts for applications running on AWS. CloudWatch is built into AWS and needs no extra vendor; Datadog is a third-party platform with deeper application monitoring that spans several clouds and on-premises systems.Applies to: Whether the cloud provider's own monitoring is enough, or a third-party platform is needed.
- Splunk
- Choose Splunk when your security team drives observability requirements, when regulatory log retention exceeds 90 days, or when SIEM correlation across AWS and on-premise sources is mandatory.
- Google Cloud Operations
- Amazon CloudWatch is chosen instead of Google Cloud Operations for AWS-native application and infrastructure monitoring workloads. We recommend it over Google Cloud Operations for teams whose production systems and incident-response workflow are centered on AWS.
- Azure Monitor
- Choose Azure Monitor when your primary infrastructure runs on Azure — it is the cheapest and least-friction option there, just as CloudWatch is for AWS.Applies to: For teams that run workloads on both AWS and Azure and want one cloud's native service to watch all of them.
- Grafana Loki
- The fork is the cloud's default against a best-of-breed store. Logs land in the provider's own service with no integration work and a bill that grows with ingest and retention; Loki costs a cluster to run and keeps bodies in object storage, which is why it stays cheap at volume. CloudWatch Logs is where AWS services already write, so choosing it is choosing not to move anything.Applies to: Logs for workloads running on AWS. CloudWatch stands in for Loki when the estate is AWS-only and zero integration work matters most; Loki stands in when volume makes per-GB ingest pricing the dominant cost, or the estate spans clouds.