Vous avez configuré une source d'événements Amazon S3 pour déclencher une fonction AWS Lambda lorsque des objets sont créés ou mis à jour dans un compartiment S3 spécifique. La fonction Lambda utilise le nom du compartiment et la clé de l'objet de l'événement pour lire l'objet et analyser son contenu, puis écrit les données analysées dans une table DynamoDB. Le rôle d'exécution de la fonction Lambda dispose des autorisations nécessaires pour lire le compartiment S3 et écrire dans DynamoDB, mais la fonction n'est pas invoquée lorsque des objets sont ajoutés ou modifiés. Qu'est-ce qui résout le problème ?

La bonne réponse est d'ajouter une politique basée sur les ressources à la fonction Lambda. Lorsqu'un service AWS comme S3 doit invoquer une fonction Lambda, la fonction Lambda a besoin d'une politique de ressources (aussi appelée politique d'autorisation) qui accorde au service appelant la permission d'invoquer la fonction. Sans cette politique, S3 n'est pas autorisé à déclencher la fonction, même si le rôle d'exécution de Lambda a les permissions nécessaires pour les opérations en aval. Les autres options sont incorrectes car : Une politique de compartiment S3 ne donne pas à S3 la permission d'invoquer Lambda ; elle contrôle l'accès au compartiment lui-même. Configurer une file d'attente SQS comme destination d'échec est pour la gestion des erreurs d'invocation de Lambda, pas pour l'autorisation d'invocation initiale. Configurer SQS comme cible de notification S3 est une solution alternative pour acheminer les événements S3, mais cela ne résout pas le problème fondamental d'autorisation entre S3 et Lambda directement.