Amazon EventBridge Pipes
Servicio que construye integraciones punto a punto desde fuentes como SQS, Kinesis y DynamoDB Streams hacia destinos con filtrado y transformación incorporados
Descripción general
Amazon EventBridge Pipes es un servicio que construye integraciones punto a punto desde fuentes de eventos hacia destinos sin necesidad de código. Conecta fuentes como SQS, Kinesis Data Streams, DynamoDB Streams, Apache Kafka administrado (MSK) y colas MQ con destinos como Step Functions, Lambda, API Gateway, EventBridge Bus y servicios de terceros, con capacidades opcionales de filtrado y enriquecimiento en el camino. A diferencia de las reglas de EventBridge que operan en un modelo pub/sub de uno a muchos, Pipes se especializa en conexiones uno a uno, simplificando la configuración y reduciendo la latencia.
Pipeline de 4 etapas: fuente, filtro, enriquecimiento y destino
La arquitectura de Pipes se compone de 4 etapas: Source → Filter → Enrichment → Target. La etapa Source define de dónde se consumen los eventos (SQS, Kinesis, DynamoDB Streams, MSK, etc.). La etapa Filter aplica patrones de filtrado de EventBridge para procesar solo los eventos que coinciden con condiciones específicas, reduciendo invocaciones innecesarias del destino. La etapa Enrichment es opcional y permite enriquecer los eventos llamando a Lambda, Step Functions, API Gateway o API Destinations antes de enviarlos al destino. La etapa Target define el destino final donde se entregan los eventos procesados. Esta arquitectura de 4 etapas elimina la necesidad de escribir código Lambda de pegamento para filtrar, transformar y enrutar eventos, reduciendo la complejidad operativa y los costos. Cada etapa es configurable de forma independiente, y el filtro y enriquecimiento pueden omitirse si no son necesarios.
Diseño de procesamiento por lotes y manejo de errores
Pipes soporta procesamiento por lotes para fuentes basadas en streams (Kinesis, DynamoDB Streams). El tamaño del lote (BatchSize) y la ventana de lote (MaximumBatchingWindowInSeconds) controlan cuántos registros se procesan juntos. Para cargas de trabajo de alto throughput, lotes más grandes mejoran la eficiencia pero aumentan la latencia. El manejo de errores difiere según la fuente: para SQS, los mensajes fallidos se envían a la cola de mensajes muertos (DLQ) después del número máximo de reintentos. Para Kinesis y DynamoDB Streams, se puede configurar el comportamiento ante fallos: reintentar con backoff exponencial, omitir el registro fallido o dividir el lote para aislar el registro problemático. La configuración OnPartialBatchItemFailure permite reportar solo los ítems fallidos del lote, evitando reprocesar los exitosos. Para escenarios de alta disponibilidad, se recomienda configurar un destino DLQ para capturar eventos que no pudieron procesarse después de todos los reintentos.
Transformación de eventos y uso de InputTemplate
InputTemplate permite transformar la estructura del evento antes de enviarlo al destino, adaptando el formato del evento de la fuente al esquema esperado por el destino. Se utiliza la sintaxis de plantillas de EventBridge con variables como <$.detail.field> para extraer campos específicos del evento. Por ejemplo, un evento de DynamoDB Streams con estructura NewImage puede transformarse en un payload JSON plano que el destino API espera. Las transformaciones soportan funciones de cadena, concatenación y valores estáticos. Para transformaciones complejas que exceden las capacidades de InputTemplate, la etapa de Enrichment con Lambda proporciona flexibilidad total. Un patrón común es usar InputTemplate para transformaciones simples de mapeo de campos y reservar Lambda solo para lógica de negocio compleja como validaciones o llamadas a APIs externas. Esto minimiza los costos al evitar invocaciones Lambda innecesarias para transformaciones que pueden resolverse declarativamente.