Filtraggio dei messaggi SQS e integrazione SNS + SQS

In un'architettura fan-out senza filtraggio, ogni subscriber SQS riceve ogni messaggio SNS. Se il topic pubblica eventi relativi a ordini di 10 categorie di prodotti diverse, ma un subscriber elabora solo gli ordini di elettronica, riceve comunque i messaggi relativi ad alimentari e abbigliamento e deve scartarli. Questo spreca risorse di calcolo, aumenta i costi e aggiunge carico non necessario sui consumer. Le policy di filtro delle sottoscrizioni SNS risolvono il problema facendo sì che sia SNS a instradare i messaggi solo ai subscriber appropriati.

Una filter policy è un oggetto JSON applicato a una sottoscrizione SQS o Lambda. SNS valuta la policy rispetto agli attributi del messaggio prima della consegna. Se gli attributi del messaggio corrispondono alla filter policy, il messaggio viene consegnato; in caso contrario, SNS ignora silenziosamente quel subscriber. Le filter policy supportano la corrispondenza di stringhe, gli intervalli numerici, la corrispondenza per prefisso e l'operatore exists per verificare la presenza o l'assenza di un attributo.

Per impostazione predefinita, le filter policy verificano gli attributi del messaggio (metadati). Dal 2023, SNS supporta anche il filtraggio basato sul payload (corpo), impostando l'ambito della filter policy su MessageBody. Ciò consente di applicare il filtraggio direttamente al corpo del messaggio tramite JSON path, senza richiedere ai publisher di aggiungere attributi. Il filtraggio del corpo è più flessibile, ma richiede che il corpo del messaggio sia un JSON valido. Verifichi sempre quale ambito corrisponde al formato prodotto dal publisher.

Le filter policy supportano diversi operatori di corrispondenza oltre alla semplice uguaglianza tra stringhe:

• Numeric: {"numeric": ["=", 100]}, {"numeric": [">", 50, "<=", 200]}
• Prefix: {"prefix": "order-"} corrisponde a qualsiasi stringa che inizi con quel prefisso
• Anything-but: {"anything-but": ["CANCELLED"]} corrisponde a qualsiasi valore tranne quelli elencati
• Exists: {"exists": true} corrisponde se l'attributo è presente; false se è assente

Perché il filtraggio funzioni, il publisher deve includere gli attributi del messaggio quando pubblica su SNS. Gli attributi sono coppie chiave-valore con un tipo di dati (String, Number, Binary). Il publisher non deve sapere quali filter policy hanno i subscriber: deve solo arricchire il messaggio con attributi che descrivono l'evento. SNS gestisce automaticamente l'instradamento. In questo modo i publisher rimangono completamente disaccoppiati dalla logica specifica dei subscriber.

Una topologia fan-out avanzata può prevedere che SNS instradi i messaggi verso code SQS con diversi livelli di specificità: una coda riceve tutti gli ordini (senza filtro) per l'audit, un'altra riceve solo gli ordini HIGH_VALUE (amount >= 1000) per la revisione delle frodi e una terza riceve solo gli ordini ELECTRONICS per il magazzino di elettronica. Ogni coda SQS ha il proprio consumer Lambda. Questo pattern consente di scalare ogni livello di elaborazione in modo indipendente e di aggiungere nuovi consumer senza modificare quelli esistenti né il publisher.

SNS può effettuare la consegna a code SQS presenti in un account AWS diverso. La policy basata sulle risorse della coda SQS deve consentire al principale di servizio SNS di chiamare sqs:SendMessage dall'ARN del topic SNS dell'account di pubblicazione. Ciò consente la pubblicazione centralizzata degli eventi (un account pubblica, più team di account sottoscrivono) senza condividere le credenziali. Il fan-out tra account è un pattern comune nelle configurazioni AWS Organizations con più account.

Quando il volume degli eventi aumenta improvvisamente, le invocazioni dirette da SNS a Lambda fanno scalare immediatamente Lambda, rischiando di sovraccaricare i database o le API downstream. L'aggiunta di SQS tra SNS e Lambda crea un buffer: SNS distribuisce i messaggi a SQS e Lambda interroga SQS con una dimensione del batch controllata. In questo modo Lambda elabora i messaggi a una velocità sostenibile, mentre SQS assorbe i picchi di traffico. La profondità della coda agisce da meccanismo di backpressure: è possibile monitorarla e generare un avviso quando supera una soglia che indica un ritardo del consumer.

SNS → Lambda (diretto): latenza minima, nessun buffering e scalabilità immediata di Lambda. È ideale per gli avvisi in tempo reale o le notifiche urgenti, quando è importante una latenza inferiore al secondo. SNS → SQS → Lambda: aggiunge il supporto per la DLQ, un throughput controllato, retry con visibility timeout e il monitoraggio della profondità della coda. È ideale per l'elaborazione delle transazioni, gli aggiornamenti dell'inventario e qualsiasi scenario in cui sia necessario rispettare i limiti dei sistemi downstream. Nelle domande d'esame, scelga il buffering SQS ogni volta che vengono menzionati persistenza e controllo della velocità.

Utilizzi l’editor delle filter policy della console SNS per verificare se un messaggio di esempio corrisponderebbe alla filter policy prima di eseguire il deployment. Può anche utilizzare la SNS Sandbox per simulare la consegna dei messaggi e verificare il routing. Nel codice, convalidi le filter policy pubblicando messaggi di test con attributi noti e controllando le metriche di CloudWatch per ogni sottoscrizione: la metrica NumberOfMessagesFiltered mostra quanti messaggi sono stati bloccati dal filtro, aiutandola a ottimizzare le policy senza dover attendere eventi in produzione.

Un’integrazione completa tra SNS e SQS funziona in questo modo: (1) l’applicazione pubblica un evento in un topic SNS Standard con attributi del messaggio; (2) SNS valuta la filter policy di ogni sottoscrizione e consegna solo i messaggi corrispondenti a ciascuna coda SQS; (3) Lambda esegue il polling di ogni coda SQS con una dimensione batch configurata ed elabora i messaggi; (4) i messaggi non elaborati raggiungono la DLQ della coda dopo il numero massimo di ricezioni, maxReceiveCount; (5) un allarme CloudWatch sulla profondità della DLQ avvisa il team. Questo pattern completamente disaccoppiato e resiliente rappresenta un modello di architettura SAA-C03.

Verifichi la sua comprensione dei concetti AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione ha imparato che le filter policy SNS instradano i messaggi in base agli attributi del messaggio o al contenuto del corpo a livello SNS, eliminando l’elaborazione non necessaria da parte dei consumer downstream; il pattern SNS→SQS→Lambda aggiunge un buffering duraturo e un controllo della velocità tra la trasmissione broadcast fan-out e l’elaborazione; infine, la consegna SQS cross-account consente di realizzare un modello pub/sub centralizzato in ambienti con più account tramite le policy delle risorse delle code. Nella prossima lezione esploreremo le API REST, HTTP e WebSocket di Amazon API Gateway.