Amazon CloudWatch Pipelines: integridad del log original para cumplimiento y auditoria

Cuando un equipo de auditoria solicita evidencia de que los registros no fueron alterados, la pregunta relevante no es si existen logs. La pregunta es si lo que el equipo de operaciones analiza a diario corresponde fielmente a lo que el sistema registro. En entornos donde los logs pasan por transformaciones antes de llegar al destino de analisis (filtrado de campos, enriquecimiento, cambio de formato) esa correspondencia no es automatica.

vtjean

Published Sep 16, 2026

Last modified Sep 16, 2026

Amazon CloudWatch Pipelines, anunciado el 10 de abril de 2026, es un recolector gestionado de datos de telemetria que ingesta, transforma y enruta logs y metricas desde servicios de AWS, aplicaciones de terceros y fuentes personalizadas hacia Amazon CloudWatch. Para equipos que operan bajo requisitos de cumplimiento normativo, la capacidad de conservar el log original antes de cualquier transformacion convierte al pipeline en algo mas que infraestructura de observabilidad: lo convierte en una pieza de la cadena de custodia del dato.

En el contexto de esta serie: el pipeline con la copia original es la garantia de integridad de la senal que alimenta el resto de la cadena de deteccion y respuesta. El requisito de gobernanza define el objetivo. Y tener la trazabilidad de auditoria configurada antes de que el regulador la solicite es la diferencia entre una respuesta de horas y una respuesta de semanas.

Amazon CloudWatch Pipelines en contexto

Amazon CloudWatch Pipelines actua como punto central de recoleccion de telemetria. Acepta datos de multiples fuentes: logs generados por servicios de AWS (denominados "vended logs"), aplicaciones que envian datos mediante agentes o APIs, y fuentes personalizadas.

El pipeline procesa los datos entrantes mediante una cadena de procesadores configurables: puede filtrar campos, transformar formatos, enriquecer con metadatos adicionales o renombrar atributos. Una vez procesados, los datos se enrutan al destino correspondiente.

Dos restricciones de destino que conviene conocer desde el inicio:

Pipelines de logs: Amazon CloudWatch Logs es el unico destino soportado.
Pipelines de metricas: Amazon CloudWatch Metrics es el unico destino soportado.

La creacion de un pipeline toma hasta 5 minutos. Este tiempo incluye la provision de la infraestructura y la validacion de la configuracion de procesadores.

El problema: transformar para operar, conservar para auditar

Los equipos de operaciones necesitan logs procesados. Un log en formato crudo puede tener campos irrelevantes para el monitoreo, formatos inconsistentes entre fuentes, o carecer de metadatos que faciliten la correlacion. Transformar el log antes de almacenarlo reduce el ruido en consultas y estandariza la estructura entre fuentes.

Pero los equipos de cumplimiento necesitan lo contrario: el dato tal como fue generado, sin modificaciones, con la capacidad de demostrar que no fue alterado.

Estas dos necesidades son legitimas y no tienen por que entrar en conflicto. El mecanismo que Amazon CloudWatch Pipelines ofrece para resolverlas es la funcionalidad "Keep original log".

Keep original log: el campo @original_message

Cuando la opcion "Keep original log" esta habilitada en un pipeline, el servicio almacena una copia del evento de log en su estado original, antes de cualquier transformacion, en el campo de sistema @original_message.

Cada evento de log que pasa por el pipeline conserva dos versiones:

La version transformada: El resultado de aplicar los procesadores configurados. Esta es la version que los equipos de operaciones consultan para monitoreo, alertas y dashboards.
El campo @original_message: El evento tal como llego al pipeline, sin modificaciones. Esta es la version que el equipo de auditoria puede consultar para verificar integridad.

Esta funcionalidad esta disponible exclusivamente para pipelines cuya fuente son logs generados por servicios de AWS (vended log sources). Para fuentes personalizadas o de terceros, la funcionalidad no aplica.

Consulta del campo @original_message

El campo @original_message es consultable mediante Amazon CloudWatch Logs Insights como cualquier otro campo de sistema. Un ejemplo de consulta para recuperar el log original junto con la marca temporal:

1
2
3
4
fields @timestamp, @original_message
| filter @logStream = 'vpc-flow-logs-prod'
| sort @timestamp desc
| limit 50

Esta consulta recupera los ultimos 50 eventos originales del stream de VPC Flow Logs de produccion. El equipo de auditoria puede comparar el contenido de @original_message con la version transformada del mismo evento para confirmar que las transformaciones aplicadas corresponden a la configuracion documentada del pipeline.

Ejemplo practico

Supongamos que un pipeline recibe logs de Amazon VPC Flow Logs y aplica los siguientes procesadores:

Un filtro que elimina campos de bajo valor analitico
Una transformacion que convierte direcciones IP a nombres de host mediante enriquecimiento
Un renombrado de campos para estandarizar nomenclatura

Con "Keep original log" habilitado, el evento almacenado en Amazon CloudWatch Logs contiene los campos transformados en su estructura normal y, adicionalmente, el campo @original_message con el evento de VPC Flow Log tal como lo genero el servicio de Amazon VPC.

Procesadores y configuracion condicional

Los pipelines de logs soportan una cadena de procesadores que actuan sobre los eventos entrantes. Cada procesador puede configurarse con un parametro "when" que controla sobre que eventos actua.

El parametro "when" permite definir condiciones para que un procesador solo se aplique a un subconjunto de los eventos del pipeline. Esto es util cuando el pipeline recibe logs de multiples fuentes o tipos y las transformaciones no aplican de forma uniforme.

Un ejemplo de uso: un pipeline que recibe logs de Amazon VPC Flow Logs y de balanceadores de carga de AWS puede necesitar transformaciones diferentes para cada tipo. El parametro "when" permite dirigir cada procesador al tipo de log correspondiente sin necesidad de crear pipelines separados.

Configuracion asistida por IA

Amazon CloudWatch Pipelines incluye una funcionalidad de configuracion asistida que genera configuraciones de procesadores a partir de descripciones en lenguaje natural. En lugar de escribir la configuracion manualmente, el operador describe la transformacion deseada y el servicio genera la configuracion correspondiente.

Esta funcionalidad requiere el permiso de IAM logs:GeneratePipeline. La configuracion generada debe revisarse antes de aplicarla. Es una herramienta de asistencia que acelera la creacion inicial, pero no reemplaza la validacion del operador.

Auditoria de la configuracion del pipeline

Las configuraciones de procesadores de Amazon CloudWatch Pipelines se registran como eventos en AWS CloudTrail. Cada cambio en la configuracion de un pipeline (agregar un procesador, modificar una condicion, habilitar o deshabilitar "Keep original log") queda registrado con el detalle habitual de CloudTrail: identidad de IAM, marca temporal, direccion IP de origen y parametros de la solicitud.

Para equipos de cumplimiento, esta trazabilidad permite demostrar no solo que el log original se conserva, sino tambien que la configuracion del pipeline no fue modificada sin autorizacion.

Precaucion con datos sensibles en la configuracion

La documentacion de Amazon CloudWatch Pipelines advierte de forma explicita: las configuraciones de procesadores no deben incluir contrasenas, claves de API ni informacion sensible. Dado que estas configuraciones aparecen en eventos de AWS CloudTrail, cualquier dato sensible incluido en la configuracion quedaria visible en los registros de auditoria.

Esta advertencia aplica especialmente a procesadores de enriquecimiento que podrian requerir credenciales para consultar fuentes externas. La recomendacion es utilizar referencias a AWS Secrets Manager o mecanismos equivalentes en lugar de incluir valores en texto plano dentro de la configuracion del procesador.

Pipelines de metricas: configuracion YAML con atributos OTel

Los pipelines de metricas de Amazon CloudWatch utilizan una configuracion basada en YAML que define criterios de seleccion mediante rutas de atributos de OpenTelemetry (OTel). Los criterios disponibles incluyen:

resource.attributes: Atributos del recurso que genera la metrica (servicio, instancia, region)
metric.name: Nombre de la metrica
datapoint.attributes: Atributos especificos del punto de datos

Cuando se definen multiples criterios, se aplica logica AND: el punto de datos debe cumplir todos los criterios para ser procesado por el pipeline.

Un ejemplo de configuracion YAML:

1
2
3
4
5
6
selection_criteria:
  - resource.attributes:
      service.name: "servicio-pagos"
    metric.name: "http.server.request.duration"
    datapoint.attributes:
      http.route: "/api/v2/transactions"

Esta configuracion selecciona las metricas de duracion de solicitudes HTTP en la ruta de transacciones del servicio de pagos, descartando todo lo demas. La especificidad de los criterios permite construir pipelines de metricas enfocados que reduzcan el volumen de datos procesados.

Flujo de trabajo de gobernanza

Integrando las capacidades descritas, un flujo de trabajo de gobernanza para pipelines de logs bajo requisitos de cumplimiento incluye seis pasos:

1. Inventario de requisitos

Identificar que fuentes de logs requieren conservacion del dato original por obligacion normativa o politica interna. No todas las fuentes necesitan la misma proteccion. Priorizar las que contienen datos de clientes, transacciones financieras o eventos de seguridad.

2. Configuracion del pipeline con "Keep original log"

Habilitar la funcionalidad en cada pipeline que procese fuentes bajo requisito de conservacion. Verificar que la fuente sea de tipo vended log, ya que la funcionalidad no aplica a fuentes personalizadas.

3. Documentacion de procesadores

Configurar cada procesador con condiciones "when" explicitas. Mantener documentacion del proposito de cada transformacion: por que se filtra un campo, por que se renombra un atributo, que enriquecimiento se aplica. Esta documentacion no es solo para el equipo tecnico; es evidencia de que las transformaciones son intencionales y justificadas.

4. Verificacion de trazabilidad en AWS CloudTrail

Confirmar que los cambios en la configuracion del pipeline se registran correctamente en AWS CloudTrail. Ejecutar una modificacion de prueba y verificar que el evento aparece en el trail con el detalle esperado.

5. Alertas sobre cambios de configuracion

Configurar reglas en Amazon EventBridge para notificar cuando se modifique la configuracion de un pipeline bajo requisito de cumplimiento. El objetivo es que ninguna modificacion pase desapercibida, independientemente de quien la realice.

6. Prueba de recuperacion

Ejecutar periodicamente consultas en Amazon CloudWatch Logs Insights que verifiquen la presencia del campo @original_message en los eventos recientes. Un ejemplo:

1
2
3
4
fields @timestamp, @original_message
| stats count() as total_con_original by bin(1h)
| sort @timestamp desc
| limit 24

Esta consulta muestra el conteo de eventos con @original_message agrupados por hora durante las ultimas 24 horas. Una caida inesperada en el conteo indicaria un problema con la configuracion del pipeline.

Donde encaja en la estrategia de observabilidad

Amazon CloudWatch Pipelines no reemplaza otros mecanismos de recopilacion de logs. Amazon CloudWatch Agent, las suscripciones de Amazon CloudWatch Logs y las integraciones directas de servicios de AWS siguen siendo validos. El pipeline anade la capa de transformacion gestionada y, con "Keep original log", la capa de conservacion para cumplimiento.

Para organizaciones que operan bajo marcos regulatorios (PCI DSS, SOC 2, HIPAA, regulaciones bancarias locales), la capacidad de demostrar que el log original no fue alterado es un requisito, no una mejora. El pipeline, con el campo @original_message, convierte ese requisito en una configuracion de servicio en lugar de un proceso manual.

Limitaciones

La funcionalidad "Keep original log" solo esta disponible para pipelines con fuentes de logs de servicios de AWS (vended log sources). Las fuentes personalizadas y de terceros no estan cubiertas.
Los pipelines de logs solo soportan Amazon CloudWatch Logs como destino. No es posible enrutar directamente a Amazon S3, Amazon OpenSearch Service u otros destinos.
Los pipelines de metricas solo soportan Amazon CloudWatch Metrics como destino.
La creacion de un pipeline toma hasta 5 minutos. Los cambios de configuracion tambien requieren tiempo de propagacion.
La configuracion asistida por IA (permiso logs:GeneratePipeline) genera sugerencias que requieren revision manual. No es un mecanismo de configuracion autonomo.
Habilitar "Keep original log" incrementa el volumen de almacenamiento en Amazon CloudWatch Logs, dado que cada evento conserva ambas versiones del dato. El impacto en costos debe evaluarse durante la planificacion.
El campo @original_message no tiene un mecanismo de verificacion criptografica integrado. La integridad depende de los controles de acceso y las politicas de retencion del grupo de logs de Amazon CloudWatch Logs.

Recursos

Amazon CloudWatch Pipelines - Documentacion oficial del servicio con guias de configuracion
Amazon CloudWatch Logs Insights query syntax - Sintaxis para consultar campos como @original_message
AWS CloudTrail event reference - Estructura de eventos de auditoria de configuracion
IAM actions for Amazon CloudWatch Logs - Permisos IAM incluyendo logs:GeneratePipeline
Amazon EventBridge rules - Configuracion de reglas para alertar sobre cambios en pipelines

Builder Center