AWS Integrates Native OpenTelemetry Metrics and PromQL into Amazon CloudWatch

AWS has made native OpenTelemetry Protocol (OTLP) metrics ingestion and Prometheus Query Language (PromQL) querying generally available within Amazon CloudWatch. The capability introduces a high-cardinality metrics store capable of ingesting and preserving native OpenTelemetry metric types—including counters, gauges, histograms, and up-down counters—with support for up to 150 labels per metric, well beyond CloudWatch's traditional 30-dimension threshold. Furthermore, CloudWatch automatically enriches incoming OTLP telemetry with AWS resource context such as account IDs, regions, and cluster ARNs, while enabling engineers to query infrastructure and application metrics directly via PromQL in CloudWatch Query Studio and Amazon Managed Grafana. This development is significant because it eliminates a persistent architectural compromise in modern cloud-native observability. Historically, teams running containerized microservices on Amazon Elastic Kubernetes Service (EKS) were forced to operate two separate metrics stacks: CloudWatch for underlying cloud infrastructure and a dedicated Prometheus backend to capture label-dense container and application telemetry. Bridging these environments typically required running Prometheus CloudWatch exporters and executing repeated GetMetricData API calls, introducing infrastructure maintenance overhead, API polling costs, and query latency. Unifying these workflows under CloudWatch's native OTLP ingestion allows engineering organizations to standardize instrumentation on open CNCF standards while retaining single-pane-of-glass operational visibility. Contextually, this launch completes CloudWatch's multi-year pivot toward native OpenTelemetry support across all three core observability signals—traces, logs, and metrics. As OpenTelemetry solidifies its position as the universal instrumentation standard across the cloud industry, major cloud providers and monitoring vendors are shifting their competitive advantage away from proprietary telemetry collection agents toward backend processing speed, cardinality scale, and unified analysis. AWS betting natively on PromQL also reflects the industry-wide entrenchment of Prometheus querying standards for time-series data. In practice, engineering teams should evaluate their existing telemetry ingestion costs and pipeline complexity against CloudWatch's OTLP endpoints. Practitioners running EKS can deploy the CloudWatch Observability add-on to immediately capture standardized Container Insights metrics alongside custom application telemetry instrumented via OpenTelemetry SDKs. Organizations should review alert rules and dashboard definitions to begin migrating proprietary metric math queries to portable PromQL expressions, easing future cross-platform interoperability across Grafana and CloudWatch consoles.