Home » AWS Certification Cheat Sheets » AWS Certified Developer

Associate Cheat Sheets » AWS Compute » Elastic Beanstalk

AWS Elastic Beanstalk

AWS Elastic Beanstalk can be used to quickly deploy and manage
applications in the AWS Cloud.

Developers upload applications and Elastic Beanstalk handles the

deployment details of capacity provisioning, load balancing, auto-scaling,
and application health monitoring.

AWS Elastic Beanstalk leverages Elastic Load Balancing and Auto Scaling to
automatically scale your application in and out based on your application’s
specific needs.

In addition, multiple availability zones give you an option to improve

application reliability and availability by running in more than one zone.

Considered a Platform as a Service (PaaS) solution.

Supports Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker web
applications.

Supports the following languages and development stacks:

Apache Tomcat for Java applications.

Apache HTTP Server for PHP applications.
Apache HTTP Server for Python applications.
Nginx or Apache HTTP Server for Node.js applications.
Passenger or Puma for Ruby applications.
Microsoft IIS 7.5, 8.0, and 8.5 for .NET applications.
Java SE.
 Docker.
Go.

Deploys to server platforms such as Apache Tomcat, Nginx, Passenger,

Puma, and IIS.

Developers can focus on writing code and don’t need to worry about
deploying infrastructure.

You maintain full control of the underlying resources.

You pay only for the resources provisioned, not for Elastic Beanstalk itself.

Elastic Beanstalk automatically scales your application up and down.

You can select the EC2 instance type that is optimal for your application.

Can retain full administrative control or have Elastic Beanstalk do it for you.

The Managed Platform Updates feature automatically applies updates for

your operating system, Java, PHP, Node.js etc.

Elastic Beanstalk monitors and manages application health and information is

viewable via a dashboard.

AWS CloudFormation is used by Elastic Beanstalk to deploy the resources.

Integrated with CloudWatch and X-Ray for performance data and metrics.

Elastic Beanstalk Layers

There are several layers that make up Elastic Beanstalk and each layer is
described below:

Application:
 Within Elastic Beanstalk, an application is a collection of different
elements, such as environments, environment configurations, and
application versions.
You can have multiple application versions held within an application.

Application version:

An application version is a very specific reference to a section of

deployable code.
The application version will point typically to an Amazon s3 bucket
containing the code.

Environment:

An environment refers to an application version that has been deployed on

AWS resources.
The resources are configured and provisioned by AWS Elastic Beanstalk.
The environment is comprised of all the resources created by Elastic
Beanstalk and not just an EC2 instance with your uploaded code.

Environment tier:
 Determines how Elastic Beanstalk provisions resources based on what the
application is designed to do.
Web servers are standard applications that listen for and then process
HTTP requests, typically over port 80.
Workers are specialized applications that have a background processing
task that listens for messages on an Amazon SQS queue.

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.

Configuration template:

This is a template that provides the baseline for creating a new, unique
environment configuration.

Elastic Beanstalk Deployment Options | AWS Certifie…

Certifie…

Click the image above to watch the FREE Video Tutorial on Elastic Beanstalk
Deployment Options
Deployment Options
AWS Elastic Beanstalk provides several options for how deployments are
processed, including deployment policies and options that let you configure
batch size and health check behavior during deployments.

Deployment options
Single instance: great for development.

High availability with load balancer: great for production.

Deployment policies

The deployment policies are: All at once, Rolling, Rolling with additional

batch, and Immutable.

All at once:

Deploys the new version to all instances simultaneously.

All of your instances are out of service while the deployment takes place.
Fastest deployment.
Good for quick iterations in the development environment.
You will experience an outage while the deployment is taking place – not
ideal for mission-critical systems.
If the update fails, you need to roll back the changes by re-deploying the
original version to all of your instances.
No additional cost.

Rolling:

Update a few instances at a time (batch), and then move onto the next
batch once the first batch is healthy (downtime for 1 batch at a time).
The application is running both versions simultaneously.
Each batch of instances is taken out of service while the deployment takes
place.
 Your environment capacity will be reduced by the number of instances in a
batch while the deployment takes place.
Not ideal for performance-sensitive systems.
If the update fails, you need to perform an additional rolling update to roll
back the changes.
No additional cost.
Long deployment time.

Rolling with additional batch:

Like Rolling but launches new instances in a batch ensuring that there is
full availability.
The application is running at capacity.
You can set the bucket size.
The application is running both versions simultaneously.
Small additional cost.
Additional batch is removed at the end of the deployment.
Longer deployment.
Good for production environments.

Immutable:

Launches new instances in a new ASG and deploys the version update to
these instances before swapping traffic to these instances once healthy.
Zero downtime.
New code is deployed to new instances using an ASG.
High cost as double the number of instances running during updates.
Longest deployment.
Quick rollback in case of failures.
Great for production environments.

Additionally, Elastic Beanstalk supports blue/green deployment.

Blue / Green deployment:

This is not a feature within Elastic Beanstalk

You create a new “staging” environment and deploy updates there.
 The new environment (green) can be validated independently and you can
roll back if there are issues.
Route 53 can be set up using weighted policies to redirect a percentage of
traffic to the staging environment.
Using Elastic Beanstalk, you can “swap URLs” when done with the
environment test.
Zero downtime.

The following tables summarizes the different deployment policies:

Elastic Beanstalk CLI

There is an additional CLI called “eb cli”.

The EB CLI is a command-line interface for AWS Elastic Beanstalk that

provides interactive commands that simplify creating, updating and
monitoring environments from a local repository.

You can use the EB CLI as part of your everyday development and testing
cycle as an alternative to the Elastic Beanstalk console.

Security
Elastic Beanstalk works with HTTPS:
 Load the SSL certificate onto the load balancer.
Can be performed from the console or in code
(.ebextensions/securelistener-alb.config).
SSL certificate can be provisioned using ACM or CLI.

For redirecting HTTP to HTTPS:

Configure in the application.

Configure the ALB with a rule.
Ensure health checks are not redirected.

Lifecycle Policies
Elastic Beanstalk can store at most 1000 application versions.

To phase out old versions use a lifecycle policy:

Time-based – specify max age.

Count based – specify max number to retain.

Versions that are in use will not be deleted.

Option to not delete the source bundle in S3 to prevent data loss.

Worker environments
If an application performs tasks that take a long time to complete (long-
running tasks), offload to a worker environment.

It allows you to decouple your application tiers.

Can define periodic tasks in the cron.yaml file.

Elastic Beanstalk Extensions
You can add AWS Elastic Beanstalk configuration files (.ebextensions) to your
web application’s source code to configure your environment and customize
the AWS resources that it contains.

Customization includes defining packages to install, create Linux users and

groups, running shell commands, specifying services to enable, configuring a
load balancer, etc.

Configuration files are YAML- or JSON-formatted documents with a .config

file extension that you place in a folder named .ebextensions and deploy in
your application source bundle.

The .ebextensions folder must be included in the top-level directory of your

application source code bundle.

All the parameters set in the UI can be configured in the code.

Requirements:

Must be located in the .ebextensions/ directory of the source code.

 YAML or JSON format.
.config extensions can be included (e.g. logging.config).
You can modify some default settings using “option_settings”.
You can add resources such as RDS, ElastiCache, and DynamoDB.

Resources managed by .ebextensions get deleted if the environment is

terminated.

Elastic Beanstalk with Amazon Relational Database Service

(RDS)
You can deploy Amazon RDS within an Elastic Beanstalk environment as in
the diagram below:

However, if you terminate your Elastic Beanstalk environment you also lose
the database.

The use case is only for development environments, typically not suitable for
production.
For production, it is preferable to create the Amazon RDS database outside of
Elastic Beanstalk as in the diagram below:

Steps to migrate from RDS within a Beanstalk environment to standalone

RDS:

Take a snapshot of the RDS DB.

Enable deletion protection on the RDS DB.
Create a new environment without an RDS DB and point applications to the
existing RDS DB.
Perform a blue/green deployment and swap the new and old
environments.
Terminate the old environment (RDS will not be deleted due to termination
protection).
Delete the CloudFormation stack (will be in the DELETE_FAILED state).

Connecting to an Amazon RDS database

When the environment update is complete, the DB instance’s hostname and
other connection information are available to your application through the
following environment properties:

RDS_HOSTNAME – The hostname of the DB instance.

RDS_PORT – The port on which the DB instance accepts connections. The
default value varies among DB engines.
RDS_DB_NAME – The database name, ebdb.
RDS_USERNAME – The user name that you configured for your database.
RDS_PASSWORD – The password that you configured for your database.

Get Started Find Answers

AWS Certification Path Latest Blog Articles

Free AWS Certication Guide FAQ

AWS Training Courses Join our Slack Channels

AWS Practice Exams Join our Facebook Group

AWS Books for Offline Study Join our LinkedIn Group

Connect Follow

About us Facebook

Connect with Neal LinkedIn

Contact us Youtube

Submit Feedback Twitter

Join our Team Instagram

AWS Training Resources

AWS Cloud Practitioner

AWS Solutions Architect

AWS Developer Associate

AWS SysOps Administrator

AWS Solutions Architect PRO

AWS Certification Training - Master Amazon Web Services

© 2021 Digital Cloud Training | Privacy Policy | Terms of Service | Sitemap