Which AWS Elastic Beanstalk Deployment Method Should You Use?

  • by Emre Yilmaz
  • Oct 8, 2018
  • AWS, DevOps
  • Istanbul
Elastic Beanstalk Deployment Methods

Let’s say that you are a developer building awesome applications using Node.js or Python, but lacking knowledge and experience necessary to configure AWS environments. No worries! Elastic Beanstalk can make your life easier by handling configuration details. It uses preconfigured CloudFormation templates and provisions a scalable, load balanced and reliable environment for your application. It supports lots of programming languages, giving you less control but less worry in return. You can start from a single instance and make your architecture grow into a multi-instance cluster.

Although it may sound simple until now, actually Elastic Beanstalk is more than this. It provides you many deployment options and you can select one of them depending on your environment and use case. In this post, I will explain the options and when to consider them.

Some words on Elastic Beanstalk

Elastic Beanstalk currently supports multiple programming platforms such as Go, Java SE, .NET on Windows Server with IIS, Node.js, PHP, Python, Ruby… Each of these platforms supports multiple versions and configurations. For example, you can choose Ruby 2.5 with Puma version 2.8.4 or Ruby 2.3 with Passenger version 2.8.4 or another configuration whichever suits your needs. In addition, it supports Docker containers allowing you to host custom applications using Docker. You can also create custom platforms or customize your environment using .ebextensions.

You have two type of environments on Elastic Beanstalk: Web server environments and worker environments. Web server environment is designed to serve web applications on the Internet whereas worker environments is designed to be used in background SQS message processing for decoupling your applications. In this post, our examples will be a web server environment.

As usual you have an application on Elastic Beanstalk and its versions. You can deploy the same version to multiple environments, but an environment can have only one application version running.

When you create an environment, Elastic Beanstalk creates a CloudFormation stack behind the scenes and this stack is visible on the CloudFormation console. Similarly, when you update an environment configuration or make a deployment it creates additional temporary stacks and/or updates the curent stack accordingly.

As you can see, the main purpose of Elastic Beanstalk simplifying provisioning and deployment process for developers. However, it also supports complex deployment automations which I will describe each below.

Base Scenario

Before continuing with the first deployment method, let’s describe our sample environment component:

  • An Elastic Load Balancer distributing traffic to the instances
  • 3 EC2 instances behind EC2 Autoscaling which is configured to scale minimum of 3 and maximum of 6 instances.

You can see the diagram below.

Elastic Beanstalk Environment

Now, let start describing deployment methods Elastic Beanstalk provides to us.

All At Once: Let’s deploy them to all!

As the name suggests, when you deploy your application in All At Once mode in Elastic Beanstalk; it starts the deployment on all EC2 instances at the same time. In our case, all 3 instances starts deploying.

It can be useful for fast deployments, but what if your deployment is faulty and fails?Believe me, it can always happen and will happen. Then, all your instances will fail and your load balancer will not be able to serve traffic because downtime. Both of them is a disaster if you host a production application. In this case, you need to deploy the previous version from application versions and wait for them to complete.

Elastic Beanstalk - All At Once

Why to use All At Once? I can only think for development and test environment purposes. Downtimes due to failed deployments should not effect your business use case.

Rolling: Let’s be more cautious and deploy one by one!

You can mitigate all fail mode of all at once by rolling deployments and switch to only one batch fails. When you deploy in Rolling mode, you also define the number of instances to be grouped in a batch. Let’s define the batch size as 1.

In the beginning, Elastic Beanstalk deploys the application version to the first batch and proceeds to next after it succeeded.

Elastic Beanstalk - Rolling

What happens if the deployment fails? Only failed instance will be effected and the effect on whole environment depends on when it failed.

  • If it failed in the first batch, the first instance will be down, both other instances will continue to serve the previous version.
  • If it failed in later batches, the failed instance will become unhealthy and there will be two versions served by your environment: The new version will be served by successful deployments until the failure and the previous version will be served by instances the deployment cancelled.

Elastic Beanstalk - Failure

In addition, your fleet size serving the application will be reduced by the batch size, as failed instances will not be able to serve traffic. But, you will not have downtime when compared to all at once deployments.

To rollback, you need to cancel deployment using AWS Management Console or AWS CLI or EB CLI and start redeployment of the known previous healthy version on the environment.

Rolling with additional batch: Let’s launch new instances and deploy on them!

As we saw in the previous section, in Rolling deployments, the fleet size serving traffic is reduced during deployments and in case of failures. To solve this problem, you can use Rolling with additional batch.

In this deployment, Elastic Beanstalk provisions a new batch of instances and starts by deploying the new version to them. Then, it will register the new instances to the load balancer and continues with the next batch of instances. After deployment is completed in all batches, it decreases the instances desired limit to the state where deployment started. In another words, it terminates the number of instances equal to the batch size it launched.

Elastic Beanstalk - Rolling with additional batch

What happens if this deployment fails? If the deployment is failed in the first batch, it terminates the failed instances when you cancel the deployment and because deployment is done on additional batch, nothing will be effected. Your fleet size will remain as it is and you do not need to do anything. Awesome! The effect is minimal.

However, if the deployment is failed after the first batch, again the failed batch will be terminated, but there will be two versions of your application served like in Rolling deployments without additional batch. You need to deploy the previous version again to rollback.

Elastic Beanstalk - Rolling with additional batch - Failure

When I tried this deployment method, I find it really safe if it fails in the first batch, because failed instances were replaced automatically. But, I could not simulate failures after the first batch, but it is possible.

Immutable: Let’s lauch new instances and deploy on them!

This deployment method regards your instances as immutable, they are not updated, simply replaced. When you deploy using immutable deployment type, Elastic Beanstalk will lauch new instances and duplicate the size of your fleet for a short period. Then, it will deploy the new version in new instances and terminate the old group after success.

Elastic Beanstalk - Immutable Deployments

Elastic Beanstalk - Immutable Success

As you might guess already, in case of a deployment failure the new instances will be terminated without effecting your availability.

Elastic Beanstalk - Immutable - Failure

What are the drawbacks? Well, when you duplicate the fleet, you are subject to AWS account limits and Elastic Beanstalk may fail to launch new instances if your fleet size is large. Also, it is slightly more costly then other deployments as you mostly update them in place or only launch one batch of instances during deployment. But on cloud, the cost effect is minimal as this is expected only for a few minutes.

This deployment method is definitely safer than previous methods.

Blue/Green: Duplicate the whole environment and swithc URLs.

Blue/Green deployments are simply replicating your current environment (blue), deploying the new application to your new, cloned environment (green) and redirect the traffic to the new environment after deployment.

If the deployment fails, you terminate the clone environment and nothing will be effected.

If something goes bad after deployment, for example, your users experience a problem in the new version, you simply redirecting the traffic back to the old version. Hence, it would be wise to keep the old environment until you are sure that the deployment is successful and DNS propogation completed.

Finally, you terminate the old environment and your cloned environment becomes your new blue one. You repeat the same process in all environments. It is a nearly zero-downtime deployment model and a best practice for mission critical applications.

How to perform Blue/Green deployments on Elastic Beanstalk?

As you deploy application versions on a selected environment, Blue/Green does not exist as a deployment type on Elastic Beanstalk deployments. Because you need to duplicate the environment as a whole including Elastic Load Balancers. However, this is very simple on Elastic Beanstalk and it is one of its strengths:

1) You clone the current environment using AWS Management Console or AWS CLI or EB CLI. It will create a replica of your environment along side with Elastic Load Balancers, Autoscaling Groups and other resources and deploy the current version on the instances.

2) After your new environment is ready, you deploy the new version on this environment and verify that the deployment is successful by testing.

Elastic Beanstalk - Blue Green Deployments - Clone

3) Once you are sure that everything is fine, you swap the urls of the two environments using AWS Management Console or AWS CLI or EB CLI. Then the traffic will start to flow to your new environment as DNS propogation completes.

Elastic Beanstalk - Blue Green Success

What are the prerequisites to apply Blue/Green?

One thing the note is that you are duplicating your environment and you are again subject to AWS account limits. Hence, your instance limit should cover new instances launched.

Secondly and even more importantly, your environment should not contain any RDS instances or any other databases because the data will not copied during environment cloning operation. Even it had, the two databases would not be in sync. So, swapping urls would not be applicable if you have a database resource inside your Elastic Beanstalk environment.


As you can see, Elastic Beanstalk is a very powerful platform to deploy your applications without worrying about the infrastructure. You can even apply DevOps principles using Blue/Green deployment method and other deployment types.

I hope after reading this post, you will have a clear picture on the deployment types Elastic Beanstalk provides.

Thanks for reading!



Freelance AWS Consultant, Instructor

CEO @ Shikisoft


Would you like to learn AWS CloudFormation?

Our new course AWS CloudFormation Step by Step: Beginner to Intermediate is live on Udemy!

Join us now with up to 90% discount using the coupon below!

Enroll now!

Subscribe to this blog's RSS feed