Krytyczna aplikacja działa na pojedynczej instancji EC2 i wykorzystuje jednowęzłowy klaster ElastiCache for Redis oraz instancję bazy danych RDS for MariaDB. Każdy komponent musi być sprawny i aktywny, aby aplikacja działała. Musisz przeprojektować infrastrukturę tak, aby mogła automatycznie odzyskiwać się po awariach z minimalnym czasem przestoju. Jaką kombinację zmian należy wdrożyć? (Wybierz trzy.)

Aby zapewnić wysoką dostępność i automatyczne odzyskiwanie, należy wdrożyć redundancję na każdym poziomie. Umieszczenie instancji aplikacji za Elastic Load Balancer i uruchomienie wielu instancji EC2 w grupie Auto Scaling z minimalną pojemnością dwóch instancji zapewnia odporność na awarie pojedynczej instancji EC2 i automatyczne skalowanie. Modyfikacja instancji bazy danych RDS, aby używała wdrożenia Multi-AZ, gwarantuje automatyczne przełączanie awaryjne do repliki w innej strefie dostępności w przypadku awarii podstawowej bazy danych, minimalizując przestoje. Utworzenie grupy replikacji dla ElastiCache for Redis i włączenie Multi-AZ dla klastra zapewnia wysoką dostępność pamięci podręcznej, automatycznie przełączając się na replikę w przypadku awarii węzła głównego. Opcja z grupą EC2 Auto Scaling w trybie nieograniczonym nie jest odpowiednia, ponieważ nie zapewnia minimalnej liczby instancji dla wysokiej dostępności. Utworzenie repliki odczytu RDS w tej samej strefie dostępności nie chroni przed awarią całej strefy. Konfiguracja ElastiCache for Redis z grupą Auto Scaling nie jest standardowym ani zalecanym sposobem na zapewnienie wysokiej dostępności dla ElastiCache; zamiast tego używa się grup replikacji z Multi-AZ.