Une application s'exécutant sur EC2 interroge un système de fichiers Amazon EFS pour détecter de nouveaux fichiers. Lorsqu'un nouveau fichier apparaît, l'application sélectionne une image de conteneur Docker pour traiter le fichier, démarre le conteneur approprié et transmet l'emplacement du fichier. Le traitement peut prendre jusqu'à 2 heures ; une fois terminé, le conteneur écrit le résultat dans EFS et se termine. L'entreprise souhaite supprimer les instances EC2 qui exécutent ces conteneurs. Quelle approche de refactoring répond à cette exigence ?

La solution correcte refactorise l'application pour utiliser AWS Fargate pour le traitement conteneurisé, éliminant ainsi les instances EC2. Elle déplace la logique de sélection des conteneurs vers une fonction AWS Lambda, qui peut être invoquée par des événements. Le déplacement du stockage des fichiers vers Amazon S3 est crucial car S3 peut déclencher directement des notifications d'événements (par exemple, s3:ObjectCreated:) vers Lambda, ce qui n'est pas possible avec EFS. EFS ne prend pas en charge les notifications d'événements directes pour les ajouts de fichiers, ce qui rend les options qui tentent de le faire incorrectes. L'option incorrecte qui utilise des fonctions Lambda comme images de conteneurs pour le traitement est moins adaptée car les tâches de traitement peuvent durer jusqu'à 2 heures, dépassant la durée maximale d'exécution de 15 minutes de Lambda.