Grupa Auto Scaling dla aplikacji internetowej doświadcza powolnego skalowania w poziomie (scale-out), ponieważ skrypty uruchamiania instancji (bootstrapping) zajmują dużo czasu. Administrator chce skrócić czas potrzebny na obsługę ruchu podczas skalowania w poziomie bez zwiększania nadmiernej pojemności. Która zmiana najskuteczniej to osiągnie?

Skonfigurowanie warm pool dla grupy Auto Scaling jest najskuteczniejszym rozwiązaniem, ponieważ pozwala na utrzymywanie instancji w stanie wstępnie zainicjowanym (np. po uruchomieniu skryptów bootstrappingu), ale nieaktywnym. Gdy wymagane jest skalowanie w poziomie, te instancje są szybko wprowadzane do grupy Auto Scaling, znacznie skracając czas potrzebny na obsługę ruchu bez ponoszenia pełnych kosztów za nieużywaną pojemność. Modyfikacja konfiguracji uruchamiania na większe typy instancji nie rozwiązuje problemu długiego czasu uruchamiania. Zwiększenie minimalnej liczby instancji zwiększa nadmierną pojemność. Dodanie polityki skalowania predykcyjnego może pomóc, ale warm pool jest bardziej bezpośrednim rozwiązaniem problemu długiego czasu uruchamiania instancji.