AWS Elastic Beanstalk — Day 18

AWS Elastic Beanstalk — Day 18

In the ever-evolving landscape of cloud computing, managing applications efficiently is crucial. AWS Elastic Beanstalk is a service designed to simplify the deployment, scaling, and management of web applications and services developed with popular programming languages, frameworks, and containers.

Understanding AWS Elastic Beanstalk

AWS Elastic Beanstalk operates as a Platform as a Service (PaaS) offering within the Amazon Web Services (AWS) ecosystem. It abstracts away the underlying infrastructure, allowing developers to focus solely on their application code.

Key Features:

  1. Ease of Use: Elastic Beanstalk streamlines the deployment process by automatically handling capacity provisioning, load balancing, auto-scaling, and application health monitoring.

  2. Support for Various Environments: It supports a variety of programming languages such as Java, Python, Node.js, Ruby, PHP, .NET, and more. This flexibility enables developers to choose their preferred language and environment.

  3. Simple Configuration: Elastic Beanstalk allows customization of environments through configuration files, giving developers control over settings like instance types, databases, load balancers, and security.

  4. Monitoring and Scaling: It provides built-in monitoring tools and the ability to automatically scale resources based on application demand, ensuring optimal performance without manual intervention.

  5. Integration with AWS Services: Seamlessly integrates with other AWS services like RDS (Relational Database Service), S3 (Simple Storage Service), and CloudWatch, enhancing functionality and scalability.

Getting Started with Elastic Beanstalk

1. Creating an Application:

  • Access the AWS Management Console and navigate to Elastic Beanstalk.

  • Click on “Create Application” and provide details such as application name, platform, and deployment options.

2. Uploading Application Code:

  • Upload the application code either directly or through version control systems like Git.

  • Define configuration settings for the application environment.

3. Deploying the Application:

  • Elastic Beanstalk handles the provisioning of resources based on specified configurations.

  • The application is automatically deployed and made available to users.

4. Monitoring and Management:

  • Utilize the monitoring dashboard to track application health, performance metrics, and resource utilization.

  • Adjust configurations or enable auto-scaling to manage traffic fluctuations efficiently.

Advantages of Elastic Beanstalk

  • Reduced Complexity: Abstracts away infrastructure management complexities, enabling developers to focus on coding.

  • Rapid Deployment: Streamlined deployment processes result in faster time-to-market for applications.

  • Scalability: Allows applications to seamlessly handle varying levels of traffic without manual intervention.

  • Cost-Effectiveness: Pay only for the AWS resources consumed, minimizing unnecessary expenses.

Limitations and Considerations

  • Platform Limitations: While it supports various languages, there might be limitations or delays in adopting the latest language features or versions.

  • Customization Challenges: Advanced configurations might require additional AWS services or manual setups outside Elastic Beanstalk.

AWS Elastic Beanstalk Components

There are certain key concepts that you will come across frequently when you deploy an application on Beanstalk. Let us have a look at those concepts:


  • An application in Elastic Beanstalk is conceptually similar to a folder

  • An application is a collection of components including environments, versions and environment configuration

Application Version:

  • An application version refers to a specific, labeled iteration of deployable code for a web application.

  • An application version points to an Amazon S3 object that contains the deployable code such as a Java WAR file


  • Environments within the Elastic Beanstalk Application is where the current version of the application will be active

  • Each environment runs only a single application version at a time. But it is possible to run the same or different versions of an application in many environments at the same time

Environment Tier:

Based on requirement beanstalk offers two different Environment tiers: Web Server Environment, Worker Environment

  • Web Server Environment: Handles HTTP requests from clients

  • Worker Environment: Processes background tasks that are resource-consuming and time-intensive

Here is an illustration to show how the Application, Application version and Environments relate to each other:

Here is how Beanstalk Environment using default container type looks like:

Now that you know about different key concepts about Elastic Beanstalk, let's understand the architecture of Elastic Beanstalk.

AWS Elastic Beanstalk Architecture

Before getting into AWS Elastic Beanstalk architecture, let’s answer the most frequently asked question,

What is an Elastic Beanstalk Environment?

Environment refers to the current version of the application. When you launch an Environment for your application, Beanstalk asks you to choose among two different Environment Tiers i.e, Web Server Environment or Worker Environment. Let’s understand them one by one.

Web Server Environment

Application version which is installed on the Web Server Environment handles HTTP requests from the client. The following diagram illustrates an example of AWS Elastic Beanstalk architecture for a Web Server Environment tier and shows how the components in that type of Environment Tier work together.

Beanstalk Environment — The Environment is the heart of the application. When you launch an Environment, Beanstalk assigns various resources that are needed to run the application successfully.

Elastic Load Balancer — When the application receives multiple requests from a client, Amazon Route53 forwards these requests to the Elastic Load Balancer. The load balancer distributes the requests among EC2 instances of the Auto Scaling Group.

Auto Scaling Group — Auto Scaling Group automatically starts additional Amazon EC2 instances to accommodate the increasing load on your application. If the load on your application decreases, Amazon EC2 Auto Scaling stops instances but always leaves at least one instance running.

Host Manager — It is a software component that runs on every EC2 instance that has been assigned to your application. The host manager is responsible for various things like

  • Generating and monitoring application log files

  • Generating instance-level events

  • Monitoring application server

Security Groups — A Security Group is like a firewall for your instance. Elastic Beanstalk has a default security group, which allows the client to access the application using HTTP Port 80. It also provides you with an option where you can define security groups to the database server as well. The below image summarizes what we have learned about Web Server Environment.

So that’s all about the Web Server Environment. But what if the application version installed on Web Server Tier keeps denying multiple requests because it has encountered time-intensive and resource-consuming tasks while handling a request? Well, this is where the Worker Tier comes into the picture.

Worker Environment

A worker is a separate background process that assists the Web Server Tier by handling resource-intensive or time-intensive operations. In addition, it also emails notifications, generates reports and cleans up databases. This makes it possible for the application to remain responsive and handle multiple requests.

That’s great, but how does the Worker process know which tasks to handle and when? How do these two Environment tiers communicate? For that, we use a message queuing service by AWS called Amazon Simple Queue Service (SQS). The image below gives you a rough idea of how the worker process receives and handles background tasks.

The workflow of the worker process is fairly simple. When you launch a Worker Environment tier, Elastic Beanstalk installs a daemon on each EC2 instance in the Auto Scaling group. The daemon pulls requests sent from an Amazon SQS queue. Based on the queue’s priority, SQS will send the message via a POST Requests to the HTTP Path of the Worker Environment. The worker on receiving the message executes the tasks and sends an HTTP response once the operation is done. SQS on receiving a response message deletes the message in the queue. If it fails to receive a response, it will continuously retry sending the messages.