Une application invoque une fonction AWS Lambda de manière asynchrone. Le développeur souhaite capturer les messages qui ont provoqué des échecs d'invocation Lambda afin que l'application puisse les relancer ultérieurement. Quelle approche permet d'y parvenir avec le moins de frais opérationnels ?

La configuration d'une file d'attente de lettres mortes (DLQ) pour les invocations Lambda asynchrones échouées est la solution la plus efficace et la moins coûteuse en termes opérationnels. Lambda enverra automatiquement les événements non traités (en raison d'erreurs ou d'échecs de tentatives) à la DLQ. Vous pouvez ensuite configurer la fonction Lambda pour qu'elle traite les messages de cette DLQ, ce qui permet de relancer facilement les invocations échouées. Les autres options sont moins optimales : Utiliser CloudWatch Logs pour filtrer et archiver les messages dans S3, puis les importer dans Lambda, est un processus manuel et complexe avec des frais opérationnels élevés. Configurer EventBridge pour transférer les messages échoués vers SNS pour redéclencher la fonction Lambda ajoute une couche de complexité inutile et n'est pas la méthode native pour gérer les échecs d'invocations asynchrones de Lambda. Envoyer les événements à une file d'attente SQS et configurer Lambda pour interroger SQS est une approche valide pour d'autres cas d'utilisation, mais pour les échecs d'invocations asynchrones de Lambda, la DLQ est la solution intégrée et la plus simple.