Podczas premiery gry firma uruchomiła 12 instancji Amazon EC2 r6g.16xlarge (zoptymalizowanych pod kątem pamięci) za Network Load Balancerem. Monitorowanie wykazało, że rzeczywiste użycie procesora i pamięci wynosiło około jednej czwartej oczekiwanej wartości. Zapotrzebowanie spadło i stało się bardziej zmienne. Firma zastąpi stałą flotę grupą Auto Scaling, która skaluje się w oparciu o procesor i pamięć, aby zminimalizować koszty. Jaka konfiguracja Auto Scaling jest najbardziej opłacalna, spełniając jednocześnie wymagania?

Prawidłowa jest opcja użycia instancji r6g.4xlarge. Początkowe instancje r6g.16xlarge były zoptymalizowane pod kątem pamięci, a ich rzeczywiste użycie procesora i pamięci wynosiło około jednej czwartej oczekiwanej wartości. Oznacza to, że potrzebne są mniejsze instancje, ale nadal zoptymalizowane pod kątem pamięci. r6g.4xlarge to mniejsza wersja r6g.16xlarge, zachowująca optymalizację pamięci. Zmniejszenie rozmiaru instancji o czterokrotnie (16xlarge do 4xlarge) odpowiada czterokrotnie mniejszemu wykorzystaniu zasobów. Minimalna pojemność 3 instancji r6g.4xlarge zapewnia podobną moc obliczeniową do jednej instancji r6g.16xlarge, co jest rozsądnym punktem wyjścia dla zmiennego obciążenia. Pozostałe opcje są nieprawidłowe, ponieważ c6g.4xlarge są zoptymalizowane pod kątem obliczeń, a m6g.4xlarge są ogólnego przeznaczenia, co nie odpowiada pierwotnej optymalizacji pamięci. Opcja z r6g.8xlarge jest mniej opłacalna, ponieważ instancje są większe niż to konieczne.