AWS monitoring cost 2026: native vs third-party

CloudWatch is the AWS-native observability product, billed across multiple meters with no economic floor. Custom metrics cost $0.30 per metric per month for the first 10,000 metrics, dropping to $0.10, $0.05, and $0.02 at higher volume tiers. CloudWatch Logs ingestion costs $0.50 per gigabyte ingested plus $0.03 per gigabyte per month for storage. Dashboards cost $3 per dashboard per month above the 3 free dashboards included with the AWS account. CloudWatch Synthetics canaries cost $0.0012 per run. CloudWatch RUM (real-user monitoring) costs $1 per 100,000 events. CloudWatch Logs Insights queries cost $0.005 per gigabyte scanned.

The pricing structure rewards modest, AWS-native workloads and punishes comprehensive observability. A small AWS workload running 10 EC2 instances with basic CloudWatch metrics, modest log volume (5 GB per day), and a handful of dashboards typically costs $50 to $150 per month on CloudWatch. The same workload on Datadog with full observability would be $250 to $500 per month, three to five times more expensive. CloudWatch wins decisively at this scale.

At larger scale the picture shifts. A 100-host AWS workload with comprehensive observability (custom application metrics, full APM via X-Ray, 50 GB per day of CloudWatch Logs, 30 plus dashboards, synthetic checks across 20 endpoints) typically costs $1,500 to $4,000 per month on CloudWatch native. The same workload on Datadog is $5,500 to $9,000 per month. CloudWatch is still cheaper but the gap has narrowed substantially. The per-meter pricing accumulates faster than headline rates suggest, particularly when log volume grows or when the team adds CloudWatch Synthetics and RUM.

The non-cost considerations are equally important. CloudWatch dashboards are functional but visibly less polished than Grafana or Datadog UX. CloudWatch alerting is capable but lacks the alert-grouping and incident-response sophistication of dedicated observability platforms. CloudWatch Logs Insights is operationally adequate for ad-hoc queries but expensive for routine continuous monitoring. AWS X-Ray provides distributed tracing but with less language-runtime coverage and less polished UX than Datadog APM, New Relic, or Tempo. For teams that value operational ergonomics, third-party vendors are worth the cost premium.

Amazon Managed Grafana plus Amazon Managed Service for Prometheus is the hybrid observability pattern that captures most of the third-party ergonomic benefit at AWS-native pricing. Amazon Managed Grafana costs $9 per active editor user per month and $5 per active viewer user per month, with no per-dashboard or per-data-source charges. It connects natively to CloudWatch, Amazon Managed Service for Prometheus, Amazon OpenSearch, AWS X-Ray, Athena, Timestream, and any external Prometheus-compatible source.

Amazon Managed Service for Prometheus charges per million sample ingest at $0.30 per million plus storage at $0.03 per gigabyte per month. For a typical 100-host Kubernetes workload producing 30,000 active series at 4 samples per minute, the monthly bill is roughly $5,000 in samples plus modest storage. The pricing is competitive with Grafana Cloud for the same workload (Grafana Cloud at 30,000 active series above 10K free is roughly $200 plus log and trace charges).

The hybrid pattern works well for AWS-only workloads where the team wants Grafana dashboard ergonomics without the operational burden of self-hosting. The dashboards look like Grafana, the queries are PromQL, the underlying storage is AWS-managed, and the billing is on the existing AWS account. The integration with CloudWatch as a Grafana data source means existing CloudWatch metrics and logs are queryable alongside new Prometheus metrics in unified dashboards.

The hybrid pattern is less suited to multi-cloud workloads (the AWS-managed services are AWS-only), to teams that need APM and distributed tracing as a primary observability path (Managed Grafana plus Managed Prometheus is dashboard-and-metrics oriented; APM requires X-Ray or a third-party APM vendor), and to teams that need broad pre-built dashboards out of the box (Datadog and New Relic ship hundreds of pre-built dashboards; Managed Grafana requires the team to build dashboards or import from the open-source Grafana community library).

Third-party observability vendors win for AWS workloads in three specific scenarios. First, multi-cloud or hybrid workloads where AWS is one of multiple environments. CloudWatch covers AWS only; Datadog, Grafana Cloud, and New Relic cover AWS plus GCP plus Azure plus on-premises with the same observability backend. For organisations that span multiple clouds, the unified observability backend is operationally meaningful and economically efficient versus running cloud-specific monitoring on each provider.

Second, workloads where APM and distributed tracing are operationally important. AWS X-Ray provides distributed tracing for AWS-instrumented applications but with narrower language-runtime support and less mature UX than Datadog APM, New Relic APM, Dynatrace, or Grafana Tempo. For microservices-heavy workloads where transaction-level visibility matters, third-party APM is meaningfully better than X-Ray.

Third, workloads where dashboard ergonomics and alert sophistication matter to operational teams. Datadog dashboards are visibly more polished than CloudWatch dashboards. Datadog and New Relic alerting is more sophisticated (alert grouping, downtime exclusion, dependency-aware alerting) than CloudWatch Alarms. For incident response teams that work in dashboards and alert workflows daily, the operational ergonomic premium of third-party vendors is worth the cost premium.

Outside these three scenarios, CloudWatch native is usually the right default for pure AWS workloads. The cost is lower, the integration is tighter, and the operational UX is adequate for non-incident-heavy workloads. The decision is rarely binary; many AWS-native teams use CloudWatch for basic logs and metrics plus a third-party vendor for APM and distributed tracing.

For new AWS workloads, the instrumentation choice has long-term cost implications that often exceed the immediate observability vendor decision. ADOT (AWS Distro for OpenTelemetry) is the AWS-supported OpenTelemetry distribution that provides pre-configured collectors and SDKs for AWS workloads. Applications instrumented with ADOT can route telemetry to CloudWatch today, Grafana Cloud tomorrow, and Datadog the day after, without rewriting application code.

The architectural choice matters because observability vendor migration is operationally substantial. Teams that instrumented applications with proprietary Datadog or New Relic SDKs face a multi-month migration project to switch vendors. Teams that instrumented with ADOT or vanilla OpenTelemetry can switch backends in a configuration change at the OTel Collector level. The vendor-neutral instrumentation preserves negotiating leverage and architectural flexibility for the long term.

ADOT-instrumented applications can route to AWS X-Ray for distributed tracing, Amazon Managed Service for Prometheus for metrics, CloudWatch Logs for logs, and any third-party vendor for any of the above. The OTel Collector becomes the routing layer that decides which backend receives which telemetry. For organisations evaluating vendor consolidation or migration, this routing flexibility is the foundation of the cost-optimisation strategy.

The trade-off is that auto-instrumentation maturity differs between vendor-specific agents and OpenTelemetry SDKs. Datadog APM auto-instrumentation tends to capture more telemetry out of the box than ADOT or vanilla OTel for the same application. The gap has narrowed dramatically since 2023 with OTel community investment but is not yet zero. For teams that prioritise time-to-value over vendor independence, vendor-specific instrumentation is faster initially. For teams that prioritise long-term flexibility, ADOT is the right choice.