Une entreprise a déployé une application sur AWS Elastic Beanstalk et a défini la capacité désirée du groupe Auto Scaling de l'environnement à cinq instances EC2. Si la capacité tombe en dessous de quatre instances pendant les déploiements, les performances de l'application se dégradent. L'environnement utilise la politique de déploiement « all-at-once ». Quel est le changement le PLUS rentable pour éviter le problème de performance pendant les déploiements ?

L'option correcte est de modifier la politique de déploiement en « rolling with additional batch » et de définir la taille du lot additionnel à 1. Cette stratégie garantit qu'une instance supplémentaire est lancée avant de commencer le déploiement sur les instances existantes. Avec une capacité désirée de cinq instances, l'ajout d'une instance supplémentaire (portant le total à six) permet de maintenir au moins cinq instances saines et opérationnelles pendant le déploiement progressif, évitant ainsi la dégradation des performances. Modifier la capacité désirée à six instances ne résout pas le problème du déploiement « all-at-once » qui mettrait toutes les instances hors service simultanément. La politique « traffic splitting » est plus coûteuse et complexe, et un temps d'évaluation d'une heure est trop long pour un déploiement rapide. La politique « rolling » avec un lot de 2 réduirait le nombre d'instances disponibles à trois (5 - 2 = 3) pendant le déploiement, ce qui est inférieur au seuil de quatre instances.