Firma uruchamia aplikację na instancjach EC2 w grupie Auto Scaling za Application Load Balancer (ALB). Podczas uruchamiania instancje uruchamiają skrypty user-data, aby pobrać krytyczną zawartość aplikacji z zasobnika S3. Instancje uruchamiają się, ale po pewnym czasie zostają zakończone z komunikatem: „An instance was taken out of service in response to an ELB system health check failure.” Auto Scaling wielokrotnie uruchamia i kończy instancje w pętli. Jedyną ostatnią zmianą było dodanie dużej ilości krytycznej zawartości do zasobnika S3. Firma nie chce modyfikować skryptów user-data w środowisku produkcyjnym. Co powinien zrobić architekt rozwiązań, aby środowisko produkcyjne mogło zostać pomyślnie wdrożone?

Problem polega na tym, że instancje są kończone, zanim zdążą pobrać całą zawartość z S3 i poprawnie zainicjować aplikację, co skutkuje niepowodzeniem kontroli stanu ALB. Zwiększenie okresu prolongaty sprawdzania stanu grupy Auto Scaling (health check grace period) daje nowo uruchomionym instancjom więcej czasu na pełne uruchomienie i zainicjowanie aplikacji, zanim Auto Scaling lub ALB zaczną je sprawdzać. Dzięki temu instancje nie zostaną przedwcześnie zakończone. Zwiększenie rozmiaru instancji EC2 może nie rozwiązać problemu, jeśli opóźnienie wynika z pobierania danych, a nie z mocy obliczeniowej. Zwiększenie limitu czasu sprawdzania stanu ALB nie pomoże, jeśli instancja w ogóle nie odpowiada na kontrolę stanu. Zmiana ścieżki sprawdzania stanu ALB nie jest rozwiązaniem, ponieważ problemem jest czas inicjalizacji, a nie sama ścieżka.