Amazon CloudWatch Adds Native OpenTelemetry Metric Ingestion and PromQL Support

AWS has introduced native OpenTelemetry Protocol (OTLP) metric ingestion and Prometheus Query Language (PromQL) querying directly within Amazon CloudWatch. The capability includes a dedicated high-cardinality metric store supporting up to 150 labels per metric—a substantial increase over the legacy 30-dimension threshold of standard CloudWatch metrics—and preserves native OpenTelemetry metric instruments such as gauges, counters, and histograms without lossy transformations. Furthermore, telemetry emitted from AWS environments automatically inherits AWS resource context tags, and Amazon CloudWatch Container Insights now natively supports OTLP and Prometheus formats on Amazon EKS. For DevOps, platform engineering, and site reliability teams, this update removes one of the most stubborn architectural friction points in cloud-native monitoring: metric pipeline fragmentation. Historically, engineering teams operating microservices on Amazon EKS or ECS had to manage distinct collector pipelines, sending AWS infrastructure metrics to CloudWatch while routing high-cardinality application and pod metrics to self-hosted Prometheus or Amazon Managed Service for Prometheus. With native OTLP ingestion, teams can emit telemetry directly from standard OpenTelemetry SDKs and upstream collectors to CloudWatch via standard HTTP endpoints, eliminating custom exporters, bridge agents, and the maintenance overhead of managing dedicated scraper fleets. This development fits into the broader enterprise shift toward vendor-neutral observability standardization governed by the Cloud Native Computing Foundation (CNCF). As OpenTelemetry has become the de facto telemetry generation and transport standard across cloud providers, major hyperscalers are transitioning from proprietary metric formats to native OTLP ingestion pipelines. By coupling native OTLP ingestion with PromQL compatibility, AWS bridges the gap between the dominant open-source telemetry protocol and the industry-standard metric query syntax, allowing organizations to retain existing Prometheus dashboard queries and Grafana panels without vendor lock-in. In practice, engineering organizations should audit their current telemetry pipelines and evaluate migrating EKS and ECS workloads to the standardized OTLP gateway pattern. SREs can begin by enabling the CloudWatch Observability add-on and configuring OpenTelemetry SDKs to point directly at CloudWatch OTLP endpoints, eliminating unnecessary Prometheus exporter sidecars. However, platform teams must monitor ingestion volume and label cardinality carefully: while 150 labels provide extensive dimensionality for containerized workloads, uncontrolled attribute propagation can drive up cloud billing. Establishing centralized Collector gateway filters to sanitize and drop ephemeral attributes before upstream export remains essential for cost-efficient operations.