Aplikacja działa na pojedynczej instancji Amazon EC2 uruchomionej przez grupę Auto Scaling (min=1, max=1) w prywatnej podsieci. Aplikacja korzysta z instancji bazy danych Amazon RDS for MySQL. VPC ma podsieci w trzech Strefach Dostępności, ale wdrożona jest tylko jedna brama NAT. Architekt musi zapewnić, że aplikacja będzie mogła działać w wielu Strefach Dostępności. Które rozwiązanie spełnia ten wymóg?

Poprawna odpowiedź zapewnia wysoką dostępność aplikacji w wielu Strefach Dostępności. Wdrożenie dodatkowych bram NAT w każdej Strefie Dostępności i aktualizacja tabel routingu gwarantuje, że instancje EC2 w każdej AZ mają dostęp do Internetu. Konfiguracja RDS for MySQL w trybie Multi-AZ zapewnia automatyczne przełączanie awaryjne bazy danych w przypadku awarii AZ. Skonfigurowanie grupy Auto Scaling do uruchamiania instancji w różnych AZ i ustawienie minimalnej/maksymalnej pojemności na 3 (lub więcej niż 1) zapewnia, że aplikacja będzie działać nawet po awarii jednej AZ. Pozostałe opcje są nieprawidłowe, ponieważ: Zastąpienie bramy NAT bramą VPN nie jest rozwiązaniem dla dostępu do Internetu. Zastąpienie RDS for MySQL klastrem Aurora MySQL DB jest dobrą praktyką, ale nie rozwiązuje problemu pojedynczej bramy NAT. Zastąpienie bramy NAT instancją NAT wprowadza pojedynczy punkt awarii. Migracja do RDS for PostgreSQL nie rozwiązuje problemu wysokiej dostępności. Włączenie automatycznych kopii zapasowych RDS nie zapewnia wysokiej dostępności w przypadku awarii AZ. Utrzymanie minimalnej/maksymalnej pojemności Auto Scaling na 1 oznacza, że aplikacja przestanie działać po awarii AZ.