AWS CloudWatch OTLP adds 150 labels

CloudWatch just made a very specific observability problem less painful. Modern agent systems and microservices throw off a mess of telemetry — spans, retries, tool calls, queue hops, model names, tenant IDs, workflow steps. The old CloudWatch custom-metric model was a bad fit for that shape of data because it capped you at 30 dimensions. On April 2, 2026, AWS put native OpenTelemetry metrics support into public preview, and the headline feature is support for up to 150 labels per metric, sent directly over OTLP and queried with PromQL. ### What actually changed? AWS added native OTLP metrics ingestion to CloudWatch, so metrics no longer need custom conversion into the older CloudWatch metric format before they land. That completes AWS’s OpenTelemetry story across metrics, logs, and traces in CloudWatch. The preview also includes PromQL querying in CloudWatch and a new Query Studio for building queries, alarms, and dashboards around those OTLP metrics. ### Why does 150 labels matter? Because “150 labels” is really shorthand for “you can keep the context.” OpenTelemetry metrics carry labels instead of the old namespace-plus-dimensions model. CloudWatch’s docs now spell out that OTLP metrics support up to 150 labels per metric, while traditional custom metrics top out at 30 dimensions. In practice, the name, or workflow step attached to the same signal instead of flattening or dropping them. ### Why are agent systems the obvious use case? Agent workflows are distributed systems wearing an AI costume. One user request can fan out into planner calls, retrieval, tool execution, model retries, async jobs, and downstream microservices. If you cannot preserve correlation metadata across those hops, you get a trace that looks fine but tells the feature lines up neatly with that problem because high-cardinality labels are exactly what these systems generate. That last part is an inference from the product design and the workloads AWS names — Kubernetes, microservices, and OpenTelemetry-heavy environments. ### How does this fit with traces? Metrics are only half the story. CloudWatch already accepted traces and logs through OTLP endpoints, and Application Signals gives an application-centric view of services, dependencies, and edges. So the new piece is not “CloudWatch can finally do tracing.” The new piece is that OTLP metrics can now sit next to traces and move you from “this request was slow” to “this workflow step in this service for this tenant was expensive and slow.” ### What about Kubernetes? Kubernetes is where the label expansion gets very concrete. AWS’s new OTel-based Container Insights preview for EKS says each metric can be enriched with up to 150 descriptive labels, including Kubernetes metadata and customer-defined labels like team, application, or business unit. That is a strong hint about where AWS will take CloudWatch next. ### Is there a catch? Yes — more labels are useful, but they also create more cardinality, more query complexity, and more chances to instrument nonsense. Rich telemetry only helps if teams standardize naming, propagation, and sampling. OpenTelemetry gives the common language, but it does not save you from sloppy schema design. CloudWatch is basically removing a platform constraint, not the operational discipline problem. ### So what’s the bottom line? The news is not just “CloudWatch adds more labels.” The