Migracja typu lift-and-shift pozostawiła pojedynczą grupę Auto Scaling, w której każda instancja EC2 uruchamia komponenty webowe, bazodanowe i pamięci podręcznej Redis, co powoduje zmienne czasy odpowiedzi i przeciążone instancje. Firma chce rozdzielić komponenty, aby poprawić dostępność i wydajność. Która zmiana architektury spełni to wymaganie?

Prawidłowa odpowiedź rozdziela komponenty na dedykowane usługi AWS, co poprawia dostępność i wydajność. Application Load Balancer (ALB) jest idealny dla aplikacji webowych, oferując zaawansowane funkcje routingu i skalowania. Amazon Aurora z Multi-AZ zapewnia wysoką dostępność i skalowalność dla bazy danych. Amazon ElastiCache (Redis OSS) to zarządzana usługa pamięci podręcznej, która znacząco poprawia wydajność, odciążając bazę danych. Pozostałe opcje są mniej optymalne: Pierwsza opcja błędnie sugeruje użycie Network Load Balancer (NLB) dla aplikacji webowej, który jest przeznaczony dla ruchu na poziomie 4, oraz tworzenie grupy Auto Scaling dla pamięci podręcznej Redis, co nie jest typowym wzorcem dla zarządzanej usługi ElastiCache. Druga opcja sugeruje NLB dla pamięci podręcznej Redis w pojedynczej strefie dostępności, co obniża dostępność. Trzecia opcja błędnie sugeruje NLB dla aplikacji webowej i tworzenie grupy docelowej z celami DNS wskazującymi na nazwę hosta ElastiCache, co jest niepotrzebne, ponieważ ElastiCache jest zarządzaną usługą.