→ Back to Home
Observability

AWS Adds Native OpenTelemetry Metrics and PromQL Ingestion to Amazon CloudWatch

Amazon Web Services has expanded Amazon CloudWatch by introducing native metric ingestion via the OpenTelemetry Protocol (OTLP) alongside native support for the Prometheus Query Language (PromQL). The feature introduces a dedicated high-cardinality metrics store capable of supporting up to 150 labels per metric—a substantial increase over CloudWatch's traditional 30-dimension ceiling for custom metrics. With this addition, CloudWatch completes native support across all three core observability signals (traces, logs, and metrics) through standard OTLP endpoints without requiring custom intermediate translation agents or metric truncation. For Site Reliability Engineers (SREs) and platform architects, this release resolves a persistent architectural dilemma: balancing vendor-neutral telemetry standards against the operational simplicity of native cloud monitoring. Previously, teams adopting OpenTelemetry had to run complex sidecars or external collectors to reshape high-cardinality metrics into CloudWatch-compatible formats or maintain separate, self-hosted Prometheus backends. Supporting direct OTLP metrics ingestion and 150-dimension metadata eliminates these ingestion bottlenecks, preserving rich contextual data like pod names, commit hashes, and ephemeral container IDs directly in CloudWatch. This move aligns with the broader industry transition toward vendor-neutral observability backends standardized around CNCF projects. Over the past several years, OpenTelemetry has become the de facto wire standard for distributed systems instrumentation, while PromQL remains the dominant query dialect for containerized and Kubernetes environments. Major cloud providers and enterprise APM vendors have shifted from proprietary collectors toward open ingestion pipelines. CloudWatch's native PromQL support validates PromQL as a multi-vendor analytics query standard, reducing cognitive friction for engineers transitioning between Grafana dashboards, self-hosted Prometheus clusters, and managed cloud infrastructure. In practice, DevOps teams can now streamline their telemetry architecture by pointing standard OpenTelemetry Collectors directly to regional CloudWatch OTLP endpoints. Platform engineers can reuse existing PromQL alerting rules and visualization queries across both Amazon Managed Grafana and CloudWatch consoles without rewrite penalties. However, teams must monitor ingestion costs carefully: storing high-cardinality metrics with up to 150 labels per metric series can rapidly escalate cloud spend if granular labels are attached indiscriminately. Organizations should implement robust metric filtering at the collector level to balance rich contextual visibility against storage and query overhead.
#observability#opentelemetry#promql#cloudwatch#devops
Read original source