Aplikacja HTTP firmy znajduje się za Network Load Balancerem (NLB). Grupa docelowa NLB korzysta z grupy Auto Scaling Amazon EC2 z wieloma instancjami EC2 uruchamiającymi usługę sieciową. NLB nie wykrywa błędów HTTP, które wymagają ręcznego ponownego uruchamiania instancji EC2 usługi sieciowej. Firma chce poprawić dostępność bez pisania niestandardowych skryptów lub kodu. Co powinien zrobić architekt rozwiązań?

Poprawna odpowiedź to zastąpienie NLB przez Application Load Balancer (ALB) i skonfigurowanie kontroli stanu HTTP. Network Load Balancer (NLB) działa na warstwie 4 (transportowej) i nie jest w stanie interpretować protokołu HTTP, co oznacza, że nie może wykrywać błędów HTTP. Application Load Balancer (ALB) działa na warstwie 7 (aplikacji) i może wykonywać kontrole stanu HTTP, monitorując odpowiedzi aplikacji. W przypadku wykrycia błędów HTTP, ALB oznaczy instancję jako niezdrową, a grupa Auto Scaling może automatycznie zastąpić tę instancję, poprawiając dostępność bez niestandardowych skryptów. Włączenie kontroli stanu HTTP w NLB jest niemożliwe, ponieważ NLB nie obsługuje protokołu HTTP. Dodanie zadania cron wymagałoby niestandardowego kodu i nie jest rozwiązaniem zarządzanym przez AWS. Tworzenie alarmu CloudWatch monitorującego UnhealthyHostCount dla NLB nie rozwiąże problemu, ponieważ NLB nie wykrywa błędów HTTP, więc metryka ta nie odzwierciedlałaby problemów z aplikacją.