CloudWatch Metric Streams y OpenTelemetry: observabilidad moderna en AWS sin vendor lock-in

La observabilidad en AWS tiene un problema silencioso que muchos equipos no detectan hasta que ya duele: cuanto más crece la infraestructura, más cara y frágil se vuelve la monitorización tradicional. Más llamadas a la API de CloudWatch, más riesgo de throttling, más coste de herramientas de terceros y, paradójicamente, menos visibilidad real de lo que pasa en producción.

La solución no es comprar más licencias ni añadir más exporters. Es repensar el modelo desde la base: dejar de ir a buscar métricas y empezar a recibirlas. Eso es exactamente lo que permite la combinación de CloudWatch Metric Streams, Amazon Data Firehose, AWS Lambda y un OpenTelemetry Collector corriendo dentro de tu VPC.

El problema real que resuelve esta arquitectura

Muchas empresas llegan a un punto en el que su sistema de monitorización funciona, pero de forma cada vez más costosa e ineficiente. El patrón es siempre parecido: se usa una herramienta de terceros para recoger métricas de CloudWatch mediante scraping, lo que genera un flujo constante de llamadas a la API de GetMetricData.

Con el tiempo, eso produce throttling, gaps de datos en alertas críticas y facturas de observabilidad que crecen más rápido que la propia infraestructura. Además, los datos quedan atrapados en una plataforma concreta, con exportaciones difíciles y migraciones todavía más complicadas.

• Throttling de API cuando el scraping es demasiado frecuente o el número de métricas crece.
• Latencia alta para alertas porque el sistema consulta cada cierto intervalo, no cuando ocurren los eventos.
• Vendor lock-in cuando los datos de observabilidad solo existen dentro de una plataforma propietaria.
• Coste descontrolado conforme escalan las cuentas, servicios y regiones monitorizadas.

Esta arquitectura ataca los cuatro problemas a la vez: elimina el polling agresivo, baja la latencia, rompe el lock-in y ofrece un modelo de costes mucho más predecible.

Push vs Pull: por qué importa el modelo

En monitorización tradicional, el modelo pull domina. Prometheus es el ejemplo más claro: va a buscar métricas periódicamente haciendo scraping de endpoints. Funciona bien a pequeña escala, pero tiene un techo claro en entornos grandes o muy dinámicos.

El modelo push invierte esa lógica. En lugar de preguntar "¿qué métricas tienes ahora mismo?", el sistema emite los datos en cuanto se generan. No hay polling, no hay intervalos fijos, no hay llamadas repetidas. Los datos llegan cuando ocurren los eventos, lo que permite alertas verdaderamente en tiempo real.

CloudWatch Metric Streams implementa el modelo push de forma nativa dentro de AWS. No necesitas escribir código, configurar exporters ni gestionar intervalos de scraping. El servicio emite las métricas hacia un destino en cuanto están disponibles, con latencia sub-minuto.

Los cuatro bloques de la arquitectura

La solución se apoya en cuatro componentes que trabajan juntos de forma muy limpia. Cada uno tiene una responsabilidad clara, y la integración entre ellos es lo que hace que el conjunto funcione.

• CloudWatch Metric Streams: el origen. Emite métricas de CloudWatch en tiempo real hacia Amazon Data Firehose. Soporta filtrado por namespace para enviar solo lo que interesa, y puede generar el stream en formato JSON u OpenTelemetry nativo.
• Amazon Data Firehose: el gestor del stream. Recibe las métricas, las bufferiza y puede invocar una función Lambda sincrónicamente para transformar o redirigir los datos antes de la entrega final. También actúa como red de seguridad: si el destino falla, puede volcar los datos en un bucket S3.
• AWS Lambda: el puente crítico. Aquí está el corazón del diseño. Firehose no puede entregar métricas a endpoints HTTP privados dentro de una VPC. Lambda sí puede, porque se despliega dentro de la VPC y alcanza el Network Load Balancer interno. Lambda recibe el batch de métricas, puede enriquecerlas o filtrarlas, y las empuja al collector.
• OpenTelemetry Collector: el procesador y exportador. Corre en la subred privada, recibe las métricas, aplica la lógica de procesamiento (filtros, batching, enriquecimiento con metadatos) y las exporta hacia uno o varios backends. Un Network Load Balancer distribuye el tráfico entre instancias del collector para garantizar disponibilidad.

Por qué Lambda es la pieza que hace posible todo

La limitación técnica que esta arquitectura resuelve es concreta: Amazon Data Firehose solo puede enviar datos a endpoints HTTP accesibles públicamente. Si tu OpenTelemetry Collector corre en una subred privada, Firehose no puede llegar hasta él directamente.

La función de data transformation de Firehose es el mecanismo que lo soluciona. Firehose bufferiza los datos entrantes y llama a Lambda de forma síncrona antes de intentar la entrega final. Esa Lambda está desplegada dentro de la VPC, puede hablar con el Network Load Balancer interno, y desde ahí los datos llegan al collector.

Pero Lambda no es solo un workaround para un problema de red. En esta arquitectura puede hacer trabajo real de valor:

• Filtrar métricas antes de que lleguen al collector para reducir volumen y coste.
• Enriquecer datos añadiendo etiquetas de cuenta, región o entorno.
• Transformar formatos si el collector espera un esquema específico.
• Gestionar reintentos cuando el collector no responde correctamente.
• Aplicar lógica de routing para enviar métricas distintas a collectors distintos.

OpenTelemetry Collector: más que un simple receptor

El OpenTelemetry Collector es mucho más que un endpoint que recibe datos. Es una pieza de infraestructura de observabilidad que procesa, transforma y distribuye telemetría hacia múltiples destinos de forma configurable.

Trabaja con tres bloques internos que funcionan en pipeline:

• Receivers: aceptan datos en diferentes formatos (OTLP, Prometheus, Jaeger, Zipkin...) y los traducen al modelo interno de OpenTelemetry.
• Processors: transforman los datos mientras fluyen. Pueden filtrar métricas innecesarias, aplicar batching para mejorar rendimiento, añadir atributos de Kubernetes o enmascarar información sensible.
• Exporters: envían los datos procesados hacia los backends de observabilidad. El mismo pipeline puede exportar a Grafana Cloud, Amazon Managed Prometheus, AWS X-Ray, Amazon OpenSearch, Honeycomb o Lightstep, simultáneamente si hace falta.

Esta separación en tres bloques es lo que convierte a OpenTelemetry en un estándar real y no en otra herramienta más. Si mañana la empresa decide cambiar de Grafana a otro backend, solo hay que cambiar el exporter. La instrumentación, el collector y el pipeline de datos no cambian.

El bucket S3 como red de seguridad

La arquitectura incluye un bucket Amazon S3 como destino secundario de Firehose. Dado que Lambda intercepta los datos y los envía directamente al collector, en condiciones normales no llegan métricas al bucket S3 y por tanto no genera coste adicional de almacenamiento. El bucket existe como destino de fallback: si Lambda falla o devuelve errores a Firehose, los datos pueden caer ahí para no perderse.

Es un mecanismo de durabilidad, no de flujo principal. Un buen diseño de observabilidad siempre contempla qué pasa cuando una pieza del pipeline falla.

Seguridad: por qué tiene sentido mantener el collector en la VPC

Colocar el OpenTelemetry Collector dentro de una subred privada no es solo una preferencia técnica. En entornos enterprise o sectores regulados, es un requisito real. Los collectors reciben información sensible: nombres de servicios internos, métricas de negocio, patrones de tráfico, topologías de red. Exponer ese endpoint públicamente añade superficie de ataque innecesaria.

• Security Groups controlan exactamente qué tráfico puede alcanzar el collector.
• Subredes privadas evitan exposición directa desde internet.
• IAM gestiona qué puede hacer Lambda y qué puede escribir en el collector.
• TLS en tránsito protege los datos mientras viajan por el pipeline.
• CloudTrail y CloudWatch Logs para auditoría y trazabilidad del propio sistema de observabilidad.

Network Load Balancer: disponibilidad y escalado horizontal

El Network Load Balancer opera a nivel de transporte y distribuye tráfico TCP hacia las instancias del collector. En producción, esto significa que puedes tener varios collectors corriendo en paralelo, en diferentes Availability Zones, sin que Lambda necesite saber cuántos hay.

Si un collector falla, el NLB deja de enviarle tráfico automáticamente. Si el volumen de métricas crece, se añaden más instancias y el NLB las incorpora sin cambios en Lambda ni en Firehose.

Dónde puede correr el collector en producción

El caso base describe el collector en instancias Amazon EC2 dentro de subredes privadas. Pero en una arquitectura más madura también puede ejecutarse en:

• Amazon ECS como servicio containerizado con auto scaling basado en carga.
• Amazon EKS como DaemonSet o Deployment dentro del clúster de Kubernetes.
• EC2 Auto Scaling Group para alta disponibilidad automática y reposición de instancias.
• Entornos híbridos conectados a AWS mediante VPN o Direct Connect, para centralizar métricas cloud y on-premise en el mismo pipeline.

Casos de uso donde esta arquitectura tiene más sentido

• Entornos multi-account: centralizar métricas de docenas de cuentas AWS en un único pipeline sin multiplicar herramientas.
• Equipos SRE con SLOs exigentes: alertas en tiempo real cuando el polling de cada minuto ya no es suficiente.
• Sectores regulados: cuando los datos de observabilidad no pueden salir de la red privada.
• Organizaciones que migran de herramientas propietarias: recuperar control sobre los datos y reducir costes de licencias.
• Arquitecturas Kubernetes: integrar métricas nativas de CloudWatch en un stack OpenTelemetry existente.
• Plataformas de datos e IA: observabilidad de infraestructura y aplicación en el mismo sistema.

Lo que hay que calcular antes de implementarlo

• Volumen de métricas: cuántas métricas por minuto y si conviene filtrar namespaces antes de abrir el stream completo.
• Coste de Firehose y Lambda: ambos escalan con el volumen de métricas y hay que estimarlo antes de activar.
• Capacidad del collector: cuántas instancias necesito, qué CPU y memoria requiere cada una.
• Alta disponibilidad: un collector en única instancia es un punto único de fallo. Multi-AZ es el mínimo para producción.
• Estrategia de reintentos: qué ocurre si Lambda no puede entregar al collector. ¿Se pierden métricas? ¿Caen en S3? ¿Hay alarma configurada?

Mi lectura como arquitecto cloud

Lo que me parece más interesante de esta arquitectura no es la complejidad técnica, sino la claridad del razonamiento detrás. Cada decisión tiene una razón concreta: CloudWatch Metric Streams porque el modelo push es mejor que el pull a escala, Firehose porque gestiona el stream de forma fiable y gestionada, Lambda porque resuelve el problema del endpoint privado de forma elegante, y OpenTelemetry porque el estándar abierto es la única forma real de evitar quedar atrapado en un vendor para siempre.

Para equipos de Platform Engineering y Cloud Operations, este patrón tiene algo muy valioso: cada componente se puede sustituir sin rediseñar todo el sistema. Si mañana quieres cambiar de Grafana a otro backend, cambias el exporter del collector. Si quieres añadir métricas de on-premise, añades otro receiver. El pipeline base no cambia.

Eso es exactamente lo que significa diseñar con estándares abiertos: no como decisión ideológica, sino como decisión práctica de arquitectura que protege la inversión a largo plazo.

Cuándo sí lo usaría

• Cuando la empresa tiene varias cuentas AWS y necesita centralizar observabilidad.
• Cuando el coste de herramientas de observabilidad de terceros ya es un problema real.
• Cuando el equipo necesita alertas con latencia sub-minuto y el polling no llega.
• Cuando hay requisitos de privacidad que impiden exponer endpoints de observabilidad públicamente.
• Cuando se quiere construir una plataforma de observabilidad portable y sin dependencias de vendor.
• Cuando ya existe un stack OpenTelemetry y se quiere integrar métricas nativas de CloudWatch.

Cuándo tendría cuidado o elegiría otra opción

• Si la infraestructura es pequeña y CloudWatch Dashboards ya cubre las necesidades del equipo.
• Si el equipo no tiene experiencia operando collectors ni pipelines de observabilidad.
• Si no se han calculado bien los costes de Firehose y Lambda antes de activar el stream completo.
• Si el collector se va a desplegar sin alta disponibilidad ni monitorización propia.
• Si no existe una estrategia clara de qué métricas enviar, qué retener y hacia qué backends exportar.

Conclusión

La combinación de CloudWatch Metric Streams, Amazon Data Firehose, AWS Lambda y un OpenTelemetry Collector privado dentro de la VPC es una de las arquitecturas de observabilidad más sólidas que se pueden construir hoy en AWS.

No es una solución para todos los equipos ni para todos los tamaños de infraestructura. Pero para organizaciones que han superado la fase inicial y necesitan observabilidad a escala, con latencia real, sin vendor lock-in y con control sobre dónde viven los datos, es un patrón que merece mucho la pena entender y evaluar.

La forma más clara de resumirlo es esta: CloudWatch genera las métricas, Metric Streams las empuja, Firehose las gestiona, Lambda abre la puerta a la VPC privada, y OpenTelemetry convierte todo eso en observabilidad que la empresa controla, puede mover y no depende de ningún vendor para mantener viva.