COLIN BLOG

Getting Started With Fundamentals | AWS Elastic Beanstalk Survival Guide

A beginner guide to effectively deploy and manage application on AWS with Elastic Beanstalk
January 29, 2016

Chapter 2

Before we start deploying our application to Elastic Beanstalk, let us do a quick revision on the fundamentals of Elastic Beanstalk. Throughout the survival guide, we will be using terms that might not be familiar to you. Hence, it is important to get everyone on the same page before embarking on the rest of the survival guide.

Learning the Elastic Beanstalk lingo

If you have any experience with AWS, you should have known by now that AWS loves to come up with their own set of terminology which can throw you off.

Application

A Elastic Beanstalk Application is like our project folder. So if we have a project named “helloeb”, we will name our Elastic Beanstalk Application as helloeb.

Your application does not run within the Elastic Beanstalk Application. Remember, it is just a folder, right? Instead, your application is deployed and runs in an environment.

Environment

We create environments within Elastic Beanstalk Application which house different running version of our application. For example, a project might have both staging and production versions. We will then create two environment (helloeb-staging & helloeb-production) within the same Elastic Beanstalk Application.

Colin Toh Application and Environment View in management console.

Take note: We can technically create separate Elastic Beanstalk Application for two different application version. However, it is best practice to group relevant application versions under the same Elastic Beanstalk Application.

Environment Tier

There are two types of tier that we can choose for each environment:

The web server tier handles HTTP(S) requests while worker tier handles background-processing tasks. In this survival guide, we will be mainly talking about the web server tier.

Environment Health

From the management console, we are able to monitor our environment health in 4 different state with their respective colors.

Colin Toh

How do Elastic Beanstalk conducts health checks?

For a single instance environment, Elastic Beanstalk just monitor its EC2 instance status.

For a load-balanced environment, the load balancer will open a TCP connection with each instance every 30 seconds. If the instance acknowledges the connection, the instance is considered healthy.

In addition to the load balancer's health checks, Elastic Beanstalk also monitors the following for health checks:

Using Elastic Beanstalk CLI tool - eb

There are 3 ways that we can manage our application with:

  1. Elastic Beanstalk Management Console
  2. Elastic Beanstalk CLI tool eb
  3. Web API

Although Elastic Beanstalk comes with a nice management console for application management, we highly recommend to use it together with the Elastic Beanstalk CLI tool - eb for maximum efficiency.

eb provides us with high-level commands to manage and configure our Elastic Beanstalk applications within the terminal. The list is quite extensive but we will be mainly using these few commands for important tasks:

For the full list of EB CLI commands:
https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb3-cmd-commands.html

Install eb:
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb-cli3-install.html

Architectural Overview aka The Big Picture

It is crucial to understand the Elastic Beanstalk architecture and what resources were provisioned for us. Once we have good understanding of the big picture, we will be able to troubleshoot accordingly when the environment experiences red health status.

In fact, the architectural overview is not that complicated. Let's step through them in detail from the top to bottom.

Colin Toh Diagram of the architectural components of a web server tier environment.

Isolated Environment

First, we see that the solid blue line outlined the entire scope of a single environment. Within a Elastic Beanstalk Application, every environment is isolated from one another.

CNAME

All environment has a human-readable URL for easy access. Elastic Beanstalk provisioned for Amazon Route 53 to forward any requests to the CNAME record. Take note that the CNAME record is pointing towards the load balancer and not the instances.

As the instances belong to an auto-scaling group, the instance’s IP address is not static. Hence, if we point the CNAME to an instance, it will break when Auto Scaling decide to terminate the particular instance.

Load Balancer

Elastic Beanstalk will also provision a load-balancer to manage and direct traffic to multiple instances during high load. But when do the environment know to spin up new instances?

Auto-Scaling Group

This is solved by having an auto-scaling group. Once traffic surge pass a preset limit, Auto Scaling is triggered to spin up new instances to handle the high load. If traffic has reduced past a certain threshold, Auto Scaling will terminate excess instances.

Conclusion

We have come to the end of Chapter 2 of "AWS Elastic Beanstalk Survival Guide" and we are just getting started. In the next chapter, we will be seeing some real action with application deployment. So stay tuned.

Interested in this AWS Elastic Beanstalk Survival Guide Series, remember to subscribe below for updates

Elastic Beanstalk Survival Guide: Table Of Content

RSS