Un'applicazione richiama una funzione AWS Lambda in modo asincrono. Lo sviluppatore desidera acquisire i messaggi che hanno causato invocazioni Lambda fallite in modo che l'applicazione possa riprovarli in seguito. Quale approccio realizza questo con il minor overhead operativo?

L'opzione corretta è configurare una coda di messaggi non recapitabili (DLQ) per le invocazioni asincrone di Lambda fallite e renderla una sorgente di eventi per la funzione Lambda. Questo è l'approccio più efficiente perché AWS Lambda offre il supporto nativo per le DLQ per le invocazioni asincrone. Quando un'invocazione asincrona fallisce (dopo i tentativi automatici), il messaggio viene automaticamente inviato alla DLQ. La funzione Lambda può quindi essere configurata per elaborare i messaggi da questa DLQ, consentendo una facile rielaborazione. Le altre opzioni sono meno efficienti: L'utilizzo dei log di CloudWatch per filtrare e archiviare i messaggi in S3 richiede un'implementazione e una gestione aggiuntive per l'estrazione e la rielaborazione dei messaggi. Configurare EventBridge per inoltrare i messaggi falliti ad Amazon SNS non è il meccanismo primario per la gestione dei fallimenti delle invocazioni asincrone di Lambda e aggiunge complessità. Inviare gli eventi a una coda Amazon SQS e configurare Lambda per eseguire il polling della coda è un modello valido per l'elaborazione di messaggi, ma non è la soluzione più diretta per catturare i fallimenti delle invocazioni asincrone di Lambda, che è ciò che la DLQ gestisce nativamente.