Introducción
Un equipo SRE que opera 40 microservicios en AWS, 15 cargas en Azure y tres agentes de IA construidos sobre LangGraph y CrewAI enfrenta un problema operativo concreto: tres dashboards distintos, dos protocolos de ingesta (CloudWatch metrics nativos y OTLP), y un gap de 12 a 18 minutos promedio para correlacionar una degradación de latencia en un endpoint con una tool invocation fallida en el agente que la consume. La fragmentación de la observabilidad no es un problema de volumen de datos, es un problema de superficie de consulta.
Amazon CloudWatch Omni, en disponibilidad general desde septiembre de 2026, ataca esa fragmentación con una arquitectura que normaliza telemetría OpenTelemetry bajo el motor de escala de CloudWatch, organiza los datos en «spaces» por equipo y aplicación, y expone una capa conversacional que traduce preguntas en lenguaje natural a consultas sobre traces, logs y métricas. No reemplaza CloudWatch: lo envuelve y lo extiende hacia observabilidad de agentes y multicloud. Para equipos que ya instrumentan con OpenTelemetry Collector, la migración es incremental; para quienes operan Azure AD o Entra ID como identidad, la integración SSO nativa elimina un salto manual.
Qué ocurrió
AWS anunció la disponibilidad general (GA) de Amazon CloudWatch Omni en tres regiones: US East (N. Virginia), US West (Oregon) y Europe (Ireland). El producto se posiciona como evolución de Amazon CloudWatch, no como servicio separado, lo que implica que conserva la base de infraestructura de ingesta, almacenamiento y alerting de CloudWatch pero introduce tres capas nuevas: spaces de observabilidad con visibilidad cross-account y cross-cloud, un motor de interacción conversacional potenciado por AWS DevOps Agent, y un workflow de evaluación dedicado a workloads de IA generativa.
La arquitectura soporta ingesta OpenTelemetry nativa (OTLP gRPC y HTTP), lo que significa que un Collector estándar puede enviar traces, métricas y logs a Omni sin agentes propietarios de AWS. Adicionalmente, Omni incluye un extension gratuito para VS Code, Cursor y Kiro que permite instrumentar, debuggear y evaluar agentes localmente sin necesidad de una cuenta AWS activa. El workflow de desarrollo de agentes opera sobre frameworks específicos: LangGraph, CrewAI, OpenAI Agents SDK, Vercel AI SDK y Strands. Cada prompt, llamada de modelo y invocación de tool se registra como span evaluable, con capacidad de ejecutar experimentos A/B sobre prompts o configuraciones antes de desplegar a producción.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos DevOps que ya operan OpenTelemetry Collector en Kubernetes o EC2, Omni elimina la necesidad de un backend separado (Grafana Tempo, Jaeger, Datadog) para correlacionar traces con métricas de infraestructura. El espacio de observabilidad centralizado cruza cuentas AWS y regiones, y —punto relevante para organizaciones con estrategia multicloud— ingiere telemetría de workloads en Azure. Esto reduce la cantidad de herramientas de observabilidad de 2-3 a una sola superficie, con un único modelo de permisos vía SSO.
Desde la perspectiva de seguridad, la arquitectura de spaces introduce un modelo de aislamiento por equipo y aplicación. Un grupo de SRE que opera el cluster de producción puede crear un space con visibilidad limitada a sus cuentas, mientras que un equipo de plataforma tiene visibilidad global. La autenticación SSO integrada con AWS IAM Identity Center (o Azure Entra ID) centraliza el control de acceso. El extension local para IDE no requiere credenciales AWS, lo que reduce la superficie de exposición de secrets durante desarrollo, aunque implica que la telemetría de agentes en local no se persiste en la plataforma hasta que el desarrollador elige exportarla.
Detalles técnicos
La ingesta de datos opera sobre el protocolo OpenTelemetry en sus variantes OTLP/gRPC y OTLP/HTTP. Un Collector estándar configurado con un exporter OTLP apunta a Omni sin modificaciones mayores:
exporters:
otlphttp/omni:
endpoint: https://cloudwatch-omni.us-east-1.amazonaws.com/v1/traces
headers:
Authorization: «Bearer ${AWS_ACCESS_TOKEN}»
service:
pipelines:
traces:
exporters: [otlphttp/omni]
metrics:
exporters: [otlphttp/omni]
Omni auto-descubre servicios, mapea dependencias entre ellos y calcula golden metrics (latencia, throughput, error rate, saturation) sin configuración manual por servicio. La detección de dependencias se construye sobre los atributos semánticos de OpenTelemetry (peer.service, net.peer.name) y las relaciones de parent-child en los traces.
La capa conversacional funciona sobre AWS DevOps Agent. Un usuario escribe «¿qué causó el spike de p99 en checkout-service entre las 14:00 y las 14:15 UTC?» y el sistema construye vistas dinámicas de los signals relevantes, correlaciona traces con logs y propone una hipótesis de root cause. El flujo alternativo (point-and-click) permite navegar directamente desde un golden metric degradado hasta el trace individual, el span problemático y el log asociado.
Para agentes de IA, Omni instrumenta cada invocación como un árbol de spans con jerarquía: prompt → model call → tool invocation → sub-agent call. El workflow de evaluación permite ejecutar un set de prompts de prueba contra una nueva versión del agente, comparar métricas de calidad (relevancia, latencia, token usage, tasa de tool failure) y aprobar o rechazar el cambio antes del deploy.
Las regiones de disponibilidad actuales son tres. Regiones adicionales no tienen fecha pública confirmada en el anuncio de GA.
Qué deberían hacer los administradores y equipos técnicos
Evaluar la compatibilidad con la instrumentación existente. Si el equipo ya exporta telemetría OpenTelemetry a un backend propio (Grafana, Datadog, Honeycomb), el paso inicial es configurar un exporter OTLP adicional hacia Omni sin remover el pipeline actual. Validar que los atributos semánticos del Collector (service.name, deployment.environment, cloud.region) estén presentes, porque Omni los usa para auto-descubrimiento y mapeo de dependencias.
Crear un space de prueba con visibilidad cross-account. Desde la consola de CloudWatch, navegar a Omni → Create Space. Configurar SSO con AWS IAM Identity Center (o Azure Entra ID si la organización usa Entra como IdP). Habilitar visibilidad sobre al menos dos cuentas AWS y una cuenta Azure para validar que la correlación cross-cloud funciona con los workloads reales.
Instalar el extension en el IDE del equipo de agentes. El extension para VS Code, Cursor o Kiro es gratuito y no requiere cuenta AWS. Los desarrolladores de agentes en LangGraph o CrewAI deberían instalarlo en sus entornos de desarrollo para instrumentar localmente y validar que los spans de tool invocation y model call se generan correctamente antes de conectar el pipeline de producción.
Revisar el modelo de permisos por space. Antes de habilitar Omni en producción, definir qué equipos acceden a qué spaces. Un space que expone telemetría de un workload con datos sensibles (PII en logs, secrets en attributes de spans) debe tener SSO con MFA obligatorio y roles IAM restrictivos. No asignar acceso «Reader» global al space de producción.
Monitorear el consumo de ingesta y almacenamiento. Omni cobra por volumen de datos ingeridos y consultados. Equipos que hoy exportan a un backend de OpenTelemetry con retención de 7 días deben calcular el impacto en costos si Omni mantiene 30 días por defecto. Revisar la página de pricing de CloudWatch Omni antes de migrar pipelines de alto volumen (>10 GB/día de logs).
Conclusión
CloudWatch Omni no introduce un protocolo nuevo ni obliga a reescribir instrumentación. Su valor concreto para equipos de infraestructura y SRE está en reducir el número de superficies de consulta de 2-3 a 1, cruzar AWS y Azure en un mismo modelo de datos, y habilitar troubleshooting conversacional sobre traces que ya existen. Para equipos que desarrollan agentes de IA, el workflow de evaluación por prompt y tool invocation es un capability que antes requería armar con LangSmith, Braintrust o herramientas equivalentes. La limitación actual es la disponibilidad en tres regiones y la dependencia de la infraestructura CloudWatch para almacenamiento y consulta. Equipos con requisitos de data residency estrictos fuera de esas tres regiones deben esperar la expansión geográfica antes de planificar una migración completa.
Fuentes
- https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-cloudwatch-omni-ai/