CloudWatch Adds Native OpenTelemetry Metrics and PromQL to Unify Hybrid Telemetry

Amazon CloudWatch has expanded its OpenTelemetry integration by adding native metric ingestion via the OpenTelemetry Protocol (OTLP) alongside Prometheus Query Language (PromQL) querying capabilities. This launch completes CloudWatch's support for open standards across logs, traces, and metrics through a single ingest pipeline. The updated metrics engine introduces a high-cardinality storage tier capable of indexing up to 150 labels per data point—a substantial increase over the 30-dimension boundary in classic CloudWatch custom metrics—backed by automatic AWS resource metadata enrichment and a per-gigabyte ingestion pricing model that includes 15 months of retention. For platform engineers, DevOps practitioners, and SRE teams, this development addresses a long-standing architectural compromise in cloud monitoring. Previously, organizations operating microservices on Amazon EKS or hybrid environments frequently maintained dual telemetry systems: dedicated Prometheus or VictoriaMetrics clusters for rich, multi-dimensional application telemetry, and CloudWatch for AWS infrastructure services. Correlating data across both domains often required custom metric exporters, metric streams, or continuous GetMetricData API calls, introducing latency and increasing costs. By introducing PromQL querying directly in the CloudWatch console and exposing a Prometheus-compatible query API, teams can correlate metrics across more than 70 AWS services and custom workloads in a unified workflow. This move fits into a broader cloud observability trend where major hyperscalers are aligning their native toolchains with open-source specifications rather than proprietary agents. As OpenTelemetry establishes itself as the industry standard for telemetry collection and Prometheus semantics dominate container monitoring, cloud providers are integrating these protocols directly into managed platforms. The transition acknowledges that modern engineering organizations prioritize portable instrumentation and single-pane observability over vendor-locked agent ecosystems. In practice, engineering teams should assess opportunities to simplify their observability footprint by routing application metrics directly to regional OTLP endpoints via the AWS Distro for OpenTelemetry or OpenTelemetry Collector pipelines. However, teams must account for key implementation details: classic CloudWatch metric math cannot be combined within PromQL queries, and PromQL-based alarms operate independently from classic metric alarms. SREs should evaluate telemetry volume under the per-GB ingestion pricing model, audit label hygiene to prevent unexpected high-cardinality spikes, and leverage automatic AWS resource tagging to streamline cross-account querying.