AWS Elastic Beanstalk provides different options for how application code is deployed into an environment, depending on if you want your application to be available all during the deployment, or can sustain a little downtime or want to split your traffic to a new deployment version for testing. These are called Deployment Policies.
Elastic Beanstalk offers the following deployment policies –
All at Once –
This is the default deployment policy applied, if your application code runs on a single instance or your application is not set to be scalable. In this approach, AWS deploys your application to all the instances in the environment at the same time, which causes your application to be unavailable for sometime.
This is the quickest deployment of all the available policies. Code is deployed to the existing instances and in case of any issues, you need to rollback by redeploying manually.
Rolling –
This is the default deployment policy applied if your application is configured to be scalable. In this approach, the code is deployed to your instances in batches, where in every batch one set of instances are deployed.
This means that for every iteration, there are a set of instances which are down and they are not available to serve traffic for a while, meaning reduced availability. Code is deployed to the existing instances and in case of any issues, you need to rollback by redeploying manually.
Rolling with additional batch –
This deployment policy is similar to Rolling deployment, wherein the code is deployed to your instances in batches. But in this case Beanstalk first spins up a new batch of temporary instances that run the existing application code. The code is deployed to the set of existing instances, and if the deployment is successful the temporary instances are terminated. This process then continues until all the instances are deployed with the new code. Due to the launch of temporary instances and termination for every batch, this approach takes an even longer deployment time than others but caters to the reduced availability in the case of Rolling deployment. In case of any issues, you need to rollback by redeploying manually.
Immutable –
This deployment policy is a bit different from the previous three, because here the code is always deployed to a new set of instances instead of existing. This approach is a bit slower, but has the advantage of a quick and safe rollback without any issues.
In this approach, a second Auto Scaling group is launched in your environment with identical configuration and count of instances, and the new version serves traffic alongside the old version until the new instances pass health checks.
In case of any issues, the new auto scaling group is terminated. In this approach, at a given point of time you may find the capacity of the environment doubled for a short period of time, while the new version is deployed and health checks are performed.
Traffic splitting –
This is a canary testing deployment method. In this approach, you can direct a portion of incoming traffic to your new application for testing while the other traffic is routed to the old application version.
Similar to immutable, you have a new set of instances launched with the new application version and have the traffic split via the load balancer. In case of any issues, you just need to reroute traffic and terminate the new instances.
| Deployment Policy | Features |
| All at Once | * Default policy applied, if application is not set to be scalable * New version deployed to all instances at once * Quickest deployment * Has downtime * Manual Rollback if failed |
| Rolling | * Default policy applied, if application is set to be scalable * New version deployed to instances in batches * Slower deployment * No downtime, but reduced Availability * Manual Rollback if failed |
| Rolling with additional batch | * New batch of temporary instances with old version is first created * New version deployed to instances in batches, temp instances removed if successful * Slower deployment than Rolling * No downtime, and caters to reduced Availability of Rolling * Manual Rollback if failed |
| Immutable | * A new Auto scaling group with same count of instances are first created * New version deployed to instances in new group, old instances are removed after health checks are green * Slower deployment * No downtime, and always Available * If failed, the new instances are terminated * Environment has double capacity for a short while, till health checks |
| Traffic splitting | * A new Auto scaling group with same count of instances are first created * New version deployed to instances in new group, a portion of traffic sent to new group for canary testing * Slower deployment * No downtime, and always Available * If failed, the new instances are terminated |
Documentation – https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.deploy-existing-version.html
Found this article helpful? Please consider supporting!
