Architekt rozwiązań musi stworzyć plan odzyskiwania po awarii dla platformy SaaS o dużym wolumenie danych, której dane są przechowywane w klastrze Amazon Aurora MySQL DB. Plan DR musi replikować dane do pomocniczego regionu AWS. Które rozwiązanie spełni te wymagania w NAJBARDZIEJ opłacalny sposób?

Prawidłowa odpowiedź to skonfigurowanie globalnej bazy danych Aurora dla klastra DB, a następnie usunięcie instancji DB z regionu pomocniczego. Globalna baza danych Aurora zapewnia szybką i niezawodną replikację danych między regionami AWS, co jest kluczowe dla odzyskiwania po awarii. Usunięcie instancji DB z regionu pomocniczego po konfiguracji minimalizuje koszty, ponieważ płaci się tylko za przechowywanie danych i transfer replikacji, a nie za uruchomione instancje DB, dopóki nie zajdzie potrzeba przełączenia awaryjnego. Pozostałe opcje są mniej optymalne kosztowo lub technicznie: Replikacja dziennika binarnego MySQL jest bardziej złożona w zarządzaniu i może wymagać ręcznej konfiguracji, co zwiększa ryzyko błędów i koszty operacyjne. Udostępnienie jednej instancji DB w regionie pomocniczym generuje stałe koszty. AWS DMS jest dobrym rozwiązaniem do migracji, ale do ciągłej replikacji w scenariuszu DR, Globalna Baza Danych Aurora jest bardziej zintegrowana i zoptymalizowana, a usunięcie instancji DB z regionu pomocniczego nie jest typowym scenariuszem dla DMS. Skonfigurowanie globalnej bazy danych Aurora i określenie minimum jednej instancji DB w regionie pomocniczym jest funkcjonalne, ale nie jest najbardziej opłacalne, ponieważ instancja DB w regionie pomocniczym generuje stałe koszty, nawet jeśli nie jest aktywnie używana.