Chapter 2: Getting Started with Fundamentals

Colin Toh
AWS Elastic Beanstalk Survival Guide
5 min readJan 28, 2016
Illustrated by Jowin Tam

This article was originally posted at AWS Elastic Beanstalk Survival Guide: Getting Started With Fundamentals.

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.

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:

  • Web Server Tier
  • Worker Tier.

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.

  • Green — Environment has passed health checks. At least one EC2 connection is healthy and receiving request. However, this does not necessarily mean that your application is up and running.
  • Gray — Environment is currently updating. No deployment or management can take place when the health status is gray.
  • Yellow — Environment only partially passed health checks. Health checks are not consistently passing.
  • Red — Environment consistently fails health checks. Most likely environment resources are down. Check on the relevant resources like EC2, load balancers, RDS, etc.

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:

  • The environment’s Auto Scaling group is available and has a minimum of at least one instance.
  • The environment’s security group is available and is configured to allow incoming traffic on port 80.
  • The environment CNAME exists and is pointing to the right load balancer.

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:

  • eb initCreating Application
  • eb createCreating environment
  • eb consoleOpening Elastic Beanstalk Dashboard
  • eb listShow current environment
  • eb useSwitch environment
  • eb logsLogs Checking
  • eb deployDeployment

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.

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 how do the load balancer identify which instances can be utilise and 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.

♥ Like this article? Subscribe to the mailing list to get updates for the rest of the “AWS Elastic Beanstalk Survival Guide” series.

Elastic Beanstalk Survival Guide: Table Of Content

Chapter 1: Introduction

Chapter 2: Getting Started With Fundamentals

Chapter 3: How to deploy application on AWS Elastic Beanstalk

Chapter 4: How to configure AWS Elastic Beanstalk to scale

Chapter 5: How to map custom domain name for AWS Elastic Beanstalk

Chapter 6: How to configure SSL for AWS Elastic Beanstalk

--

--