Introducción
Los equipos que operan Kubernetes en cloud suelen convivir con una arquitectura de observabilidad fragmentada: métricas de infraestructura en CloudWatch, métricas de aplicación en backends Prometheus, y capas de exportación para cruzar ambos mundos. Ese diseño funciona, pero introduce más componentes, más puntos de falla y más costo operativo.
En este contexto, AWS anunció una capacidad en preview para Amazon CloudWatch: ingesta nativa de métricas OpenTelemetry (OTLP) y consultas con PromQL. Para equipos de plataforma, esto no es solo una mejora de UX. Es un cambio de arquitectura que puede simplificar pipelines métricos completos, especialmente en EKS y entornos con alta cardinalidad.
Qué ocurrió
En su blog técnico del 3 de abril de 2026, AWS presentó soporte de OpenTelemetry y PromQL en CloudWatch. Según la publicación, CloudWatch puede recibir métricas OTLP a través de un endpoint regional, conservar tipos de métricas de OTel (como counters, gauges e histogramas) y permitir consultas PromQL desde CloudWatch y Amazon Managed Grafana.
El anuncio también destaca dos capacidades prácticas: soporte de hasta 150 labels por métrica para series OTLP y enriquecimiento automático con contexto de AWS (cuenta, región, identificadores de recursos y tags). La propuesta es reducir la necesidad de exportadores o etiquetas manuales para correlacionar datos entre servicios y workloads.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos DevOps y SRE, el impacto principal está en el plano operativo. Una parte relevante de la complejidad diaria en observabilidad viene de mantener collectors, exporters, reglas de scraping, transformaciones de labels y mecanismos de federación entre sistemas. Si CloudWatch absorbe OTLP y además permite PromQL, parte de esa complejidad se mueve a una capa gestionada.
En cloud e infraestructura, la ventaja potencial es una mejor correlación entre métricas de aplicaciones y metadatos de recursos AWS. Esto facilita consultas por entorno, cuenta, región o etiqueta sin depender de convenciones manuales de instrumentación.
Desde seguridad y compliance, una arquitectura más unificada también ayuda. Menos componentes de integración suelen traducirse en menor superficie de exposición, menos secretos distribuidos y rutas de auditoría más claras para métricas críticas del negocio.
Detalles técnicos
El cambio se apoya en tres piezas técnicas:
- Endpoint OTLP regional en CloudWatch para enviar métricas desde SDKs y collectors compatibles.
- Store de alta cardinalidad para series ingestadas vía OTel, con límite superior de labels más amplio que el esquema clásico de métricas custom.
- Capa de consulta PromQL sobre esos datos, reutilizable desde interfaces de CloudWatch y Managed Grafana.
Para Kubernetes, el punto relevante es que Container Insights también entra en la narrativa: AWS muestra cómo usar EKS + Container Insights y luego consultar datos con PromQL. Esto reduce fricción para equipos que ya operan Prometheus y no quieren cambiar lenguaje de consulta o paneles de troubleshooting.
Aun así, hay matices importantes. El feature está en preview, por lo que conviene validar límites reales, costos por volumen/serie, latencias de consulta y comportamiento de cardinalidad bajo carga real. También hay que revisar el modelo de retención y la portabilidad de dashboards para evitar lock-in accidental.
Qué deberían hacer los administradores o equipos técnicos
- Inventariar el pipeline actual de métricas: collectors, exporters, costos y puntos de dolor.
- Identificar workloads candidatos en EKS con alta cardinalidad donde PromQL ya sea estándar interno.
- Probar en entorno no productivo la ingesta OTLP y verificar enriquecimiento automático de metadatos AWS.
- Comparar consultas y alertas existentes entre backend actual y CloudWatch (exactitud, latencia, costo).
- Definir guardrails de cardinalidad, naming y tags antes de migrar más equipos.
- Migrar por etapas: primero servicios internos, luego componentes críticos con rollback documentado.
- Actualizar runbooks de incidentes para reflejar el nuevo flujo de diagnóstico.
Conclusión
La llegada de OTLP + PromQL a CloudWatch apunta a un problema real de operaciones: la fragmentación de observabilidad en entornos cloud-native. Si la capacidad madura como promete, muchos equipos podrán simplificar arquitectura, reducir piezas de integración y acelerar troubleshooting sin renunciar a PromQL.
La oportunidad está en adoptar con criterio: pruebas controladas, métricas de costo/rendimiento y transición gradual. Para ingeniería de plataforma, el valor no está en “migrar por novedad”, sino en medir si esta unificación mejora confiabilidad operativa y tiempo de respuesta ante incidentes.
Fuentes
https://aws.amazon.com/blogs/mt/introducing-opentelemetry-promql-support-in-amazon-cloudwatch/
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-metrics.html
https://www.cncf.io/projects/opentelemetry/