Filtrado de mensajes de SQS e integración de SNS + SQS

En una arquitectura fan-out sin filtrado, cada suscriptor de SQS recibe todos los mensajes de SNS. Si su topic publica eventos de pedidos para 10 categorías de productos diferentes, pero un suscriptor solo procesa pedidos de electrónica, aun así recibe y debe descartar los mensajes de alimentación y ropa. Esto desperdicia recursos de cómputo, aumenta los costes y añade carga innecesaria a los consumidores. Las políticas de filtrado de suscripciones de SNS resuelven este problema haciendo que el propio SNS enrute los mensajes únicamente a los suscriptores adecuados.

Una política de filtrado es un objeto JSON aplicado a una suscripción de SQS o Lambda. SNS evalúa la política con respecto a los atributos del mensaje antes de realizar la entrega. Si los atributos del mensaje coinciden con la política de filtrado, el mensaje se entrega; si no, SNS omite silenciosamente ese suscriptor. Las políticas de filtrado admiten coincidencia de cadenas, rangos numéricos, coincidencia por prefijo y el operador exists para comprobar si un atributo está presente o ausente.

De forma predeterminada, las políticas de filtrado coinciden con los atributos del mensaje (metadatos). Desde 2023, SNS también admite el filtrado basado en la carga útil (cuerpo) si se establece el ámbito de la política de filtrado en MessageBody. Esto permite filtrar directamente el cuerpo del mensaje mediante rutas JSON, sin que los publicadores tengan que añadir atributos. El filtrado del cuerpo es más flexible, pero requiere que el cuerpo del mensaje sea un JSON válido. Confirme siempre qué ámbito coincide con el formato de salida del publicador.

Las políticas de filtrado admiten varios operadores de coincidencia además de la simple igualdad de cadenas:

• Numeric: {"numeric": ["=", 100]}, {"numeric": [">", 50, "<=", 200]}
• Prefix: {"prefix": "order-"} coincide con cualquier cadena que comience por ese prefijo
• Anything-but: {"anything-but": ["CANCELLED"]} coincide con cualquier valor excepto los indicados
• Exists: {"exists": true} coincide si el atributo está presente; false si está ausente

Para que el filtrado funcione, el publicador debe incluir atributos del mensaje al publicar en SNS. Los atributos son pares clave-valor con un tipo de datos (String, Number, Binary). El publicador no necesita saber qué políticas de filtrado tienen los suscriptores; solo debe enriquecer el mensaje con atributos que describan el evento. SNS se encarga de enrutarlo automáticamente. Esto mantiene a los publicadores completamente desacoplados de la lógica específica de los suscriptores.

Una topología fan-out avanzada puede tener SNS enroutando mensajes a colas de SQS con distintos niveles de especificidad: una cola recibe todos los pedidos (sin filtro) para auditoría, otra recibe únicamente pedidos HIGH_VALUE (amount >= 1000) para la revisión de fraudes y una tercera recibe solo pedidos ELECTRONICS para el almacén de productos electrónicos. Cada cola de SQS tiene su propio consumidor de Lambda. Este patrón permite escalar cada nivel de procesamiento de forma independiente y añadir nuevos consumidores sin modificar los existentes ni el publicador.

SNS puede entregar mensajes a colas de SQS de una cuenta de AWS diferente. La política basada en recursos de la cola de SQS debe permitir que la entidad principal de servicio de SNS llame a sqs:SendMessage desde el ARN del topic de SNS de la cuenta publicadora. Esto permite centralizar la publicación de eventos (una cuenta publica y varios equipos de cuentas se suscriben) sin compartir credenciales. El fan-out entre cuentas es un patrón habitual en configuraciones de AWS Organizations con varias cuentas.

Cuando el volumen de eventos aumenta repentinamente, las invocaciones directas de SNS a Lambda escalan Lambda de inmediato, lo que puede sobrecargar las bases de datos o las API posteriores. Añadir SQS entre SNS y Lambda crea un búfer: SNS entrega los mensajes a SQS y Lambda sondea SQS con un tamaño de lote controlado. Esto permite que Lambda procese los mensajes a un ritmo sostenible mientras SQS absorbe los picos de tráfico. La profundidad de la cola actúa como mecanismo de retropresión: puede supervisarla y generar una alerta cuando supere un umbral que indique retraso del consumidor.

SNS → Lambda (directo): latencia mínima, sin búfer y escalado inmediato de Lambda. Es la mejor opción para alertas en tiempo real o notificaciones urgentes en las que importa una latencia inferior a un segundo. SNS → SQS → Lambda: añade compatibilidad con DLQ, rendimiento controlado, reintentos con tiempo de espera de visibilidad y supervisión de la profundidad de la cola. Es la mejor opción para el procesamiento de transacciones, las actualizaciones de inventario y cualquier escenario en el que deban respetarse los límites de los sistemas posteriores. En las preguntas del examen, elija el búfer de SQS siempre que se mencionen la durabilidad y el control de la tasa.

Utilice el editor de políticas de filtrado de la consola de SNS para comprobar si un mensaje de ejemplo coincidiría con su política de filtrado antes de implementarla. También puede utilizar SNS Sandbox para simular la entrega de mensajes y verificar el enrutamiento. En el código, valide las políticas de filtrado mediante la publicación de mensajes de prueba con atributos conocidos y compruebe las métricas de CloudWatch de cada suscripción: la métrica NumberOfMessagesFiltered muestra cuántos mensajes bloqueó el filtro, lo que le ayuda a ajustar las políticas sin tener que esperar a eventos en producción.

Una integración completa de SNS + SQS funciona de la siguiente manera: (1) la aplicación publica un evento en un tema estándar de SNS con atributos de mensaje; (2) SNS evalúa la política de filtrado de cada suscripción y entrega únicamente los mensajes coincidentes a cada cola de SQS; (3) Lambda sondea cada cola de SQS con un tamaño de lote configurado y procesa los mensajes; (4) los mensajes fallidos llegan a la DLQ de la cola después de alcanzar maxReceiveCount; (5) una alarma de CloudWatch sobre la profundidad de la DLQ alerta al equipo. Este patrón totalmente desacoplado y resistente es un modelo de arquitectura SAA-C03.

Compruebe sus conocimientos sobre los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección ha aprendido que las políticas de filtrado de SNS enrutan los mensajes en función de sus atributos o del contenido del cuerpo en el nivel de SNS, lo que elimina el procesamiento innecesario por parte de los consumidores posteriores; el patrón SNS→SQS→Lambda añade almacenamiento en búfer duradero y control de la velocidad entre la difusión a múltiples destinos y el procesamiento; y la entrega de SQS entre cuentas permite implementar una arquitectura pub/sub centralizada en entornos con varias cuentas mediante políticas de recursos de cola. A continuación, exploraremos las API REST, HTTP y WebSocket de Amazon API Gateway.