„Wybrana” odpowiedź jest poprawna, ale chciałem dodać dodatkowe informacje, ponieważ większość osób korzystających jednocześnie z EB i RDS powinna mieć te same wymagania - nawet jeśli jeszcze tego nie wiedzą.
Pierwsze pytanie : dlaczego chcesz, aby instancja RDS istniała poza środowiskiem EB?
Odpowiedź : Aby czas życia instancji RDS nie był powiązany z czasem życia środowiska EB. tzn. kiedy usuwasz środowisko, nie chcesz z nim niszczyć bazy danych. Istnieje bardzo niewiele powodów, dla których warto powiązać instancję RDS ze środowiskiem.
Problem z konfiguracją RDS niezależnie od EB polega na tym, że zmienne RDS_ * nie są automatycznie zapełniane, dlatego trzeba je odzyskać i wypełnić je samodzielnie za pomocą konsoli internetowej lub rozszerzeń .ebext. Nie zaleca się jednak dodawania poświadczeń do kodu, ponieważ może to stanowić lukę w zabezpieczeniach.
Ale następnym problemem jest to, że jeśli chcesz programowo tworzyć środowiska (takie jak wdrożenia niebiesko-zielone z zerowym czasem przestoju), to potrzebujesz rozwiązania, w którym za każdym razem zapełnisz wrażliwe wartości RDS (np. Hasło). Niestety wymaga to zejścia dalej w dół stosu AWS i skorzystania z szablonu CloudFormation.
Idealnym rozwiązaniem jest rozszerzenie do EB, dzięki czemu wspomniany w pytaniu link „użyj istniejącej bazy danych” faktycznie pozwala ręcznie powiązać istniejącą bazę danych RDS, a następnie automatycznie zapełnić zmienne środowiskowe RDS_ *, zamiast przekierowywać do nieprzydatnej dokumentacji . Obsługa AWS powiedziała, że zostało to zgłoszone jako żądanie funkcji, ale oczywiście nie podano ram czasowych.