Aplikacja intensywnie przetwarzająca dane działa na setkach instancji EC2 i obecnie korzysta ze współdzielonego systemu plików hostowanego na kilku instancjach EC2 zawierających 200 TB danych. Raz w miesiącu uruchamiane jest zadanie, które odczytuje podzbiór plików, działa około 72 godzin, a instancje obliczeniowe skalują się w grupie Auto Scaling. Instancje EC2 hostujące współdzielony system plików są zawsze uruchomione. Wszystkie zasoby znajdują się w tym samym regionie. Musisz zastąpić serwery współdzielonego systemu plików, aby zmniejszyć koszty, jednocześnie zapewniając wysoką wydajność dostępu dla 72-godzinnego zadania. Która opcja zapewni NAJWIĘKSZĄ ogólną redukcję kosztów, spełniając jednocześnie wymagania?

Poprawna odpowiedź minimalizuje koszty, wykorzystując Amazon S3 Intelligent-Tiering do długoterminowego przechowywania danych, co jest znacznie tańsze niż stałe utrzymywanie instancji EC2 z dyskami. Amazon FSx for Lustre jest tworzony na żądanie przed zadaniem, co zapewnia wysoką wydajność dostępu do danych dla intensywnych obliczeń, a następnie usuwany, eliminując koszty, gdy nie jest używany. Lazy loading z S3 dodatkowo optymalizuje koszty, pobierając dane tylko wtedy, gdy są potrzebne. Niepoprawne opcje: Użycie woluminu EBS z Multi-Attach nie jest idealne dla 200 TB danych i setek instancji, ponieważ EBS ma ograniczenia dotyczące rozmiaru woluminu i liczby jednoczesnych załączeń, a także nie jest to rozwiązanie współdzielonego systemu plików. Wsadowe ładowanie danych do FSx for Lustre z S3 jest droższe i czasochłonne niż lazy loading, zwłaszcza dla 200 TB danych. AWS Storage Gateway File Gateway nie jest przeznaczone do dostarczania wysokiej wydajności dla intensywnych zadań obliczeniowych na setkach instancji i jest droższe niż bezpośrednie użycie FSx for Lustre.