Elastic Beanstalk is a service provided by AWS that makes it easy for us to deploy and scale out applications for development/testing purposes. It is ideal for fast-paced environments where spinning up and down whole applications in a quick manner is needed.

In this article, we will review how to deploy a sample application using AWS Elastic Beanstalk with a Java sample application and an RDS MySQL database.

Now hands on to what we came from:

Walkthrough

In the AWS console, clic in the Services menu in the top left hand and search for the Elastic Beanstalk service. Once in it, choose the ‘Create application’ option.

Next, fill in the details of your new Beanstalk environment as follow:

• Application name: bitacora_app (or another of your preference)
• Platform: Here you can choose from among the most popular programming languages like .Net, Docker, Go, Java, Node.js, PHP, Python.
  In my case, I’ll pick Java, leaving the platform branch and version in its default values.
• Application code: For the simplicity of this example, choose ‘Sample application’. Note: You can also choose to upload your own code whether it is in your computer or on a public S3 bucket.
• Click on ‘Configure more options‘ to tune in the details of our environment.

Database

In the new screen, look for the Database section and clic ‘Edit’ to set the database engine and version of the database that will serve as a repository for the app.

Fill in the fields like this:

• Restore a snapshot: None. This works in case you have a snapshot of your own RDS instance or from a previous Beanstalk deployment, if you have any of those you can restore it here.
• Engine: Elastic Beanstalk works with the most used relational database engines in the market like MySQL, Oracle, PostgreSQL and SQL Server. In my case I’m choosing MySQL which means my database will be an RDS MySQL database.
• Engine version: 8.0.20 (or the latest known stable version)
• Instance class: db.t2.micro (Choosing this because of you know… free-tier)
• Username: testuser
• Password: ****** (one you can remember)
• Retention: Create snapshot. This will generate a snapshot of our database before the instance gets completely wiped out after termination. This is useful if we wish to use the final version of this database as a baseline for future deployments. You can also decide not to generate any snapshot by choosing the ‘Delete’ option.
• Availability: It can be either Low (only 1 AZ) or High (this will deploy standby databases in multiple Availability Zones for High Availability purposes. Here I’ll choose ‘High’ so we can appreciate the whole setup at the end.
• Clic ‘Save’. Back in the configuration screen, clic Edit in the ‘Network‘ option to choose an appropriate VPC and subnets for our instance.

Network

• Virtual private cloud (VPC): Choose the default VPC or create a new one.
• Instance settings: If your application needs to be exposed to the internet you can choose either to assign or not a Public IP address for your instances. In instance subnets, you need to select the Availability Zones you wish to deploy the app to in case of disaster. For example, if your application is on us-east-2a AZ (region: us-east-2) and need your app to remain available in case of failures in this AZ, you’ll need to select also us-east-2b. In my case, I’ll select the three available AZ and assign a Public IP.
• Database settings: Let’s apply the same instance settings to the database instances in order to replicate the data in the whole region: 3 AZ (us-east-2a, us-east-2b and us-east-2c).

Let´s leave every other sections as default and get prepared for deployment! Clic ‘Create app’ to launch our application with all the specified configurations. It will take a while but we can have some fun seeing how our environment is getting created:

Once finished we can see that our development environment has been created with the following resources:

1. One application URL. If you open it, it will show an app with the sample code we selected.
2. One RDS MySQL instance with Multi-AZ enabled.
3. One t2.micro EC2 instance with no Load Balancers and an Auto Scaling group with a minimum and a maximum capacity of 1.
4. One S3 bucket with Standard Storage class that hosts our application configuration files.

And here is a high-level graph of our environment architecture:

Si tienes alguna duda, comentarios o sugerencias, me puedes enviar un correo a bitácoradeundba@gmail.com.