Devi creare un flusso di lavoro che elabori i messaggi in arrivo in una coda Amazon SQS. Dopo l'arrivo di un messaggio, il flusso di lavoro deve attendere un ritardo specificato prima di richiamare una funzione Lambda per elaborarlo. Quale approccio fornisce questo comportamento con il MINOR sforzo operativo?

L'opzione corretta è impostare il parametro DelaySeconds della coda SQS e configurare una mappatura dell'origine eventi per la funzione Lambda. Questo è l'approccio con il minor sforzo operativo perché DelaySeconds è una funzionalità nativa di SQS che ritarda la visibilità dei nuovi messaggi per il tempo specificato. La mappatura dell'origine eventi di Lambda si occupa automaticamente del polling della coda e dell'invocazione della funzione quando i messaggi diventano visibili, senza necessità di codice aggiuntivo o infrastrutture complesse. Le altre opzioni sono meno efficienti: AWS Step Functions introdurrebbe complessità e costi aggiuntivi per un semplice ritardo, e l'attivazione tramite EventBridge ogni 5 minuti non garantirebbe un'elaborazione immediata dopo il ritardo del singolo messaggio. Il polling della coda da parte della Lambda e la ripubblicazione dei messaggi con attributi personalizzati richiederebbero logica applicativa complessa e aumenterebbero il traffico SQS, oltre a non essere un pattern standard per i ritardi. Visibility Timeout impedisce che un messaggio già consumato venga elaborato da altre istanze per un certo periodo, ma non ritarda la sua prima visibilità nella coda.