Deweloper zarządza trzema kontami AWS, z których każde ma instancję Amazon RDS w prywatnej podsieci. Deweloper musi spójnie tworzyć, a później aktualizować użytkowników bazy danych na wszystkich trzech kontach przy minimalnym wysiłku operacyjnym. Które podejście zapewnia największą efektywność operacyjną?

Poprawna odpowiedź to stworzenie szablonu CloudFormation, który używa niestandardowego zasobu do tworzenia użytkowników bazy danych, a następnie wdrożenie tego szablonu na każdym koncie. Niestandardowy zasób CloudFormation pozwala na rozszerzenie możliwości CloudFormation o logikę tworzenia i zarządzania użytkownikami baz danych RDS, co nie jest natywnie obsługiwane przez CloudFormation. Wdrożenie tego samego szablonu na wszystkich kontach zapewnia spójność i minimalizuje wysiłek operacyjny, ponieważ zmiany w logice zarządzania użytkownikami są wprowadzane raz w szablonie. Tworzenie szablonu CloudFormation deklarującego użytkowników i przypisującego ich do bazy danych jest nieprawidłowe, ponieważ CloudFormation nie ma wbudowanej obsługi do bezpośredniego zarządzania użytkownikami baz danych RDS. Skrypt na instancjach EC2 wymagałby zarządzania tymi instancjami i ręcznego uruchamiania skryptów, co zwiększa wysiłek operacyjny i ryzyko błędów. Funkcja Lambda wymagałaby zarządzania uprawnieniami i szczegółami połączeń dla wszystkich trzech kont w jednej funkcji, co może być mniej skalowalne i trudniejsze w utrzymaniu niż podejście oparte na CloudFormation.