Elastic Beanstalk
Elastic Beanstalk is a Platform as a Service environment which can create and manage infrastructure for application code.



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


Deployment Policies
AWS Elastic Beanstalk provides several options for how deployments are processed, including deployment policies (All at once, Rolling, Rolling with additional batch, Immutable, and Traffic splitting) and options that let you configure batch size and health check behavior during deployments

All at once - Deploys the new version to all instances simultaneously
Rolling - Update a batch of instances, and then move onto the next batch once the first batch is healthy
Rolling with additional batch - Like Rolling but launches new instances in a batch ensuring that there is full availability
Immutable - Launches new instances in a new ASG and deploys the version update to these instances before swapping traffic to these instances once healthy
Blue/green - Create a new "stage" environment and deploy updates there

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 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


Rolling with additional batch

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)
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 Update

Like Rolling but launches new instances in a batch ensuring that there is full availability
Application is running at capacity
Can set the batch size
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
Traffic Splitting

Blue Green


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 setup using weighted policies to redirect a a percentage of traffic to the staging environment
Using Elastic Beanstalk, you can "swap URLs" when done with the environment test
Zero downtime
Environments and RDS



Advanced Customisation via .ebextensions
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.
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.

HTTPS

Cloning
You can use an existing Elastic Beanstalk environment as the basis for a new environment by cloning the existing environment.
For example, you might want to create a clone so that you can use a newer version of the platform branch used by the original environment's platform.
Elastic Beanstalk configures the clone with the same environment settings used by the original environment.
By cloning an existing environment instead of creating a new environment, you don't have to manually configure option settings, environment variables, and other settings.
Elastic Beanstalk also creates a copy of any AWS resource associated with the original environment.
However, during the cloning process, Elastic Beanstalk doesn't copy data from Amazon RDS to the clone.
After you create the clone environment, you can modify environment configuration settings as needed.

Docker
AWS Elastic Beanstalk can launch Docker environments by building an image described in a Dockerfile
or pulling a remote Docker image.
If you're deploying a remote Docker image, you don't need to include a Dockerfile
. Instead, if you are also using Docker Compose, use a docker-compose.yml
file, which specifies an image to use and additional configuration options.
If you are not using Docker Compose with your Docker environments, use a Dockerrun.aws.json
file instead.

Docker - Multi-Container


Web Servers and Workers
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
Workers should be used for long-running tasks

Last updated