Una aplicación invoca una función de AWS Lambda de forma asíncrona. El desarrollador desea capturar los mensajes que causaron invocaciones fallidas de Lambda para que la aplicación pueda reintentarlos más tarde. ¿Qué enfoque logra esto con la menor sobrecarga operativa?

La opción correcta es configurar una cola de mensajes fallidos (DLQ) para invocaciones asíncronas de Lambda y hacer de esa DLQ un origen de eventos para la función Lambda. Cuando una invocación asíncrona de Lambda falla (después de los reintentos automáticos), el mensaje se envía a la DLQ. Luego, la función Lambda puede procesar los mensajes de la DLQ, reintentando las invocaciones fallidas. Este es el enfoque con menor sobrecarga operativa porque AWS Lambda gestiona automáticamente el envío a la DLQ y la reintentos. Las otras opciones son menos eficientes: Usar CloudWatch Logs y S3 implica un proceso manual o complejo para filtrar, archivar y reimportar mensajes. Configurar EventBridge para reenviar a SNS no es el mecanismo principal para manejar fallos de invocación asíncrona de Lambda y añade complejidad. Enviar eventos a una cola SQS y que Lambda la sondee es una arquitectura válida, pero la pregunta se refiere a capturar mensajes de invocaciones fallidas de Lambda, no a la fuente inicial de los eventos. La DLQ está diseñada específicamente para este propósito.