A resposta "selecionada" está correta, mas eu queria adicionar algumas informações extras, pois a maioria das pessoas que usam EB e RDS juntas também deve ter o mesmo requisito - mesmo que ainda não o conheçam.
Primeira pergunta : Por que você deseja que a instância do RDS exista fora do ambiente EB?
Resposta : para que o tempo de vida da instância do RDS não esteja vinculado ao tempo de vida do ambiente EB. ou seja, quando você remove um ambiente, não deseja destruir o banco de dados com ele. Existem muito poucas razões pelas quais você deseja realmente vincular sua instância do RDS ao seu ambiente.
Um problema com a configuração do RDS independentemente do EB é que você não obtém as variáveis RDS_ * preenchidas automaticamente e, portanto, precisa recuperar seus valores e preenchê-los por meio do console da web ou extensões. Não é recomendável adicionar credenciais ao seu código, pois isso pode ser uma falha de segurança.
Mas, então, o próximo problema é que, se você deseja criar ambientes de programação (como implantações de tempo de inatividade zero em azul e verde), precisa de uma solução para preencher os valores sensíveis do RDS (por exemplo, senha) todas as vezes. Infelizmente, isso exige que você desça ainda mais a pilha da AWS e use um modelo CloudFormation.
A solução ideal é um aprimoramento do EB, para que o link "use a existente database" mencionado na pergunta permita associar manualmente um banco de dados RDS existente e, em seguida, tenha as variáveis de ambiente RDS_ * preenchidas automaticamente novamente, em vez de redirecioná-lo para a documentação inútil . O Suporte da AWS disse que isso foi levantado como uma solicitação de recurso, mas é claro que não há prazo previsto.