AWS Elastic Beanstalk explained

Introduction

In this post, we will learn about AWS Elastic Beanstalk service and how it can be used to help you deploy and scale your applications and services with ease and without you having to worry about provisioning components and implementing high availability features such as Elastic Load Balancing and Auto Scaling. All of this and more is managed and handled by Elastic Beanstalk.

AWS Elastic Beanstalk is a managed service that allows you to upload code of your web application along with environment configurations, which will then allow Elastic Beanstalk to automatically provision and deploy the appropriate and necessary resources required within AWS to make the web application operational.

These resources can include other AWS services and features, such as EC2, auto scaling, application health monitoring, and elastic load balancing, in addition to capacity provisioning. This automation and simplification makes it an ideal service for engineers who may not have the familiarity or the necessary skills within AWS to deploy, provision, monitor, and scale the correct environment themselves to run the developed applications. Instead, this responsibility is passed on to AWS Elastic Beanstalk to deploy the correct infrastructure to run the uploaded code. This provides a simple, effective, and quick solution to deploying your web application.

Once the application is up and running, you can continue to support and maintain the environment just as you would with a custom-built environment. You can additionally perform some of the maintenance tasks from the Elastic Beanstalk dashboard itself. AWS Elastic Beanstalk is able to operate with a variety of different platforms and programming languages, making it a very flexible service for your devops team.

One important point to note is that the service itself is free to use. There is no cost associated with Elastic Beanstalk. However, any resources that are created on your application’s behalf, such as EC2 instances, you will be charged for as per the standard pricing policy at the time of deployment.

Core Components

So now we know at a high level what AWS Elastic Beanstalk is and does. Let me run through some of its core components that creates this service.

  • Application version: An application version is a very specific reference to a section of deployable code. The application version will point typically to S3, the Simple Storage Service, to where the deployable code may reside.

  • Environment: An environment refers to an application version that has been deployed on AWS resources. These resources are configured and provisioned by AWS Elastic Beanstalk. At this stage, the application is deployed as a solution and becomes operational within your environment. The environment is comprised of all the resources created by Elastic Beanstalk and not just an EC2 instance with your uploaded code.

  • Environment configurations: An environment configuration is a collection of parameters and settings that dictate how an environment will have its resources provisioned by Elastic Beanstalk and how these resources will behave.

  • Environment tier: This component reflects on how Elastic Beanstalk provisions resources based on what the application is designed to do. If the application manages and handles HTTP requests, then the app will be run in a web server environment. If the application does not process HTTP requests and instead perhaps pulls data from an SQS Queue, then it would run in a work environment. I shall cover more on the differences between the web server and the work environments down below.

  • Configuration template: This is a template that provides the baseline for creating a new, unique environment configuration. Platform. A platform is a combination of components in which you can build your application upon using Elastic Beanstalk. These comprise of the operating system of the instance, the programming language, the server type, web or application, and components of Elastic Beanstalk itself, and as a whole can be defined as a platform.

  • Applications: Within Elastic Beanstalk, an application is a collection of different elements, such as environments, environment configurations, and application versions. In fact, you can have multiple application versions held within an application.

Environment Tiers

There are two different environment tiers that AWS Elastic Beanstalk uses to provision and build your application within.

As a quick recap, the environment tier reflects on how Elastic Beanstalk provisions resources based on what the application is designed to do.

Web Server Tier

The web server environment is typically used for standard web applications that operate and serve requests over HTTP port 80. This tier will typically use the following AWS resources in the environment.

  • Route 53. When an environment is created by Elastic Beanstalk, it has an associated URL as the one shown on the screen. Using the CNAME record in Route 53, this URL is aliased to an Elastic Load Balancer, an ELB.

  • Elastic Load Balancer. For every environment, you should have at least one ELB sitting in front of your EC2 instances that is referenced by Route 53 as just explained. This ELB will also integrate with an autoscaling group.

  • Auto scaling. Again, for every environment, you will also have an auto scaling group that will manage the capacity planning of your applications based on the load received. As and when required it will both add and remove EC2 instances to ensure your application meets the demands of its users.

  • EC2 instances. Within the environment, AWS Elastic Beanstalk will create a minimum of one EC2 instance to run your application. This EC2 instance will be a part of the auto scaling group.

  • Security groups. Your EC2 instances will be governed by a security group, which by default will allow port 80 open to everyone.

An important component within the environment is actually installed on every EC2 instance provisioned. This component is the Host Manager.

The Host Manager has a number of different key and fundamental responsibilities. And these include:

Worker Tier

The worker environment is slightly different and are used by applications that will have a backend processing task, which will interact with AWS SQS, the Simple Queue Service. This tier typically uses the following AWS resources within the environment:

  • SQS Queue: If you don’t already have an SQS Queue operational and configured, then as a part of the creation of the worker environment AWS Elastic Beanstalk will create one for you.

  • IAM Service Role: To allow your EC2 instances to monitor queue activity in the SQS Queue, each EC2 instance will have an associated instance profile role which contains a section within the policy as shown.

  • Auto scaling: An auto scaling group is created to ensure that performance isn’t impacted based on load.

  • EC2 instances: a minimum of one EC2 instance is used and is attached to the auto scaling group, and each EC2 instance in the environment will read from the same SQS Queue.

Difference b/w Web Tier and Worker Tier

Whereas the web tier used the Host Manager to perform some key tasks for Elastic Beanstalk, instead within a worker tier a Daemon is installed on every EC2 instance to pull requests from your SQS Queue. It will also then send data to the application allowing it to process the message. This is why the instance profile role is required to ensure permissions are given to read from a queue.

As you can see, there are clear differences between the two tiers, and it’s likely that you will use the two tiers in conjunction with each other, decoupled by the use of the simple queue service, allowing each environment to scale independently of one another depending on demand through auto scaling and Elastic Load Balancing.

One final point before I finish this section is that I want to make you aware that should you have the need for additional customization over what is provisioned by the service itself within these environments, then you can develop and add your own Elastic Beanstalk configuration files within your application source code. These are either written in a YAML or JSON based format. And these customization files need to be saved within the .config file extension and then stored within the .ebextensions folder of your source code.

Deployment Options

Elastic Beanstalk application deployments. Having an understanding of the different options that are available enables you to efficiently manage your infrastructure. Now Elastic Beanstalk provides the following deployment options.

  • All at once,
  • rolling,
  • rolling with additional batch, and
  • immutable.

Let’s assume you already have an environment created with an application deployed across a number of instances that are being managed by Elastic Beanstalk.

  • All at once deployment: is the default choice if you don’t specify any other option. If you needed to update your application within your Elastic Beanstalk environment. Using the all at once option will simply roll out the application to your resources all at the same time. And this would, of course, cause a disruption to your application while the update was in progress, which would, in turn, affect your end users.

  • Rolling: with a rolling deployment you are able to minimize the amount of disruption that is caused when using the all at once approach. When performing a rolling deployment, Elastic Beanstalk will deploy your application in batches, performing an update to just a portion of your resources at a time. Once the update is complete it will then perform the update on the next batch. This would mean that you have two different versions of the application running at the same time for a very short period. However, it also means that you can still serve requests and process information through your application while the deployment is gradually rolled out for your infrastructure.

  • Rolling with additional batch: The rolling with additional batch is much the same principle as rolling. Your environment is updated in batches until all your resources have the new update. However, with rolling deployments there is an impact to your available resources while the update is being applied. For example, let’s say during a rolling deployment Elastic Beanstalk creates four different batches. While the update is being applied, your application availability takes a 25% hit while one batch is being updated. With rolling with additional batch, Elastic Beanstalk adds another batch of instances within your environment to your resource pool to ensure application availability is not impacted. So in this case, your deployment would have five batches. And while the update was being applied to one of your existing batches, you would still have four remaining batches of instances maintaining operation. On completion of the update to all batches, Elastic Beanstalk would then terminate this additional batch of instances.

  • Immutable: immutable deployments will create an entirely new set of instances in parallel to your existing and older resources. These new instances will be served through a temporary autoscaling group behind your elastic load balancer. This means for a short period of time your environment would essentially double in size. However, once your new instances are deployed and have passed all the health checks the old environment would be removed and the autoscaling group updated. If your health checks fail for the new instances then Elastic Beanstalk would terminate them and delete the autoscaling group and traffic would continue to be served to your original environment.

Summary

Basic Health Reporting:

Advanced Health Reporting: