Un'applicazione di elaborazione video viene eseguita come funzione AWS Lambda Node.js che viene attivata da S3 quando viene caricata una nuova immagine. La funzione scarica le immagini da un bucket S3, le trasforma, scrive l'immagine trasformata in un secondo bucket S3 e aggiorna i metadati in DynamoDB. Con l'aumento delle dimensioni delle immagini, la funzione Lambda ora va frequentemente in timeout; il timeout della funzione è già impostato al massimo. L'azienda non vuole gestire server. Quale combinazione di modifiche dovrebbe implementare l'architetto di soluzioni per evitare errori di invocazione? (Scegliere due.)

Le immagini di grandi dimensioni causano il timeout della funzione Lambda, anche con il timeout massimo. Questo indica che il carico di lavoro supera le capacità di Lambda per le operazioni a lunga esecuzione o ad alta intensità di risorse. La soluzione consiste nel migrare il carico di lavoro a un servizio più adatto. L'opzione corretta è impacchettare l'applicazione come immagine Docker e pubblicarla su Amazon ECR, quindi creare una definizione di attività Amazon ECS con compatibilità AWS Fargate. La funzione Lambda può quindi innescare un'attività Fargate quando un nuovo file arriva in S3. Fargate è una soluzione serverless che offre maggiore flessibilità in termini di risorse computazionali e tempi di esecuzione rispetto a Lambda, senza la necessità di gestire server. Le opzioni errate sono: L'uso di AWS Step Functions con stati Parallel e la concorrenza provisioned di Lambda non risolve il problema fondamentale del timeout dovuto all'elaborazione di singole immagini di grandi dimensioni, ma piuttosto la gestione di più invocazioni. L'utilizzo di Amazon ECS con compatibilità Amazon EC2 richiederebbe la gestione di server EC2, che l'azienda vuole evitare. L'archiviazione delle immagini su Amazon EFS e i metadati in Amazon RDS, con il montaggio di EFS da parte di Lambda, non risolve il problema del timeout di elaborazione, ma modifica solo la posizione di archiviazione.