Un système basé sur les événements possède une fonction Lambda qui traite les données et doit envoyer les données traitées à un sous-ensemble de quatre fonctions Lambda consommatrices. Le routage est basé sur la valeur d'un champ dans les données. Quelle solution offre le routage requis avec le moins de frais opérationnels ?

La bonne réponse est de créer une seule rubrique Amazon SNS, d'y abonner les quatre fonctions Lambda consommatrices, de configurer des politiques de filtrage d'abonnement SNS pour chaque abonnement, et de faire en sorte que la fonction Lambda de traitement des données publie sur la rubrique. Cette approche utilise les politiques de filtrage d'abonnement SNS pour router les messages de manière sélective vers les fonctions Lambda consommatrices appropriées, en fonction de la valeur d'un champ dans les données. Cela minimise les frais opérationnels car la logique de routage est gérée par SNS, et non par la fonction Lambda de traitement. Les autres options sont moins efficaces : Créer une file d'attente SQS par fonction consommatrice et ajouter une logique de routage dans la fonction de traitement augmenterait la complexité de cette dernière. Abonner les fonctions consommatrices à une rubrique SNS et ajouter une logique de filtrage dans chaque fonction Lambda consommatrice signifie que chaque fonction recevrait tous les messages et devrait les filtrer elle-même, ce qui est inefficace. Créer une rubrique SNS distincte pour chaque fonction consommatrice et publier sur la bonne rubrique depuis la fonction de traitement augmenterait la complexité de la fonction de traitement et le nombre de ressources SNS à gérer.