Amazon CloudWatch is AWS’s native monitoring and observability platform for teams that need visibility into cloud resources, applications, logs, metrics, traces, and automated responses inside the AWS ecosystem. It works well for organizations already running workloads on AWS because it connects directly with services like EC2, Lambda, RDS, ECS, EKS, X-Ray, EventBridge, and Auto Scaling.
Pricing is where teams need to look closely. CloudWatch has no single flat price. Costs can come from custom metrics, log ingestion, log storage, metric filters, dashboards, alarms, synthetics, RUM, Contributor Insights, and other usage-based features. As telemetry volume grows, the final bill can become harder to predict.
This review breaks down AWS CloudWatch pricing, features, reviews, real cost scenarios, and key trade-offs to understand before relying on it as your main observability platform.
Want to model your current AWS CloudWatch bill before reading further? Our calculator breaks down every cost dimension: metrics ingestion, log storage, dashboards, alarms, and the API call costs most teams overlook.
Try the CloudWatch Calculator →What Is AWS CloudWatch?
Platform Overview
Amazon CloudWatch launched in 2009 as a metrics and monitoring service for EC2. Over the following 15 years it expanded into a full observability platform for the entire AWS ecosystem. Its core advantage is zero-instrumentation access: standard metrics for over 70 AWS services flow in automatically at no cost, no agent installation and no configuration required.
Today, CloudWatch covers:
- Log management and analytics via CloudWatch Logs, Logs Insights, and Live Tail
- Infrastructure metrics: standard AWS service metrics, custom application metrics, and Metric Streams
- Distributed tracing and APM via AWS X-Ray and Application Signals
- Container and serverless monitoring via Container Insights (EKS, ECS) and Lambda Insights
- Synthetic monitoring via CloudWatch Synthetics canaries
- Real user monitoring (CloudWatch RUM) for browser performance and behavior data
- Automated alarms and remediation actions tied directly to AWS services
- Cross-account and cross-region observability for AWS Organizations
CloudWatch serves three main audiences:
- AWS-native engineering and DevOps teams that want monitoring embedded directly in the AWS control plane without deploying additional infrastructure
- Organizations with compliance or data residency requirements that need all telemetry to remain within their AWS account and region
- Teams that need automated remediation: alarms that trigger Auto Scaling, EC2 recovery, Lambda functions, or SNS notifications without a separate orchestration layer
How AWS CloudWatch Works: Architecture, Deployment, and Scale
The core model
AWS CloudWatch is fundamentally a metrics repository. AWS services put metrics into the repository, and you retrieve statistics based on those metrics. If you put your own custom metrics into the repository, you can retrieve statistics on these as well. AWS
The data model
A namespace is a container for CloudWatch metrics, using the naming convention AWS/service, for example AWS/EC2. A metric is a time-ordered set of data points. A dimension is a name/value pair that is part of the identity of a metric, with up to 30 dimensions per metric. CloudWatch treats each unique combination of dimensions as a separate metric, even if the metrics have the same metric name. This is the root cause of the high-cardinality billing problem.
How data gets in
Many AWS services send metrics automatically for free at one data point per metric per 5-minute interval, without any configuration. Beyond that, the CloudWatch Agent collects system-level metrics and logs from EC2 and on-premises servers. Applications can push custom metrics via the PutMetricData API or embed them in log lines using Embedded Metric Format, which CloudWatch extracts automatically. The AWS Distro for OpenTelemetry (ADOT) collector covers any OpenTelemetry-instrumented workload running on EC2, ECS, EKS, Lambda, or on-premises.
Regional isolation
Metrics are stored separately in Regions, each designed to be completely isolated from the other Regions. Free tier allowances do not pool across regions. A team running in five regions has five independent sets of allowances.
Retention and rollup
CloudWatch retains metric data as follows: sub-60-second data points for 3 hours; 1-minute data points for 15 days; 5-minute data points for 63 days; and 1-hour data points for 455 days (15 months). Data points published with a shorter period are aggregated together for long-term storage. Metrics expire on this schedule automatically and cannot be deleted manually.
Scale and pricing structure
CloudWatch is fully managed with no infrastructure to provision. The only structural constraint at scale is the billing model: there are no Savings Plans, no reserved capacity, and no committed-use pricing. Every custom metric at every cardinality is charged at the on-demand rate, making dimension design the most consequential decision when building on CloudWatch.
Key Features of AWS CloudWatch
Standard metrics from over 70 AWS services are collected automatically at no cost. EC2 CPU utilization, Lambda invocations, RDS connections, S3 request counts, and hundreds more are available the moment a resource is created, with no agent, SDK, or configuration required. Detailed Monitoring (1-minute resolution) for EC2 is available at additional cost, billed as 7 custom metrics per instance.
Teams can publish custom metrics via the PutMetricData API, the CloudWatch Agent, or Embedded Metric Format (EMF). EMF embeds metric data inside structured log lines, which CloudWatch extracts automatically. It is the recommended approach for high-cardinality attributes, since embedding them as log fields avoids the multiplicative billing that makes dimension-heavy custom metrics expensive at scale.
Logs Insights provides an interactive query interface supporting field extraction, pattern detection, aggregation, and time-series visualization, billed per GB scanned regardless of results returned. Live Tail streams log events in real time for active debugging and is billed per minute after the first 1,800 free minutes per month.
CloudWatch Alarms evaluate metrics against static thresholds, metric math expressions, anomaly detection bands, or Metrics Insights queries. On breach, an alarm can stop, terminate, reboot, or recover an EC2 instance; trigger Auto Scaling; invoke a Lambda function; send an SNS notification; or create an OpsCenter OpsItem. Composite alarms combine multiple component alarms into a single higher-level signal, reducing noise without requiring code.
Container Insights provides pre-built dashboards and metrics for EKS, ECS, and Kubernetes at the cluster, node, service, pod, and task level. Lambda Insights covers execution duration, memory consumption, cold start frequency, and fault rates. Both features generate additional CloudWatch metrics and log charges on top of their per-resource fees. A 10-node EKS cluster running Container Insights generates roughly 320 custom metrics, adding approximately $96/month before log costs.
X-Ray provides end-to-end distributed tracing across AWS services and instrumented applications, generating service maps, trace timelines, and latency distributions. Application Signals, generally available since 2025, adds service-level health dashboards surfacing golden signals (request rate, error rate, latency) per service and operation without manual metric configuration. It includes a free-usage period per account before paid rates apply.
CloudWatch Synthetics runs scripted canary functions on a schedule to test API endpoints and web flows. Canary runs are billed at $0.0012 each after the first 100 free runs per month, with Lambda execution, CloudWatch Logs, S3, and custom metric charges billed separately. CloudWatch RUM collects real-user performance data including page load times, JavaScript errors, and HTTP request performance, billed at $1.00 per 100,000 events after a one-time trial of 1 million events per account.
CloudWatch supports unified dashboards, alarms, and log queries spanning multiple AWS accounts within an AWS Organization. A central monitoring account can view metrics and logs from source accounts without copying data, at no additional charge for metrics and logs. This is a meaningful operational advantage for platform teams managing multi-account AWS architectures where observability data is otherwise siloed by account boundary.
Metrics Insights provides a SQL-like query language for analyzing metrics dynamically across large numbers of resources, which is particularly useful for auto-scaling environments where monitored resources change frequently. Metric Streams enables near-real-time streaming of CloudWatch metrics to Kinesis Data Firehose for delivery to third-party tools such as Datadog, Dynatrace, Splunk, or New Relic, and is often more cost-efficient than polling the CloudWatch API externally.
What Are CloudWatch’s Pricing Options?
CloudWatch uses a consumption-based pricing model. There are no upfront commitments, no minimum fees, no per-user charges, and no Savings Plans or reserved capacity discounts. You pay for what you use, billed at the end of each month. Pricing is broken into distinct components, each with its own billing unit and free tier.
Free tier
CloudWatch includes a free tier that covers small workloads. All figures apply per region, per month, for US East (N. Virginia) unless stated otherwise.
| Component | Free Allowance | Notes |
|---|---|---|
| Logs (ingestion + storage + Insights combined) | 5 GB | All three log charges share this single 5 GB bucket |
| Custom / Detailed Monitoring Metrics | 10 metrics | Standard AWS service metrics are always free |
| X-Ray traces | 100,000 recorded / 1,000,000 retrieved | Monthly per account |
| Alarms | 10 alarm metrics | Standard resolution only; monthly |
| Dashboards | 3 dashboards (up to 50 metrics each) | Automatic dashboards are always free |
AWS CloudWatch Pricing Options
Metrics
Custom metrics are billed per unique metric per month, prorated hourly. Each unique combination of name, namespace, and dimension values is one metric.
- First 10,000 metrics: $0.30 per metric/month
- Next 240,000 (up to 250,000): $0.10 per metric/month
- Next 750,000 (up to 1,000,000): $0.05 per metric/month
- Over 1,000,000: $0.02 per metric/month
Logs
CloudWatch bills log data three times independently: once to ingest, once to store, and once to query.
- Standard ingestion: $0.50 per GB (after 5 GB free tier)
- Infrequent Access ingestion: $0.25 per GB (no Live Tail or metric filters)
- Archive storage: $0.03 per GB per month (“Never expire” is the default)
- Logs Insights queries: $0.005 per GB scanned, regardless of results returned
- Live Tail: $0.01 per minute (after 1,800 free minutes per month)
Alarms
- Standard resolution (60-second): $0.10 per alarm metric/month (10 free per region)
- High resolution (10-second): $0.30 per alarm metric/month
- Composite alarms: $0.50 per alarm/month
Dashboards
- $3.00 per dashboard per month beyond the 3 free, billed per 50-metric block
APM and Tracing
- X-Ray traces recorded: $5.00 per 1 million traces (after 100,000 free per month)
- X-Ray traces retrieved or scanned: $0.50 per 1 million traces (after 1,000,000 free per month)
- Application Signals: $0.35 per GB ingested (after a 3-month or 100 GB one-time free trial per account)
Synthetics and RUM
- Synthetics canary runs: $0.0012 per run (after 100 free per month). This does not include the Lambda, Logs, S3, and metric charges each run also triggers.
- CloudWatch RUM events: $1.00 per 100,000 events (after a one-time 1M event trial per account)
Infrastructure Monitoring
- Container Insights, EKS standard: $0.90 per active node per month
- Container Insights, EKS enhanced observability: $0.35 per vCPU per month
Both rates are in addition to the separate metrics and log charges that Container Insights generates.
What Does CloudWatch Really Cost?
The assumptions and cost figures below are directional editorial estimates using CloudWatch’s publicly available pricing as of May 2026. They are not official AWS quotes. Actual costs will vary based on your specific metric cardinality, log verbosity, query patterns, retention settings, alarm types, region, and any applicable enterprise discounts.
CloudWatch’s headline per-component rates are clear, but the real total depends on how many services you run, how much telemetry they generate, which features you have enabled, and how carefully you have configured retention and metric dimensions. The three scenarios below walk through realistic configurations at different team scales.
| Team Size | Hosts | Data Volume (approx.) |
| Small Team | 5 hosts | 720 GB logs, 360 GB traces, 1 GB metrics/month |
| Growing Team | 30 hosts | 3.6 TB logs, 1.8 TB traces, 5 GB metrics/month |
| Mid-Market Team | 150 hosts | 18 TB logs, 9 TB traces, 25 GB metrics/month |
Assumptions Used in the Cost Scenarios
- All data volumes are directional estimates based on the usage profiles above.
- We have used CloudWatch’s publicly available pricing as of May 2026.
- On-demand monthly billing rates are used throughout; CloudWatch has no annual or committed-use pricing.
- Log compression is assumed at approximately 5:1 for storage cost estimates.
- Scenarios do not include AWS Enterprise Discount Program (EDP) credits or negotiated enterprise discounts.
Scenario 1: Small Team, 5 Hosts
Situation: A small engineering team runs 5 hosts including application services and a database. They generate 720 GB of logs per month, 360 GB of traces, and minimal custom metrics. They want centralized log search, basic alerting, and uptime visibility without heavy operational overhead.
Why teams at this stage use CloudWatch:
- They are already on AWS and want monitoring with zero instrumentation or agent setup.
- Basic AWS service metrics (EC2 CPU, Lambda invocations, RDS connections) are immediately available for free.
- They want alerting tied directly to Auto Scaling or EC2 recovery actions without adding a separate tool.
- They have not yet hit the pricing complexity that emerges at higher metric cardinality or log volume.
- CloudWatch is the path of least resistance for a small, AWS-only team.
Estimated usage profile:
| Configuration | Detail |
| Logs | 720 GB/month (715 GB billed after free tier) |
| Traces (X-Ray) | 360 GB/month (~72M traces estimated) |
| Metrics | 1 GB/month (~5 custom metrics, within free tier) |
| Synthetics | 50,000 API test runs + 2,000 browser test runs/month |
| RUM | 5,000 sessions/month |
| Alarms + Dashboards | 10 alarms, 1 dashboard (both within free tier) |
Estimated monthly cost:
Disclaimer: These are directional editorial estimates based on CloudWatch’s public pricing. They are not official AWS quotes.
| Component | Calculation | Monthly Cost |
| Log ingestion + storage + queries | $357.50 + $4.29 + $0.25 | ~$362.04 |
| X-Ray traces recorded + retrieved | $355.00 + $35.50 | ~$390.50 |
| Synthetics (API + browser runs) | $59.88 + $2.40 | ~$62.28 |
| RUM (5,000 sessions) | $1.00 per 100K x 0.05 | ~$0.05 |
| Metrics + Alarms + Dashboards | Within free tier | $0 |
| Total Estimated Cost | ~$814.87/month |
What this scenario shows: Even at small team scale, CloudWatch costs nearly $815 per month once logs, traces, and Synthetics are fully enabled. Log ingestion and X-Ray traces alone account for over $750 of that. The Synthetics figure covers only the canary run charge; each run also triggers Lambda execution, CloudWatch Logs ingestion, S3 artifact storage, and custom metric charges billed separately, so the true cost is higher.
Scenario 2: Growing Team, 30 Hosts
Situation: A growing SaaS company runs about 30 hosts across application services, Kubernetes workloads, and databases. They generate 3.6 TB of logs per month, 1.8 TB of traces, and have around 200 custom application metrics. They need centralized logging, distributed tracing, alerting, and basic infrastructure dashboards.
Why teams at this stage evaluate CloudWatch more carefully
- Log volume has grown to a point where the three-part billing model (ingest, store, query) becomes a serious budget line.
- Custom metric count has increased enough to exit the free tier and enter the $0.30/metric tier.
- High-cardinality dimensions such as per-customer or per-endpoint metrics start creating billing surprises.
- Logs Insights query costs during incidents become unpredictable as log group sizes grow.
- The team starts receiving CloudWatch cost alerts that require active investigation.
Estimated usage profile:
| Configuration | Detail |
| Logs | 3,600 GB/month (3,595 GB billed after free tier) |
| Traces (X-Ray) | 1,800 GB/month (~360M traces estimated) |
| Metrics | 5 GB/month (~200 custom metrics, 190 billed after free tier) |
| Synthetics | 500,000 API test runs + 20,000 browser test runs/month |
| RUM | 50,000 sessions/month |
| Alarms + Dashboards | 30 alarms (20 billed), 4 dashboards (1 billed) |
Estimated monthly cost:
Disclaimer: These are directional editorial estimates based on CloudWatch’s public pricing. They are not official AWS quotes.
| Component | Calculation | Monthly Cost |
| Log ingestion + storage + queries | $1,797.50 + $21.57 + $1.50 | ~$1,820.57 |
| X-Ray traces recorded + retrieved | $1,799.50 + $179.50 | ~$1,979.00 |
| Synthetics (API + browser runs) | $599.88 + $24.00 | ~$623.88 |
| Custom metrics + alarms + dashboards | $57.00 + $2.00 + $3.00 | ~$62.00 |
| RUM (50,000 sessions) | $1.00 per 100K x 0.5 | ~$0.50 |
| Total Estimated Cost | ~$4,485.95/month |
What this scenario shows: Moving from 5 hosts to 30 hosts takes the bill from roughly $815 to nearly $4,500 per month. X-Ray traces and log ingestion are now running almost identically as the two biggest cost drivers, together accounting for close to $3,800 of the total. Synthetics has become the third largest line item at over $620, before accounting for its downstream Lambda, Logs, and S3 charges.
Scenario 3: Mid-Market Team, 150 Hosts
Situation: A mid-market B2B SaaS company runs approximately 150 hosts across AWS, with Kubernetes workloads, multiple database clusters, backend microservices, and customer-facing applications. They generate 18 TB of logs per month, 9 TB of traces, and around 1,000 custom metrics. Multiple on-call rotations are active, Container Insights is enabled on EKS, and the team uses Synthetics for uptime monitoring.
Why teams at this scale scrutinize CloudWatch costs
- Observability spend becomes a meaningful budget line that finance and engineering leadership both track.
- High-cardinality metric dimensions from microservices create unexpected metric multiplication across teams.
- Container Insights generates both metric and log charges simultaneously, making spend hard to attribute.
- Log retention policies become critical because 18 TB per month accumulates rapidly without expiration rules.
- Logs Insights query costs during incidents at this log volume can generate thousands of dollars from a single outage investigation.
- Teams begin seriously evaluating whether third-party observability tools would be cheaper at this scale.
Estimated usage profile:
| Configuration | Detail |
| Logs | 18,000 GB/month (17,995 GB billed after free tier) |
| Traces (X-Ray) | 9,000 GB/month (~1.8B traces estimated) |
| Metrics | 25 GB/month (~1,000 custom metrics, 990 billed + 320 Container Insights) |
| Synthetics | 2,000,000 API test runs + 80,000 browser test runs/month |
| RUM | 200,000 sessions/month |
| Alarms + Dashboards | 80 alarms (70 billed), 8 dashboards (5 billed) |
Estimated monthly cost:
Disclaimer: These are directional editorial estimates based on CloudWatch’s public pricing. They are not official AWS quotes. Actual costs depend on metric cardinality, log verbosity, query frequency, Container Insights mode, and region.
| Component | Calculation | Monthly Cost |
| Log ingestion + storage + queries | $8,997.50 + $107.97 + $7.50 | ~$9,112.97 |
| X-Ray traces recorded + retrieved | $8,999.50 + $899.50 | ~$9,899.00 |
| Synthetics (API + browser runs) | $2,399.88 + $96.00 | ~$2,495.88 |
| Custom metrics + Container Insights + alarms + dashboards | $393.00 + $9.00 + $7.00 + $15.00 | ~$424.00 |
| RUM (200,000 sessions) | $1.00 per 100K x 2 | ~$2.00 |
| Total Estimated Cost | ~$21,933.85/month |
What this scenario shows: At mid-market scale, CloudWatch becomes one of the most significant line items in the entire AWS bill. Logs and X-Ray traces each independently exceed $9,000 per month, and Synthetics adds another $2,500 on top. The total of nearly $22,000 per month is the figure that typically triggers a formal observability platform review. This is the scale at which the absence of any Savings Plans or committed-use pricing in CloudWatch becomes most painful: every dollar of that bill is at full on-demand rates with no mechanism to reduce it through purchasing commitments.
What Actually Drives CloudWatch Costs
Understanding CloudWatch pricing means looking beyond the headline rates. The final bill usually depends on three main cost drivers.
1. Metric cardinality
Custom metrics can become a major cost driver at scale. CloudWatch treats each unique combination of metric name, namespace, and dimensions as a separate metric. AWS also states that dimensions are part of a metric’s identity, so adding a new dimension value creates a new variation of that metric. Custom metrics are priced at $0.30 per metric per month for the first 10,000 metrics, with lower volume tiers after that.
Example: A team monitors API latency with these dimensions:
service: 10 values
status_code: 3 values
region: 3 values
That creates 90 billable metrics.
90 × $0.30 = $27/month
Now add customer_id with 100 unique values:
10 × 3 × 3 × 100 = 9,000 metrics
9,000 × $0.30 = $2,700/month
This is why teams should avoid high-cardinality dimensions such as request_id, user_id, session_id, customer_id, or UUID-style values unless they have a clear cost model.
2. Log volume and the three-part billing model
Logs are often the highest-volume telemetry type, so they can have the biggest impact on the monthly bill. CloudWatch Logs can create separate charges for ingestion, storage, and queries. In AWS’s US East pricing examples, log ingestion is shown at $0.50/GB, archival storage at $0.03/GB-month, and Logs Insights queries are covered under the free tier only up to 5 GB of data, after which scanned data is billable.
Example: If an engineer runs 20 Logs Insights queries against a 500 GB log group, the scanned volume is:
20 × 500 GB = 10,000 GB scanned
At $0.005/GB scanned, that is $50 in query charges.
Retention also matters. By default, CloudWatch Logs stores log data indefinitely unless a retention policy is set. That means old logs can continue adding storage cost and can increase the amount of data scanned during future investigations.
3. Feature cascade costs
Some CloudWatch features create charges across multiple billing buckets at once.
For example, AWS’s Container Insights pricing examples include both CloudWatch metrics and CloudWatch Logs charges. AWS also notes that Container Insights log costs vary based on cluster names, container names, pod names, service names, labels, and related metadata.
CloudWatch Synthetics is another example. The canary run charge is only one part of the total cost. AWS’s own pricing example also includes Lambda charges, CloudWatch Logs charges, S3 charges, CloudWatch metrics, and alarms.
This is why enabling one feature can create several smaller line items across the same AWS bill.
Additional Costs Buyers Should Plan For
CloudWatch pricing varies by AWS Region, so teams running workloads across multiple Regions should model costs per Region instead of assuming one flat global rate. AWS notes that pricing varies by Region and recommends using the AWS Pricing Calculator for estimates.
CloudWatch includes 1 million API requests in the free tier, but GetMetricData, GetInsightRuleReport, and GetMetricWidgetImage are excluded. AWS states that these three operations are always charged.
This matters for dashboards, reporting jobs, and third-party monitoring tools that poll CloudWatch frequently. AWS has also published guidance on identifying resources that drive GetMetricData charges.
CloudWatch Synthetics pricing starts at $0.0012 per canary run, but that is not the full cost. Each canary can also create Lambda, CloudWatch Logs, S3, CloudWatch metric, and alarm charges depending on how it is configured.
CloudWatch does not publish a reserved-capacity or Savings Plans-style pricing model for standard CloudWatch usage. The public pricing page positions CloudWatch as pay-as-you-go with no upfront commitment or minimum fee.
In practice, cost control usually comes from reducing noisy usage: lowering metric cardinality, setting log retention policies, limiting unnecessary debug logs, right-sizing alarms, and watching API polling frequency.
CloudWatch publishes standard public rates, but large AWS customers may have private commercial agreements with AWS. Those discounts are not shown on the public CloudWatch pricing page, so buyers should verify final pricing with their AWS account team.
AWS CloudWatch User Reviews in 2026
Amazon CloudWatch has strong user ratings across major B2B review platforms. Capterra lists CloudWatch at 4.5/5 from 92 reviews, with positive sentiment around AWS resource monitoring, dashboards, alerts, and logging. Gartner Peer Insights also lists CloudWatch at 4.5/5 from 728 ratings.
Positive feedback usually focuses on native AWS integration, real-time monitoring, dashboards, logs, and alarms. Critical feedback often points to pricing complexity, cost growth with higher log volume or custom metrics, UI complexity, and the learning curve for advanced setups.
What users praise
Users often praise CloudWatch for monitoring AWS resources with little setup. Capterra’s pros-and-cons summary lists “comprehensive AWS resource monitoring” as a major positive theme, with users reporting real-time insights and reliable visibility across AWS resources.
One Capterra reviewer said CloudWatch made it easy to track AWS cloud servers and automation logs, though the same review also mentioned that the product can feel clunky and has a steeper learning curve.
Reviewers also highlight dashboards, alerts, and log analytics. Capterra lists “custom dashboards and automated alerts” as one of CloudWatch’s main pros. G2 reviews also mention near real-time monitoring, logs, custom queries, dashboards, and integration with AWS services such as Lambda and SNS.
CloudWatch’s biggest strength is still its native AWS fit. G2 review snippets mention AWS service integration, custom metrics, alarms, logs, and dashboards. Gartner Peer Insights also includes reviews that praise CloudWatch for logging AWS service data, connecting well with AWS services, and helping teams debug issues.
What users criticize
Disclaimer: The points below reflect recurring themes from Capterra, G2, Gartner Peer Insights, and AWS documentation/community cost guidance as of May 2026. They should be treated as user feedback and cost-risk patterns, not universal product limitations.
Pricing is one of the most common concerns. G2’s pros-and-cons page says users find CloudWatch pricing confusing, especially when high log volume and custom metrics lead to unexpected costs. It also notes concerns around high-frequency metrics, log ingestion, and cost management at scale.
Capterra also lists “complex and unpredictable pricing” as a negative review theme. Its summary shows this as a recurring con, while still giving CloudWatch a strong overall rating.
Several user-review themes connect rising costs to log volume, detailed monitoring, and custom metrics. G2 specifically mentions confusing pricing as log ingestion and detailed monitoring increase. AWS’s own pricing examples also show how metric counts and log ingestion volumes directly affect monthly CloudWatch charges.
G2 reviews mention that the interface and configuration can feel complex for new users, especially when setting up custom metrics and alarms. The same review snippet also says pricing can become confusing as log ingestion and detailed monitoring increase.
Capterra includes similar feedback. One reviewer praised CloudWatch for AWS server monitoring and log tracking, but said it was “pretty clunky” and had a steeper learning curve.
Summary rating breakdown: May 2026
| Platform | Rating | Notes |
| Capterra | 4.5 / 5 | 91 reviews; strong on reliability, dashboards, and alerts. |
| G2 | 4.3 / 5 | 399 reviews; strong AWS integration, but pricing concerns. |
| Gartner Peer Insights | 4.5 / 5 | 728 ratings; praised for AWS connectivity and logs. |
How to Reduce Your CloudWatch Costs
Metrics
- Audit high-cardinality dimensions. Any dimension with more than roughly 10 unique values (user IDs, request IDs, UUIDs) is a cost risk. Use Embedded Metric Format (EMF) to embed high-cardinality attributes as log fields and query them via Contributor Insights rather than as metric dimensions.
- Use Contributor Insights for per-user analysis. Contributor Insights lets you rank and analyze high-cardinality attributes such as customer ID without creating a separate metric per value. This is CloudWatch’s intended model for high-cardinality observability.
- Reduce resolution where real-time alerting is not needed. High-resolution metrics cost the same per metric as standard-resolution but generate significantly more PutMetricData API calls. Only enable high resolution where sub-minute alerting is operationally justified.
- Stream archival metrics to S3. If you only need certain metrics for post-incident analysis rather than real-time alerting, use Metric Streams to send them to S3 via Kinesis Data Firehose. S3 storage is substantially cheaper than active CloudWatch metric retention.
Logs
- Set retention policies on every log group. The “Never expire” default is the most common source of accumulating CloudWatch storage costs. Match retention to actual debugging and compliance needs: typically 7 to 30 days for application logs, longer for audit and compliance logs.
- Use the Infrequent Access log class for low-priority logs. At $0.25/GB versus $0.50/GB for Standard, Infrequent Access costs half as much. It trades away Live Tail and metric filters, but is appropriate for the majority of log data.
- Filter logs before ingestion. Use the CloudWatch Agent’s log filter expressions to drop log events below a severity threshold. Shipping only WARN and above in production can reduce log volume by 60 to 80 percent in typical applications.
- Narrow Logs Insights time windows. Every query is billed per GB scanned regardless of results. A 1-hour window scans roughly 1/720th of what a 30-day window scans on the same log group.
- Use saved queries. CloudWatch Logs Insights automatically saves queries in your history. Reusing saved queries avoids re-running expensive exploratory queries from scratch during incidents.
Alarms
- Use standard alarms over anomaly detection unless dynamic thresholds are necessary. Anomaly detection alarms cost 3x a standard alarm. For stable, well-understood metrics, a static threshold is cheaper and simpler.
- Prefer composite alarms over many individual alarms. A composite alarm that aggregates several component alarms reduces per-alarm cost and cuts alarm noise simultaneously.
- Delete unused alarms. Alarms in INSUFFICIENT_DATA state are still billed. Periodically audit and remove alarms for resources that no longer exist.
CloudWatch Alternatives: How It Compares to Competitors
CloudWatch’s tight AWS integration makes it hard to replace completely for basic AWS service monitoring. Many teams keep CloudWatch as the AWS-native baseline, then add or replace specific capabilities when they need deeper APM, broader cross-cloud visibility, better OpenTelemetry workflows, or more predictable pricing.
CloudWatch vs. CubeAPM
CloudWatch and CubeAPM solve different problems. CloudWatch is strongest for native AWS service monitoring, AWS alarms, AWS remediation workflows, and keeping telemetry inside AWS Regions. CubeAPM is stronger for deep APM, OpenTelemetry-native observability, and managed self-hosted deployment where logs, metrics, and traces stay inside the customer’s own infrastructure.
| Category | CloudWatch | CubeAPM |
| Pricing model | Separate charges across metrics, logs, alarms, traces, dashboards | Flat $0.15/GB ingested |
| Deployment | AWS-managed regional service | Self-hosted (vendor-managed) |
| APM depth | X-Ray traces and Application Signals | Deeper APM with distributed tracing |
| Data residency | Data remains within AWS services and selected Regions | Telemetry remains inside the customer’s own environment |
| OpenTelemetry | Supported through ADOT and AWS integrations | OpenTelemetry-native |
| Best fit | AWS-native monitoring baseline | Deep APM with strict data control and predictable pricing |
CloudWatch vs. Datadog
Datadog is one of the broadest observability platforms, with infrastructure monitoring, APM, log management, RUM, synthetics, security monitoring, and many integrations. Its pricing is modular, with different billing units across products such as infrastructure hosts, APM, logs, RUM, and synthetics.
| Category | CloudWatch | Datadog |
| Pricing model | Separate charges for metrics, logs, alarms, traces, dashboards, APIs, and other features | Per-host pricing plus usage-based product charges |
| Log management | Strong AWS-native logging with separate ingest, storage, and query-related costs | Strong log management with separate ingestion, indexing, and retention pricing |
| APM depth | X-Ray traces and Application Signals | Strong APM with distributed tracing and continuous profiling |
| AWS integration | Native AWS integration | Strong AWS support, usually through agents, integrations, and forwarders |
| Free tier | AWS free-tier allowances for metrics, logs, alarms, APIs, traces, and other services | Free infrastructure monitoring tier with limited scope |
| Best fit | AWS-native monitoring baseline | Feature-rich full-stack observability teams |
CloudWatch vs. Grafana Cloud
Grafana Cloud is a strong fit for teams already using Grafana, Prometheus, Loki, and Tempo. Its free tier includes 10k active metric series, 50 GB logs, 50 GB traces, 3 active users, and 14-day retention.
| Category | CloudWatch | Grafana Cloud |
| Free tier | Includes free allowances for custom/detailed metrics, logs, alarms, API requests, traces, and other features | 10k active metric series, 50 GB logs, 50 GB traces, 3 active users, 14-day retention |
| Query languages | Logs Insights, Metrics Insights, PromQL support for some use cases | LogQL, PromQL, TraceQL |
| AWS integration | Native AWS integration | Via CloudWatch data source plugin and AWS integrations |
| Cost optimization tooling | Requires careful metric, log, and dimension management | Adaptive Telemetry, Adaptive Logs, and usage controls |
| SIEM/security | Usually handled through separate AWS security services | Usually requires separate security tools or integrations |
| Best fit | AWS-native monitoring baseline | Teams already invested in the Grafana open-source ecosystem |
CloudWatch vs. New Relic
New Relic is strong for teams that want broad full-stack observability and a generous free tier. Its pricing combines data ingest with user-based pricing at higher tiers. New Relic’s pricing page lists 100 GB/month of free data ingest, unlimited free basic users, and one free full platform user.
| Category | CloudWatch | New Relic |
| Pricing model | Separate charges across metrics, logs, alarms, traces, dashboards, APIs, and other features | Data ingest plus user-based pricing |
| Free tier | Includes free allowances for metrics, logs, alarms, API requests, traces, and other services | 100 GB/month data ingest, unlimited basic users, 1 full platform user |
| Log management | Strong AWS-native log collection and analysis | Strong log management under unified data ingest pricing |
| APM depth | X-Ray traces and Application Signals | Strong APM with broad language and framework support |
| AWS integration | Native AWS integration | Strong AWS support through agents and cloud integrations |
| Best fit | AWS-native monitoring baseline | Full-stack observability teams that want broad platform coverage |
The right tool depends on your AWS commitment, existing instrumentation, data residency needs, and cost sensitivity. CloudWatch often makes sense as the AWS-native baseline for service metrics, logs, and alarms. Third-party platforms become more useful when teams need deeper APM, cross-cloud visibility, stronger OpenTelemetry workflows, or simpler cost forecasting.
Is CloudWatch the Right Choice?
When CloudWatch works best
CloudWatch works best when most of your infrastructure runs on AWS and you want monitoring built into the AWS control plane. It supports AWS-native metrics, alarms, dashboards, logs, and cross-account monitoring, so teams can get basic AWS visibility without adding a separate monitoring platform. AWS also notes that many services publish default metrics to CloudWatch automatically.
It is especially useful when teams need alarms tied directly to AWS actions. CloudWatch alarms can send SNS notifications, perform EC2 actions, trigger Auto Scaling actions, create Systems Manager OpsItems or Incident Manager incidents, and start operational investigations.
CloudWatch is a good fit for AWS-first teams that want telemetry to stay within their AWS environment and selected AWS Regions. This can help regulated teams keep monitoring data inside their existing AWS security, IAM, and audit model.
This does not remove the need for proper configuration. Teams still need to manage IAM permissions, log retention, encryption settings, account access, and cross-account or cross-region sharing carefully.
CloudWatch’s alarm-to-action model is one of its strongest native advantages. Teams can use alarms to stop, terminate, reboot, or recover EC2 instances and can also connect alarms to Auto Scaling, SNS, Lambda, EventBridge, or Systems Manager workflows.
This is useful for teams that want monitoring and remediation to stay close to the infrastructure. Third-party tools can support similar workflows, but they usually need extra integrations.
CloudWatch is practical for small AWS teams with simple monitoring needs, low custom metric usage, and moderate log volume. Basic AWS service metrics, alarms, logs, and dashboards can cover many day-to-day needs without much setup.
Costs are easier to manage when teams avoid high-cardinality custom metrics; set log retention policies; and keep logs, alarms, dashboards, and query usage under control. AWS specifically recommends avoiding high-cardinality dimensions in embedded metric formats because CloudWatch can create a custom metric for each unique dimension combination.
When CloudWatch may not be the right fit
CloudWatch custom metric costs can grow quickly when teams add dimensions such as customer_id, request_id, session_id, or very granular endpoint labels. AWS defines traditional CloudWatch metric identity by namespace, metric name, and dimensions, and custom metrics can have up to 30 dimensions.
For teams that need heavy per-user, per-customer, or per-request analysis, Prometheus-style systems or purpose-built observability platforms may be easier to manage from a cost and query-flexibility standpoint.
CloudWatch has improved its APM story through Application Signals and X-Ray. Application Signals can collect application metrics and traces and show call volume, availability, latency, faults, errors, and service health.
Still, teams that need deeper APM workflows, richer log-metric-trace correlation, profiling, and code-level diagnostics may find dedicated APM tools like Datadog, Dynatrace, New Relic, or CubeAPM more complete.
CloudWatch is strongest inside AWS. It can collect metrics, logs, and traces from EC2 instances, on-prem servers, and containerized applications through the CloudWatch Agent, but it is still mainly designed around AWS operations.
Teams with major workloads on Azure, GCP, Kubernetes outside AWS, or on-prem environments may prefer a vendor-neutral observability platform that gives one view across all systems.
CloudWatch pricing can be hard to forecast because costs can come from custom metrics, logs, queries, alarms, dashboards, traces, Synthetics, RUM, Application Signals, API calls, and other feature-specific charges. AWS’s own pricing page includes separate pricing examples for logs, metrics, Synthetics, Application Signals, and X-Ray.
Conclusion
AWS CloudWatch is a strong choice for teams already committed to AWS. It offers zero-setup monitoring for many AWS services, native alarms, automated actions, AWS data residency, and cross-account visibility for larger AWS environments.
The main trade-off is cost predictability. CloudWatch pricing can become hard to forecast because of custom metrics, metric dimensions, log ingestion, log storage, query costs, alarms, dashboards, and feature-based charges. Without retention policies and metric controls, costs can grow faster than expected.
For AWS-first teams, CloudWatch can work well if usage is managed carefully. But teams that need deeper APM, simpler pricing, multi-cloud support, or stronger telemetry control may want to compare it with tools like CubeAPM, Grafana Cloud, or Prometheus before scaling further.
Disclaimer: This is an independent editorial review based on publicly available AWS CloudWatch documentation and pricing pages, supplemented by verified user reviews from Capterra, G2, and the r/aws Reddit community at the time of writing (May 2026). Pricing, feature availability, and plan terms may change; readers should verify current details directly with AWS before making purchasing or implementation decisions. Source: aws.amazon.com/cloudwatch/pricing/.
FAQs
1. What is the AWS CloudWatch free tier?
The CloudWatch free tier includes 10 custom metrics, 10 standard-resolution alarms, 1 million standard API requests, 5 GB of log data (ingestion, storage, and Insights queries combined), 3 dashboards with up to 50 metrics each, 100 Synthetics canary runs, and 1,800 minutes of Live Tail per month. Free tier allowances apply per region and do not pool across regions. Source: Amazon CloudWatch Pricing (aws.amazon.com/cloudwatch/pricing).
2. Why is my CloudWatch bill so high?
The most common causes are: high-cardinality metric dimensions creating thousands of billable metrics at $0.30 each; log retention left at “Never expire” causing storage to grow indefinitely; heavy Logs Insights queries scanning large log groups; and anomaly detection alarms, which cost 3x standard alarms. Enabling Container Insights also generates both metrics and log charges simultaneously.
3. Are CloudWatch metrics free?
Standard metrics from AWS services (EC2 CPU, Lambda invocations, and S3 request counts) are always free at 5-minute resolution. Detailed Monitoring metrics (1-minute EC2 metrics) and custom application metrics are billed at $0.30 per metric per month for the first 10,000, with volume discounts beyond that. Source: Amazon CloudWatch Pricing (aws.amazon.com/cloudwatch/pricing).
4. What is the difference between Standard and Infrequent Access log classes in CloudWatch?
Standard logs cost $0.50/GB ingested and support all CloudWatch features including Live Tail, metric filters, subscription filters, Logs Insights, and Contributor Insights. Infrequent Access logs cost $0.25/GB ingested but do not support Live Tail, metric filters, or subscription filters. Source: Amazon CloudWatch Pricing (aws.amazon.com/cloudwatch/pricing).
5. How do I reduce my CloudWatch costs?
The highest-impact actions are: set retention policies on all log groups; audit and remove high-cardinality metric dimensions; switch to Infrequent Access log class for lower-priority logs; delete unused alarms; use Contributor Insights for high-cardinality analysis instead of metric dimensions; and narrow Logs Insights query time windows to reduce GB scanned.