Bajada
AWS habilitó soporte nativo para enviar métricas desde OpenSearch Ingestion hacia Amazon Managed Service for Prometheus. El cambio permite unificar pipelines de logs, trazas y métricas con menos componentes intermedios y mejor control operativo para equipos de plataforma.
Introducción
Los equipos de plataforma suelen convivir con una fragmentación incómoda en observabilidad: un pipeline para logs, otro para trazas y un tercero —o varios— para métricas. Eso complica la operación diaria, eleva el costo de mantenimiento y, sobre todo, hace más difícil aplicar políticas homogéneas de calidad de datos, seguridad y gobierno. En ese contexto, AWS anunció que Amazon OpenSearch Ingestion ahora soporta Amazon Managed Service for Prometheus (AMP) como sink, permitiendo enrutar métricas directamente por remote_write desde el mismo plano de ingesta.
No es un detalle menor. Para organizaciones que ya usan OpenSearch Ingestion para logs y trazas, incorporar métricas sin montar forwarding adicional reduce puntos de fallo y simplifica el diseño operativo. También abre una vía práctica para consolidar transformaciones, filtros y enriquecimiento en un único flujo administrado.
Qué ocurrió
En su anuncio de marzo de 2026, AWS confirmó que OpenSearch Ingestion puede enviar métricas a AMP como destino nativo. El servicio mantiene su enfoque de pipeline administrado, pero añade la posibilidad de definir un sink Prometheus con endpoint de workspace y autenticación IAM mediante rol del pipeline. La integración se apoya en el protocolo Prometheus remote_write y se integra con fuentes de OpenTelemetry métricas.
La documentación técnica asociada muestra configuraciones tipo de doble destino: una misma canalización puede enviar ciertos datos a OpenSearch y, en paralelo, métricas a AMP. Además, AWS detalla parámetros de buffering y flushing (por ejemplo max_events, max_request_size, flush_interval) para ajustar rendimiento, latencia y consumo.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para DevOps y SRE, el impacto principal es la simplificación del plano de ingesta. Menos componentes externos implica menos superficie de configuración, menos deuda de operación y menos rutas de degradación durante incidentes. En la práctica, permite estandarizar cómo se validan y transforman señales antes de persistirlas.
En infraestructura cloud, el cambio mejora la arquitectura de observabilidad cuando hay múltiples cuentas o entornos. OpenSearch Ingestion ya provee escalado por OCU y monitoreo en CloudWatch; sumar AMP como destino ayuda a separar responsabilidades: OpenSearch para búsqueda y análisis de logs/trazas, Prometheus para series temporales y alertado de métricas.
Desde seguridad operativa, hay ventajas y límites claros. Ventaja: se centraliza el control IAM en el rol de pipeline y se reducen agentes improvisados de forwarding. Límite: AWS aclara restricciones relevantes, como requerir workspaces AMP con claves KMS administradas por el servicio y la necesidad de co-ubicación por cuenta para este patrón. Ignorar esas condiciones puede derivar en fallos silenciosos de escritura.
Detalles técnicos
La configuración mínima del sink Prometheus requiere URL de remote_write del workspace AMP y región. En despliegues reales, lo crítico está en la política IAM: el pipeline role necesita aps:RemoteWrite sobre el ARN del workspace. También debe existir relación de confianza con osis-pipelines.amazonaws.com.
Otro aspecto técnico relevante es la calidad de señal antes del destino. La documentación de OpenSearch Ingestion permite usar procesadores para filtrar o descartar métricas irrelevantes. Esto reduce cardinalidad innecesaria y evita presión sobre cuotas y costos. Si se combina con OTel metrics source, se puede estandarizar nomenclatura y etiquetas desde el inicio del pipeline.
En monitoreo del pipeline, AWS recomienda vigilar métricas como latencia de requests, escritura fallida y volumen de documentos enviados. Esto es fundamental para detectar cuellos de botella en la etapa de remote_write y para ajustar capacidad antes de que impacte alertas de producción. También conviene instrumentar alarmas sobre errores de autenticación o rechazos por configuración de workspace.
Qué deberían hacer los administradores o equipos técnicos
1) Revisar arquitectura actual de métricas. Si hoy existe forwarding artesanal hacia Prometheus, evaluar reemplazo por pipeline administrado para reducir mantenimiento y riesgo operativo.
2) Diseñar política de filtrado. No enviar todo “como viene”. Definir qué métricas son accionables, qué etiquetas conservar y qué nivel de granularidad necesita cada entorno.
3) Validar permisos e identidad. Aplicar mínimo privilegio con aps:RemoteWrite, auditar trust policy y probar fallos controlados antes de producción.
4) Medir costo/rendimiento. Ajustar flushing y capacidad de pipeline según tasa real de ingestión. La meta es evitar latencia excesiva sin sobredimensionar OCU ni workspace.
5) Implementar rollout progresivo. Empezar por un subconjunto de servicios, comparar con ruta anterior y recién luego migrar masivamente.
Conclusión
El nuevo sink de AMP en OpenSearch Ingestion no es solo una mejora incremental: resuelve una fricción frecuente en observabilidad cloud al unificar el control operativo de señales heterogéneas. Para equipos de plataforma, el beneficio inmediato es menor complejidad y mejor gobernanza de pipelines. El verdadero valor, sin embargo, aparece cuando se acompaña con disciplina técnica: filtrado de métricas, IAM bien definido, monitoreo del propio pipeline y rollout gradual. Con ese enfoque, la novedad puede traducirse en observabilidad más confiable y sostenible, no solo en otra feature activada.
Fuentes
- AWS What’s New: OpenSearch Ingestion + AMP sink
- Documentación de OpenSearch Ingestion con sink Prometheus
- Métodos de ingesta en Amazon Managed Service for Prometheus