Firma wdrożyła aplikację na AWS Elastic Beanstalk i ustawiła pożądaną pojemność grupy Auto Scaling środowiska na pięć instancji EC2. Jeśli pojemność spadnie poniżej czterech instancji podczas wdrożeń, wydajność aplikacji ulega pogorszeniu. Środowisko używa polityki wdrożenia all-at-once. Jaka jest NAJBARDZIEJ opłacalna zmiana, aby zapobiec problemom z wydajnością podczas wdrożeń?

Poprawna odpowiedź to zmiana polityki wdrożenia na rolling with additional batch i ustawienie additional batch size na 1. Ta polityka wdrożenia zapewnia, że podczas aktualizacji Elastic Beanstalk uruchomi dodatkową instancję (additional batch size = 1) zanim zacznie wyłączać stare instancje. Dzięki temu minimalna liczba działających instancji nigdy nie spadnie poniżej początkowej pożądanej pojemności (pięciu instancji), co zapobiegnie spadkowi wydajności. Zmiana pożądanej pojemności na sześć instancji byłaby skuteczna, ale mniej opłacalna, ponieważ oznaczałaby stałe utrzymywanie dodatkowej instancji. Polityka traffic splitting jest bardziej złożona i nie rozwiązuje bezpośrednio problemu utrzymania minimalnej liczby instancji podczas wdrożenia. Polityka rolling z batch size 2 nadal mogłaby prowadzić do spadku liczby instancji poniżej czterech, ponieważ jednocześnie wyłączałaby dwie instancje, zanim uruchomiłaby nowe.