Aplikacja korzysta z klastra Amazon Aurora Multi-AZ DB zgodnego z MySQL, z repliką do odczytu między regionami, w celu odzyskiwania po awarii. Inżynier DevOps musi zautomatyzować promowanie repliki do roli głównej, jeśli główna instancja ulegnie awarii. Które rozwiązanie to umożliwi?

Poprawna odpowiedź automatyzuje promowanie repliki i aktualizację punktu końcowego w scentralizowanym miejscu. Przechowywanie punktu końcowego Aurora w AWS Systems Manager Parameter Store umożliwia aplikacji dynamiczne pobieranie aktualnego punktu końcowego. Amazon EventBridge może wykryć awarię bazy danych (np. poprzez zdarzenia RDS), uruchamiając funkcję AWS Lambda. Ta funkcja Lambda promuje replikę do roli głównej i aktualizuje Parameter Store nowym punktem końcowym. Aplikacja jest zaprogramowana tak, aby w przypadku awarii połączenia z bazą danych, ponownie załadować punkt końcowy z Parameter Store, co zapewnia ciągłość działania. Pozostałe opcje są mniej efektywne: Route 53 CNAME z kontrolami stanu i SNS/Lambda do promowania repliki nie zapewnia automatycznej aktualizacji punktu końcowego, do którego aplikacja się łączy. Tworzenie niestandardowego punktu końcowego Aurora i modyfikacja go przez Lambda jest możliwe, ale EventBridge jest bardziej elastycznym mechanizmem wyzwalania niż CloudTrail dla tego scenariusza. Modyfikowanie szablonu CloudFormation w celu promowania repliki jest zbyt złożone i nieoptymalne dla szybkiego przełączania awaryjnego.