22

I have created my RDS instance before creating my Elastic Beanstalk environment. The two are working together with no problem, but I'd like them to be linked together, and have the RDS parameters accessible via the RDS_* environment variables.

The Elastic Beanstalk configuration page says:

You do not have a database. You can create a new RDS database or use an existing database.

Although the first link creates a RDS instance in-place and links it to the current environment, the second link just redirects to this documentation page., which unfortunately only explains how to create a new RDS instance, but not how to link an existing one.

How can I associate an existing RDS instance to my Elastic Beanstalk environment?

24

The "selected" answer is correct, but I wanted to add some extra information as most people using EB and RDS together should have the same requirement too - even if they don't know it yet.

First question: Why would you want the RDS instance to exist outside the EB environment? Answer: So that the lifetime of the RDS instance is not tied to the lifetime of the EB environment. i.e. when you remove an environment, you don't want to destroy the DB with it. There are very few reasons why you'd want to actually tie your RDS instance to your environment.

A problem with settings up RDS independently of EB is that you don't get the RDS_* variables automatically populated and therefore need to retrieve their values and populate them yourselves via web console or .ebextensions. It's not recommended that you add credentials to your code though, as that can be a security hole.

But then, the next problem is if you want to programmatically create environments (such as for blue-green zero downtime deployments) then you need a solution for how to populate the sensitive RDS values (e.g. password) every time. Unfortunately, this requires you to drop further down the AWS stack and use a CloudFormation template.

The ideal solution is an enhancement to EB so that the "use an existing database" link mentioned in the question actually lets you manually associate an existing RDS database and then have the RDS_* environment variables automatically populated again, rather than redirecting you to unhelpful documentation. AWS Support said this has been raised as a feature request but of course no timeframe given.

  • a year later and it still seems to be the case? – lifeofguenter Apr 7 '15 at 13:07
  • 1
    Still the case as far as I know. – rgareth Apr 8 '15 at 7:09
  • How do we bump this AWS? – matthew Apr 8 '16 at 14:23
  • a year later, its still the same. – Karan Kumar Sep 27 '16 at 14:35
  • Steps for adding rds docs.aws.amazon.com/elasticbeanstalk/latest/dg/… (just for completness for people like me searching it) They you don't create an enviroment configuration and load it through an configuration file on creation. This should add env vars, so as long as they do not change, this should be ok? – Manuel Jan 30 '17 at 14:34
18

Answer from the AWS support:

In order to associate an existing database to a EB Environment you have to take a snapshot of it via the Management Console and then choose "create a new RDS database" under the Data Layer. There does not appear to be a way to associate a running RDS instance to an existing EB Environment without launching a new one from a snapshot due to the way the RDS instance is tied into the Beanstalk environment's underlying Cloudformation stack. If you take a snapshot of your current RDS instance you can start it anew in EB if you wish.

If you want the RDS instance to exist outside of the environment you can simply provide the connection parameters as environment variables via the EB Console: Configuration -> Web Layer -> Software Configuration. Then, you can read the environment variable via PHP.

  • I took the second approach, defining environment variables with the RDS_* names to follow convention. The security groups are set pretty tight, but it still feels a little loose to put a DB password in an environment variable. – Joseph Sheedy Jan 21 '15 at 1:53
  • @velotron Same for me, but I got used to it! – Benjamin Jan 21 '15 at 11:12
2

I needed to this recently and also wanted to automate the steps using the AWS CLI/EB CLI. In any case, here are basically the steps I followed (assuming you already created an RDS instance):

  1. Make sure you have a different security group setup for your RDS instance (not the VPC default group). You can use aws ec2 create-security-group (AWS CLI) for that and associate it with the RDS instance using aws rds modify-db-instance (AWS CLI).
  2. Initialize your beanstalk application (I used eb init (EB CLI) for that).
  3. Read relevant configuration data from your RDS database (DB name, host name, port, etc). I used aws rds describe-db-instances for that.
  4. Using that data set the RDS_* environment variables on the EB instance when you create the environment (or deploy the environment later). You can do this with eb create/eb deploy (EB CLI). When you create the environment initially it will be degraded, since the security groups to access the RDS database are not set up properly.
  5. Get the relevant security groups from the EB configuration. You need the one for the autoscaling group and for the elastic load balancer. You can use aws elasticbeanstalk describe-configuration-settings (AWS CLI) for that.
  6. Authorize your autoscaling group for inbound traffic to your database for the security group you set up in step 1. I used aws ec2 authorize-security-group-ingress (AWS CLI) for that, which uses VPC security groups (not DB security groups). You can probably achieve the same with DB security groups if they are supported in your region. When setting up the inbound traffic rule make sure you use the right protocal and port for your database engine.
  7. Add the elastic load balancer group to the security groups of your RDS instance (again using aws rds modify-db-instance (AWS CLI)).
  8. Reboot or redeploy the Elastic Beanstalk application (e.g. using eb deploy (EB CLI)). I had to do a redeploy, since I run migrations on deployments.

That is mostly it. Now you should be able to scale up/down your RDS instances without care of the EB instances, as long you keep the hostname and DB credentials the same. You can also do blue/green deployments with that approach (but you might need to do some extra steps to also revoke security group access).

0

The easiest to add an existing security group to EB EC2 instances by configuration is to use the simple file described in https://github.com/awsdocs/elastic-beanstalk-samples/blob/master/configuration-files/aws-provided/security-configuration/securitygroup-addexisting.config

For example:

$ cat .ebextensions/securitygroup-addexisting.config
option_settings:
  - namespace: aws:autoscaling:launchconfiguration
    option_name: SecurityGroups
    value: rds-launch-wizard-1
0

I was facing same issue and fixed using following steps :

1) Go to EC2 instance and note your security group example "sg-121212121212"

2) GO to RDS Security Group ad=nd inbound traffic

3) Edit rule select all traffic and add your new ebs security group "sg-121212121212"

Hope it will helpful

-2

create RDS under Elastic; it will add new correct security group; modify security group of old existed RDS; set correct connection string at web config and all work...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.