Firma realizuje 3-letni projekt z aplikacją, która wykorzystuje 20 instancji Amazon EC2 On-Demand zarejestrowanych w grupie docelowej Network Load Balancer w dwóch strefach dostępności. Aplikacja jest bezstanowa i działa 24/7. Normalne wykorzystanie procesora wynosi około 10%, ale wzrasta do 100% podczas krótkich okresów wzmożonego ruchu trwających kilka godzin. Użytkownicy zgłaszają wolne odpowiedzi. Jaka nowa architektura rozwiąże problem wolnych odpowiedzi w sposób NAJBARDZIEJ opłacalny?

Poprawna odpowiedź to utworzenie grupy Auto Scaling z minimalną pojemnością 4 i maksymalną 28, oraz zakup Reserved Instances dla 4 instancji. Pozwala to na utrzymanie podstawowej liczby instancji po niższych kosztach dzięki RI, jednocześnie dynamicznie skalując się w górę (do 28 instancji) w okresach szczytowego obciążenia, aby zapewnić responsywność aplikacji. Skalowanie w dół w okresach niskiego ruchu minimalizuje koszty. Pozostałe opcje są mniej optymalne: Ustawienie minimalnej pojemności na 20 i pożądanej na 28 z RI dla 20 instancji nie rozwiąże problemu wolnych odpowiedzi, ponieważ aplikacja nadal będzie przeciążona przy 28 instancjach, a 20 RI to za dużo, gdy ruch jest niski. Spot Fleet z request type 'request' lub 'maintain' i DefaultTargetCapacityType na Spot nie jest odpowiednie dla aplikacji działającej 24/7, która wymaga ciągłej dostępności, ponieważ instancje Spot mogą zostać przerwane. Zastąpienie NLB przez ALB nie jest konieczne, ponieważ NLB jest odpowiedni dla bezstanowych aplikacji o wysokiej wydajności.