Seamless Production Deployment with Elastic Beanstalk

Introduction

Production deployments can be complicated. You want to avoid disruption to your users and minimize downtime, but you also need to consider cost, time, risk, and how to recover from a failed deployment. You can balance the trade-offs between these considerations by choosing a deployment strategy.

AWS Elastic Beanstalk is a managed AWS compute service that supports a rich collection of deployment strategies. In this post, I’ll review the different deployment methods available and what to consider in choosing the right one for your application and users.

Deployment Strategies

Elastic Beanstalk supports 6 different deployment strategies, compared in Figure 1. Consider the relative importance of downtime, deployment time, the impact of failure, and rollback process when choosing a deployment strategy.

Figure 1: comparison of deployment strategies

When you create an Elastic Beanstalk environment, you can specify a deployment policy of All at once, Rolling, Rolling with additional batch, Immutable, or Traffic Splitting. Figure 2 shows what that looks like in the AWS console.

Figure 2: Selecting a deployment policy for an environment in the AWS console     

In addition to these policies, you can perform blue-green deployments by uploading a new application version to a staging environment and then swapping URLs (CNAMEs) with production.

All at once

All at once deployments deploy the new version to all instances simultaneously. This is the quickest and least expensive deployment method, but also the only one that incurs downtime. All of your instances will go out of service for a short time. This is a good choice if you can tolerate brief downtime and value quick deployments.

Figure 3: All at once deployment

To use this method, select the All at once deployment policy when creating an environment. There are no other settings to configure for this policy. If you need to rollback from a deployment failure, you can redeploy a previous version. For instructions, refer to Redeploying a previous version in the AWS Elastic Beanstalk Developer Guide.

Rolling

Rolling deployments divide your instances into batches, and update one batch at a time. As each batch is updated, its instances go temporarily out of service, but the rest of your instances stay up and running. Both old and new versions of the application are running during deployment. This approach avoids downtime, but your capacity is reduced by the one batch that is currently being updated. This is a good choice when you can tolerate slightly reduced bandwidth during the deployment.

Figure 4: Rolling update

To use this method, select the Rolling deployment policy when creating an environment. Specify a 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. During a rolling deployment, both old and new versions of the application are running. If a rolling update fails, then another update is necessary to roll back the changes.

Figure 5: Configuring rolling deployment batch size

If a rolling update fails, you can check the health of instances in your environment for information about the failure. To roll back, perform another deployment with a corrected or known good version of your application.

Rolling with additional batch

Rolling with additional batch deployments address the chief shortcoming of rolling deployments: one batch is out of service, reducing overall capacity. This variation creates an extra batch and maintains full capacity throughout the update. You end up with the same number of instances you started with. There’s an additional cost incurred for the extra batch during deployment. This is a good choice when you can’t tolerate a reduction in capacity.

 Figure 6: Rolling with extra batch deployment

To use this method, select the Rolling with additional batch deployment policy when creating an environment, and specify a batch size. Rollback on failure is handled just like rolling updates. For more information refer to How rolling deployments work in the developer guide,

Immutable

Immutable deployments are an alternative to rolling updates. Elastic Beanstalk creates an entire new set of instances to deploy the new version to, after which the original instances are terminated. 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.

Figure 7: Immutable deployment

To use this method, select the Immutable deployment policy when creating an environment, and specify a batch size.

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 merely terminating an auto scaling group. For more information, refer to Immutable environment updates in the developer guide.

Traffic Splitting

If the new instances don’t pass health checks, or if you choose to abort the deployment, Elastic Beanstalk moves traffic back to the old instances and terminates the new ones. There’s never any service interruption.

Traffic-splitting deployments allow you to perform canary testing. The new version is deployed to a fresh group of instances, just like immutable deployments. Traffic is temporarily split between the existing application and the new one. If a health check passes, all remaining traffic is shifted over as well and the old instances are terminated. Choose this method when you want to test the health of your new application version with only a portion of incoming traffic, while serving the old version to the rest.

Figure 8: Traffic splitting

To use this method, select the Traffic splitting deployment policy when creating an environment. Specify a batch size, the percentage of traffic to send to the new version, and the amount of time to evaluate before switching all traffic over.

Figure 9: Configuring traffic splitting

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. Rolling back a deployment to the previous version is quick and doesn’t disruptive. For more information, refer to How traffic splitting deployments work.

Blue-Green Deployment

The blue-green deployment pattern deploys the new version to a separate environment. You can then swap the URLs (CNAMEs) of the two environments. This redirects traffic to the new version instantly.  This is a good choice when you want to maintain full capacity and quickly cutover from old version to new.

Figure 10: Blue-green deployment

To perform a blue-green deployment, you first clone your current environment in the AWS Beanstalk console or launch a new environment. Next, you deploy the new version to the new environment. After testing the new environment, you swap environment URLs. You can roll back just as easily, with another URL swap. For more information, refer to Blue/green deployments with Elastic Beanstalk in the developer guide,

Conclusion

In this post, I explained and compared the different deployment strategies available for AWS Elastic Beanstalk. I invite you to explore and evaluate them, including practicing rollback for operational readiness. For detailed information on deployment and rollback, refer to the AWS Elastic Beanstalk Developer Guide. For general AWS guidance on using deployment methods in continuous integration, refer to Practicing Continuous Integration and Delivery on AWS and Automating safe, hands-off deployments.