Firma uruchamia trójwarstwową aplikację internetową on-premises: frontend Apache, monolityczną warstwę pośrednią Java i pamięć masową PostgreSQL. Ostatnia promocja przeciążyła wszystkie warstwy, aplikacja uległa awarii, a baza danych osiągnęła limity pojemności odczytu. Planowanych jest kilka promocji. Musisz zaprojektować migrację do AWS, która zmaksymalizuje skalowalność i zminimalizuje wysiłek operacyjny. Które trzy kroki to osiągną? (Wybierz trzy.)

Przebudowa frontendu do serwowania zasobów statycznych z Amazon S3 i użycie CloudFront maksymalizuje skalowalność i minimalizuje obciążenie serwerów aplikacji, jednocześnie poprawiając wydajność dla użytkowników. Migracja aplikacji Java do AWS Elastic Beanstalk z auto scalingiem zapewnia automatyczne skalowanie warstwy pośredniej w odpowiedzi na obciążenie, redukując wysiłek operacyjny. Użycie AWS DMS do migracji PostgreSQL do Amazon Aurora PostgreSQL z Aurora Auto Scaling dla replik odczytu rozwiązuje problem limitów pojemności odczytu i zapewnia wysoką skalowalność bazy danych. Przeniesienie frontendu Apache na instancje EC2 z EFS nie jest optymalne, ponieważ EFS jest droższe i wolniejsze dla zasobów statycznych niż S3/CloudFront. Przebudowa aplikacji Java na kontenery Docker i uruchomienie na Fargate jest dobrym rozwiązaniem, ale Elastic Beanstalk jest prostszy w zarządzaniu dla istniejącej aplikacji monolitycznej, minimalizując wysiłek operacyjny. Przeniesienie bazy danych na większą instancję EC2 nie rozwiązuje problemu skalowania odczytów i nie jest tak skalowalne ani zarządzane jak Aurora.