Deploy Apps Your Way with Elastic Beanstalk

AWS Elastic Beanstalk is a managed service that handles the details of deploying and managing applications on Amazon Elastic Compute Cloud (Amazon EC2). For an introduction and getting started tutorial, see Hello Beanstalk. In this post, we'll review the different ways you can handle deployments with Beanstalk.

Extensive Deployment Options

Beanstalk supports a rich collection of deployment options for updating your environments, called deployment policies. You can configure an environment's deployment policy in the AWS console.

Let's review the deployment policies one by one.

All at Once: The Brute Force Update

All at once deployments deploy the new version to all instances simultaneously. This means all instances in your environment will go out of service for a short time during deployment. There's no additional cost with this form of deployment because no additional instances are allocated. This is the fastest way to deploy, but only use it if you can tolerate brief downtime. I recommend it for non-production environments.

In the console, select the All at once deployment policy. There are no other settings to configure for this policy.

Deployment policies and settings - AWS Elastic Beanstalk

Rolling Updates: Your Table is Next

Rolling updates avoid downtime and minimize reduced availability, at the cost of a longer deployment. This is a good option if you can't handle any downtime. Rolling updates work by updating batches of instances at a time. As each batch is updated, its instances go temporarily out of service.

Through settings you can control the batch size. You can either set a fixed number of instances, or specify a percentage of the total number of EC2 instances in the auto scaling group.

While a rolling deployment is in process, both versions of the application are running simultaneously. Your capacity is reduced by the one batch that is being updated. If a Rolling update fails, then an additional rolling update is necessary to roll back the changes.

Rolling with Additional Batch: I Want It All

This is a variation of a rolling update that creates an extra batch in order to maintain full capacity throughout the update. You end up with the same number of instances you started with, but your capacity is not reduced during the deployment thanks to the extra batch.

You configure this policy with the same settings as Rolling to set the batch size.

There's a small additional cost for the extra batch during deployment.

Immutable: Behold, All Things Are Made New

Immutable environment updates are an alternative to rolling updates. Beanstalk creates brand-new instances in a new auto scaling group to deploy the new version to, then removes the older instances after a successful health check. Immutable updates ensure that configuration changes that require replacing instances are applied efficiently and safely.

Once the new version is deployed to the new instances, the load balancer cuts over to the new auto-scaling group and the original instances are deleted.

As with Rolling updates, you specify a batch size, either as a fixed number of instances or a percentage of the auto-scaling group.

Immutable updates take the longest amount of time and are the most expensive, as you are temporarily doubling your instances. However, immutable updates are low-impact on failure and have a quick rollback. If an environment update fails, the rollback process requires only terminating an auto scaling group.

Traffic Splitting: The Canary Sings

Traffic-splitting deployments allow you to perform canary testing. The new version is deployed to a fresh group of instances. Traffic is temporarily split between the existing application and the new one. If a health check passes, remaining traffic is shifted over as well.

Through settings you control the initial traffic split percentage of incoming traffic that is shifted to the new environment, and the traffic splitting evaluation time, the number of minutes to evaluate health and proceed to shift all traffic over.

Blue-Green Deployment: The Shoe is on the Other Foot

The blue-green deployment pattern deploys the new version to a separate environment. You can then swap the URLs of the two environments. This redirects traffic to the new version instantly. You can roll back just as easily, with another URL swap.

To perform a blue-green deployment, you clone your current environment in the AWS Beanstalk console or launch a new environment. Then, you deploy the new version to the new environment. After testing the new environment, you swap environment URLs.

Swap environment URL page

You hold on to the older environment for as long as you need to, knowing that you can roll back quickly if a problem arises with the new version.

Summary

As we've seen, AWS Elastic Beanstalk supports more methods of deployment than most compute cloud services. Choose the deployment approach that best suits your combined requirements for deployment time, downtime, impact of failure, and cost.

Here's a summary of the deployment options and their characteristics.

Deployment Policy	Downtime	Deploy time	Impact of Failure	Rollback process
All at once	down	1-shortest	downtime	Manual redeploy
Rolling	zero downtime	2-long	single batch out of service, earlier successful batches running new version	Manual redeploy
Rolling with an additional batch	zero downtime	3-longer	minimal if first batch fails, otherwise similar to Rolling	Manual redeploy
Immutable	zero downtime	4-longest	minimal	Terminate new instances
Traffic splitting	zero downtime	4-longest	percentage of traffic routing to new version temporarily impacted	Reroute traffic and terminate new instances
Blue/green	zero downtime	4-longest	minimal	Swap URL