SQS-berichtenfiltering en SNS- plus SQS-integratie

In een fan-outarchitectuur zonder filtering ontvangt elke SQS-abonnee elk SNS-bericht. Als je topic bestelgebeurtenissen voor tien verschillende productcategorieën publiceert, maar een abonnee alleen bestellingen van elektronica verwerkt, ontvangt en moet deze nog steeds berichten over voedsel en kleding weggooien. Dit verspilt rekenkracht, verhoogt de kosten en zorgt voor onnodige belasting van consumenten. Filterbeleid voor SNS-abonnementen lost dit op doordat SNS de berichten zelf alleen naar de juiste abonnees routeert.

Een filterbeleid is een JSON-object dat op een SQS- of Lambda-abonnement wordt toegepast. SNS evalueert het beleid voor elk bericht aan de hand van de berichtkenmerken, voordat het bericht wordt afgeleverd. Als de berichtkenmerken overeenkomen met het filterbeleid, wordt het bericht afgeleverd. Zo niet, dan slaat SNS die abonnee stilletjes over. Filterbeleid ondersteunt het vergelijken van tekenreeksen, numerieke bereiken, voorvoegselvergelijking en de operator exists om te controleren of een kenmerk aanwezig of afwezig is.

Standaard worden filterbeleid toegepast op berichtkenmerken (metagegevens). Sinds 2023 ondersteunt SNS ook filtering op basis van de nettolading (hoofdtekst) door het bereik van het filterbeleid in te stellen op MessageBody. Hierdoor kun je rechtstreeks op basis van JSON-paden in de hoofdtekst filteren, zonder dat publishers kenmerken hoeven toe te voegen. Filtering op de hoofdtekst is flexibeler, maar vereist wel dat de hoofdtekst geldige JSON bevat. Controleer altijd welk bereik overeenkomt met de indeling van de uitvoer van je publisher.

Filterbeleid ondersteunt naast eenvoudige gelijkheid van tekenreeksen meerdere vergelijkingsoperatoren:

• Numeriek: {"numeric": ["=", 100]}, {"numeric": [">", 50, "<=", 200]}
• Voorvoegsel: {"prefix": "order-"} komt overeen met elke tekenreeks die met dat voorvoegsel begint
• Alles behalve: {"anything-but": ["CANCELLED"]} komt overeen met elke waarde behalve de vermelde waarden
• Bestaat: {"exists": true} komt overeen als het kenmerk aanwezig is; false als het ontbreekt

Om filtering te laten werken, moet de publisher berichtkenmerken opnemen bij het publiceren naar SNS. Kenmerken zijn sleutel-waardeparen met een gegevenstype (String, Number, Binary). De publisher hoeft niet te weten welke abonnees welk filterbeleid hebben. Hij verrijkt het bericht alleen met kenmerken die de gebeurtenis beschrijven. SNS handelt de routering automatisch af. Zo blijven publishers volledig ontkoppeld van logica die specifiek is voor abonnees.

Een geavanceerde fan-outtopologie kan bestaan uit SNS dat naar SQS-wachtrijen met verschillende specificiteitsniveaus routeert: één wachtrij ontvangt alle bestellingen (zonder filter) voor controle, een andere ontvangt alleen bestellingen met hoge waarde (bedrag >= 1000) voor fraudebeoordeling en een derde ontvangt alleen bestellingen van elektronica voor het elektronicamagazijn. Elke SQS-wachtrij heeft zijn eigen Lambda-consument. Dit patroon maakt het mogelijk elke verwerkingslaag onafhankelijk te schalen en nieuwe consumenten toe te voegen zonder bestaande consumenten of de publisher aan te passen.

SNS kan berichten afleveren aan SQS-wachtrijen in een ander AWS-account. Het resourcebeleid van de SQS-wachtrij moet de service-principal van SNS toestaan om sqs:SendMessage aan te roepen met de ARN van het SNS-topic in het publisheraccount. Hierdoor kun je centraal gebeurtenissen publiceren (één account publiceert en teams uit meerdere accounts abonneren zich) zonder referenties te delen. Fan-out tussen accounts is een veelgebruikt patroon in omgevingen met meerdere AWS Organizations-accounts.

Wanneer het gebeurtenisvolume piekt, schalen directe SNS-naar-Lambda-aanroepen Lambda onmiddellijk op. Daardoor kunnen achterliggende databases of API's overbelast raken. Door SQS tussen SNS en Lambda te plaatsen, maak je een buffer: SNS levert berichten af aan SQS en Lambda haalt ze op in een gecontroleerde batchgrootte. Zo kan Lambda in een duurzaam tempo verwerken, terwijl SQS verkeerspieken opvangt. De diepte van de wachtrij werkt als mechanisme voor terugdruk: je kunt deze controleren en een waarschuwing instellen wanneer de diepte boven een drempel groeit, wat op een achterlopende consument wijst.

SNS → Lambda (direct): de laagste latentie, geen buffering en Lambda schaalt onmiddellijk. Dit is het meest geschikt voor realtimewaarschuwingen of dringende meldingen waarbij een latentie van minder dan een seconde belangrijk is. SNS → SQS → Lambda: biedt ondersteuning voor een DLQ, gecontroleerde verwerkingscapaciteit, nieuwe pogingen met een zichtbaarheidstime-out en controle van de wachtrijdiepte. Dit is het meest geschikt voor transactieverwerking, voorraadupdates en elk scenario waarin achterliggende limieten moeten worden gerespecteerd. Kies bij examenvragen voor buffering met SQS zodra duurzaamheid en snelheidsregeling worden genoemd.

Gebruik de editor voor filterbeleid in de SNS-console om te testen of een voorbeeldbericht overeenkomt met je filterbeleid voordat je het implementeert. Je kunt ook de SNS Sandbox gebruiken om berichtbezorging te simuleren en de routering te controleren. Valideer filterbeleid in code door testberichten met bekende kenmerken te publiceren en de CloudWatch-statistieken voor elke abonnement te controleren: de statistiek NumberOfMessagesFiltered toont hoeveel berichten door het filter zijn geblokkeerd. Zo kun je beleid bijstellen zonder op productiegebeurtenissen te wachten.

Een volledige SNS + SQS-integratie ziet er als volgt uit: (1) de applicatie publiceert een gebeurtenis naar een SNS Standard-topic met berichtkenmerken; (2) SNS evalueert het filterbeleid van elk abonnement en bezorgt alleen overeenkomende berichten aan elke SQS-wachtrij; (3) Lambda peilt elke SQS-wachtrij met een geconfigureerde batchgrootte en verwerkt berichten; (4) mislukte berichten komen na maxReceiveCount in de DLQ terecht; (5) een CloudWatch-alarm voor de DLQ-lengte waarschuwt het team. Dit volledig ontkoppelde, veerkrachtige patroon is een modelarchitectuur voor SAA-C03.

In deze les heb je geleerd dat SNS-filterbeleid berichten op SNS-niveau routeert op basis van berichtkenmerken of de inhoud van de berichttekst, waardoor onnodige verwerking door downstream-consumenten wordt geëlimineerd; dat het patroon SNS→SQS→Lambda duurzame buffering en snelheidsregeling toevoegt tussen het uitzenden naar meerdere ontvangers en de verwerking; en dat SQS-bezorging tussen accounts gecentraliseerde pub/sub mogelijk maakt in omgevingen met meerdere accounts door wachtrijbronbeleid te gebruiken. Hierna verkennen we de REST-, HTTP- en WebSocket-API's van Amazon API Gateway.