Aplikacja migrowana do AWS ma statyczny interfejs użytkownika (frontend) działający obecnie na dwóch instancjach EC2 za ALB oraz backend w Pythonie na trzech instancjach EC2 za innym ALB. Instancje to duże, ogólnego przeznaczenia typy On-Demand, dobrane pod kątem szczytowego obciążenia w środowisku lokalnym, ale ruch jest skoncentrowany w porze lunchu, a poza tym jest niewielki. Architekt rozwiązań musi zmniejszyć koszty infrastruktury bez szkody dla dostępności. Które kombinacje działań należy podjąć? (Wybierz dwie.)

Przeniesienie frontendu na statyczną witrynę hostowaną w Amazon S3 jest wysoce opłacalne, ponieważ S3 jest usługą bezserwerową, która eliminuje koszty instancji EC2, ALB i zarządzania nimi, a także skaluje się automatycznie. Migracja backendu na instancje EC2 typu burstable (np. T-series) jest odpowiednia, ponieważ ruch jest skoncentrowany w porze lunchu, a poza tym jest niewielki. Instancje te są tańsze niż instancje ogólnego przeznaczenia i zapewniają wystarczającą wydajność w okresach szczytowego obciążenia dzięki możliwościom burstu, jednocześnie obniżając koszty w okresach niskiego ruchu. Zmiana na instancje zoptymalizowane pod kątem obliczeń nie obniży kosztów, a może je nawet zwiększyć, jeśli nie są one w pełni wykorzystywane. Wdrożenie frontendu w Elastic Beanstalk nadal wiąże się z kosztami instancji EC2. Użycie Spot Instances dla backendu może prowadzić do przerw w działaniu, co narusza wymaganie dostępności.