CloudWatch Adds Native OpenTelemetry Metrics and PromQL, Dismantling Cloud Monitoring Silos

Amazon Web Services expanded Amazon CloudWatch with native ingestion for OpenTelemetry Protocol (OTLP) metrics, coupled with native PromQL query support and per-gigabyte pricing. The launch completes CloudWatch support across all three core telemetry pillars—metrics, logs, and traces—enabling direct transmission of telemetry using open standards. Users can now ingest high-cardinality custom metrics from application runtimes and hybrid environments, combining them with over 70 native AWS vended metrics streams within a single Prometheus-compatible query interface. For enterprise infrastructure operators, this development eliminates a long-standing operational tax: maintaining translation proxies or parallel monitoring pipelines. Previously, utilizing standard Prometheus or OpenTelemetry instrumentation required either self-hosting Prometheus collectors and Thanos clusters or deploying third-party APM agents. By exposing a native PromQL query API and accepting OTLP directly, CloudWatch lets DevOps teams query infrastructure metrics and application performance data in one place using industry-standard tooling like Grafana dashboards and existing PromQL alerts. This move highlights the broader industry shift toward OpenTelemetry as the universal telemetry standard in cloud-native computing. Over the past several years, proprietary SDKs have gradually taken a backseat as major hyper-scalers adapted their architectures to accommodate open-source instrumentation and standardized protocols. Cloud providers are increasingly competing on storage efficiency, correlation capabilities, and query performance rather than vendor-locked data collection agents. CloudWatch adopting PromQL and OTLP mirrors similar developments across the observability ecosystem, where open standards govern data ingestion and transport. In practice, engineering organizations should audit their current telemetry pipelines to identify redundant exporters and agents. Development teams can adopt OpenTelemetry SDKs uniformly across their services without needing distinct metric formats for cloud-native versus on-premises deployments. However, practitioners must evaluate the cost implications of the new per-gigabyte ingestion model against existing CloudWatch custom metric pricing, particularly for high-cardinality containerized workloads where unconstrained label cardinality could escalate telemetry volume.