Your team has a tomcat-based Java application you need to deploy into development, test
and production environments. After some research, you opt to use Elastic Beanstalk due to its
tight integration with your developer tools and RDS due to its ease of management. Your QA
team lead points out that you need to roll a sanitized set of production data into your
environment on a nightly basis. Similarly, other software teams in your org want access to
that same restored data via their EC2 instances in your VPC .The optimal setup for
persistence and security that meets the above requirements would be the following.
Create your RDS instance as part of your Elastic Beanstalk definition and alter its security group
to allow access to it from hosts in your application subnets.
Create your RDS instance separately and add its IP address to your application’s DB connection
strings in your code Alter its security group to allow access to it from hosts within your VPC’s IP
Create your RDS instance separately and pass its DNS name to your app’s DB connection string
as an environment variable. Create a security group for client machines and add it as a valid
source for DB traffic to the security group of the RDS instance itself.
Create your RDS instance separately and pass its DNS name to your’s DB connection string as
an environment variable Alter its security group to allow access to It from hosts In your application
Elastic Beanstalk provides support for running Amazon RDS instances in your Elastic
Beanstalk environment. This works great for development and testing environments, but is
not ideal for a production environment because it ties the lifecycle of the database instance to
the lifecycle of your application’s environment.