Cloud Infraestructura Observabilidad Seguridad

AWS CloudWatch adopta métricas nativas de OpenTelemetry con PromQL y facturación por GB

PorGustavo

Jun 16, 2026 #AWS, #Cloud, #Grafana, #OpenTelemetry, #Prometheus

Introducción

Hasta ahora, los equipos que querían centralizar métricas de aplicaciones personalizadas junto con datos nativos de AWS tenían que elegir entre soluciones fragmentadas o puentes adicionales. Con la reciente actualización de CloudWatch, AWS cierra esa brecha al soportar nativamente el envío de métricas vía OpenTelemetry Protocol (OTLP) y su consulta con PromQL. Esto no solo simplifica la arquitectura, sino que también permite facturar por gigabyte de datos ingestados, un cambio clave para equipos con volúmenes variables.

El anuncio oficial, publicado en junio de 2026, destaca que esta integración está disponible en todas las regiones comerciales de AWS, excepto en Middle East (UAE), Middle East (Bahrain) e Israel (Tel Aviv). Para equipos acostumbrados a herramientas como Prometheus, Grafana o OpenTelemetry, la novedad es que CloudWatch ahora expone una API de consultas compatible con Prometheus, eliminando la necesidad de adaptadores adicionales.

Qué ocurrió

AWS añadió soporte nativo para métricas OpenTelemetry en CloudWatch, lo que permite a los equipos enviar datos mediante OTLP y consultarlos con PromQL. Según el comunicado oficial, esta actualización incluye:

Ingestión de métricas vía OTLP sin necesidad de agentes intermediarios.
Consulta de métricas usando PromQL, mediante una API compatible con Prometheus.
Almacenamiento de 15 meses de datos sin costo adicional por retención.
Facturación por GB de métricas ingestadas, con precios detallados en la página de precios de CloudWatch.

La integración permite consolidar métricas personalizadas de aplicaciones y métricas nativas de más de 70 servicios AWS en una sola plataforma, consultables en conjunto con PromQL. Esto es relevante para equipos que ya usan OpenTelemetry, Prometheus o Grafana, ya que CloudWatch actúa ahora como un destino compatible sin cambios en sus flujos de trabajo actuales.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps e Infraestructura

La principal ventaja es la consolidación de observabilidad: antes, los equipos debían gestionar múltiples destinos para métricas personalizadas (OpenTelemetry, Prometheus) y métricas nativas de AWS (CloudWatch Metrics). Ahora, todas las métricas pueden centralizarse en CloudWatch, reduciendo complejidad operativa. Además, la API PromQL simplifica las consultas, ya que equipos acostumbrados a Prometheus no necesitan aprender un nuevo lenguaje de consultas.

En términos de costos, la facturación por GB de ingestión es un cambio significativo frente al modelo tradicional de CloudWatch, que cobraba por métricas almacenadas. Según la documentación de precios, el costo por GB varía según la región, pero en general es menor que el modelo anterior para equipos con alto volumen de métricas. Por ejemplo, en la región US East (N. Virginia), el costo es de $0.30 por GB para métricas ingestadas (precio aproximado al lanzamiento).

Para escalabilidad, CloudWatch ahora maneja métricas de aplicaciones personalizadas y de servicios AWS en un mismo espacio de nombres, lo que facilita la creación de dashboards unificados y alertas centralizadas. Esto es especialmente útil para equipos que operan entornos híbridos o multi-cloud, donde la observabilidad era un desafío.

Para equipos de Seguridad

Desde la perspectiva de seguridad, la centralización de métricas en CloudWatch puede simplificar la auditoría y monitoreo de anomalías. Sin embargo, hay que considerar que:

Exposición de datos: Al centralizar métricas en una sola plataforma, se amplía el vector de ataque potencial si hay configuraciones incorrectas en permisos (IAM).
Compliance: Equipos de seguridad deben asegurar que los datos ingestados cumplan con políticas de retención y cifrado. CloudWatch ofrece cifrado en tránsito (TLS 1.2+) y en reposo (AES-256), pero la configuración es responsabilidad del equipo.
Monitoreo de accesos: AWS recomienda configurar alertas en CloudWatch para detectar accesos no autorizados a métricas, especialmente en regiones donde no está disponible esta integración.

Detalles técnicos

Componentes afectados

Amazon CloudWatch: Versión mínima requerida: CloudWatch Agent 1.30.0 o superior para soporte de OTLP.
OpenTelemetry Collector: Versión 0.90.0 o superior para envío de métricas vía OTLP.
API de consultas: CloudWatch expone un endpoint compatible con Prometheus, accesible en la ruta /api/v1/query (ejemplo: https://monitoring.<region>.amazonaws.com/prometheus/api/v1/query).

Vectores de integración

Para enviar métricas a CloudWatch vía OTLP, los equipos pueden configurar el OpenTelemetry Collector con el siguiente ejemplo de configuración:

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:

exporters:
  awsemrmetrics:
    region: us-east-1
    namespace: "CustomMetrics"
    resource_to_telemetry_conversion:
      enabled: true

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [awsemrmetrics]

En este ejemplo:

El receptor otlp escucha métricas en formato OTLP (gRPC o HTTP).
El procesador batch agrupa métricas antes de enviarlas.
El exportador awsemrmetrics envía los datos a CloudWatch, con un namespace personalizado (CustomMetrics).

Consultas con PromQL

CloudWatch ahora soporta consultas PromQL mediante una API compatible con Prometheus. Por ejemplo, para consultar la suma de métricas de latencia en los últimos 5 minutos:

curl -G "https://monitoring.us-east-1.amazonaws.com/prometheus/api/v1/query" \
  --data-urlencode 'query=sum(rate(http_request_duration_seconds_sum[5m]))' \
  --data-urlencode 'time=2026-06-15T12:00:00Z' \
  -H "Authorization: AWS4-HMAC-SHA256 Credential=<ACCESS_KEY>/20260615/us-east-1/monitoring/aws4_request, SignedHeaders=host;x-amz-date, Signature=<SIGNATURE>"

Nota: El endpoint requiere autenticación AWS Signature v4, igual que las APIs tradicionales de CloudWatch.

Límites y consideraciones

Límite de ingestión: CloudWatch permite hasta 1 millón de métricas por cuenta por región. Si se supera este límite, las métricas adicionales se rechazan.
Latencia: La ingestión vía OTLP tiene una latencia de ~1 segundo para métricas procesadas, según pruebas internas de AWS.
Almacenamiento: Los datos se retienen por 15 meses sin costo adicional. Después de este período, se aplican cargos por retención extendida.

Qué deberían hacer los administradores y equipos técnicos

1. Actualizar componentes

OpenTelemetry Collector: Actualizar a la versión 0.90.0 o superior para soporte de OTLP.

  docker pull otel/opentelemetry-collector:0.90.0

CloudWatch Agent: Verificar que la versión del agente sea 1.30.0 o superior.

  aws cloudwatch list-metrics --query 'metrics[0].Namespace' --output text

Si el comando falla o devuelve un mensaje de error, actualizar el agente:

  sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json -s

2. Configurar OTLP en el OpenTelemetry Collector

Crear un archivo de configuración otel-config.yaml con el siguiente contenido:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

exporters:
  logging:
    loglevel: debug
  awsemrmetrics:
    region: ${AWS_REGION}
    namespace: "AppMetrics"
    resource_to_telemetry_conversion:
      enabled: true

service:
  pipelines:
    metrics:
      receivers: [otlp]
      exporters: [awsemrmetrics, logging]

Iniciar el collector:

docker run -d --name otel-collector \
  -v $(pwd)/otel-config.yaml:/etc/otel-config.yaml \
  -e AWS_REGION=us-east-1 \
  -p 4317:4317 -p 4318:4318 \
  otel/opentelemetry-collector:0.90.0 \
  --config=/etc/otel-config.yaml

3. Validar ingestión de métricas

Verificar que las métricas se estén enviando correctamente:

aws cloudwatch get-metric-data \
  --metric-data 'MetricName="http_request_duration_seconds",Namespace="AppMetrics"' \
  --start-time $(date -u -d "5 minutes ago" +%Y-%m-%dT%H:%M:%SZ") \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ") \
  --query 'MetricDataResults[0].Values' \
  --output text

Si el comando devuelve valores, la ingestión está funcionando.

4. Configurar consultas con PromQL

Para usar PromQL, configurar Grafana o Prometheus para apuntar a la API de CloudWatch:

# Ejemplo para Prometheus (prometheus.yml)
remote_write:
  - url: "https://monitoring.us-east-1.amazonaws.com/prometheus/api/v1/write"
    basic_auth:
      username: ${AWS_ACCESS_KEY_ID}
      password: ${AWS_SECRET_ACCESS_KEY}

Nota: Para autenticación, usar AWS Signature v4. Herramientas como prometheus-remote-write-aws pueden simplificar este paso.

5. Revisar costos y permisos

IAM: Asegurar que el rol o usuario tenga permisos cloudwatch:PutMetricData y cloudwatch:GetMetricData.

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "cloudwatch:PutMetricData",
          "cloudwatch:GetMetricData"
        ],
        "Resource": "*"
      }
    ]
  }

Monitoreo de costos: Configurar alertas en AWS Cost Explorer para detectar picos en la ingestión de métricas.
Retención de datos: Revisar que los datos se almacenen por 15 meses y configurar políticas de borrado automático si es necesario.

Conclusión

La integración nativa de OpenTelemetry métricas en CloudWatch con soporte para PromQL y facturación por GB es un avance significativo para equipos que buscan simplificar su observabilidad. Al centralizar métricas personalizadas y de servicios AWS en una sola plataforma, se reduce la complejidad operativa y se alinean los costos con el volumen real de datos. Sin embargo, los equipos deben actualizar sus componentes, validar la ingestión y monitorear los costos para evitar sorpresas.

Para equipos que ya usan Prometheus o Grafana, esta actualización es casi transparente: solo necesitan configurar CloudWatch como destino de métricas y aprovechar la API PromQL. Para otros, es una oportunidad para consolidar sus herramientas y reducir la deuda técnica.