AWS Elastic Beanstalk: Enabling Continuous Deployment with Zero Downtime and Immediate Rollback

Continuous Deployment with Zero Downtime for AWS Elastic Beanstalk Applications

Prev Question Next Question

Question

Your team is responsible for an AWS Elastic Beanstalk application.

The business requires that you move to a continuous deployment model, releasing updates to the application multiple times per day with zero downtime.

What should you do to enable this and still be able to roll back almost immediately in an emergency to the previous version?

Answers

Explanations

Click on the arrows to vote for the correct answer

A. B. C. D.

Answer - B.

The AWS Documentation mentions the below.

Because Elastic Beanstalk performs an in-place update when you update your application versions, your application may become unavailable to users for a short period of time.

It is possible to avoid this downtime by performing a blue/green deployment, where you deploy the new version to a separate environment, and then swap CNAMEs of the two environments to redirect traffic to the new version instantly.

For more information on Elastic beanstalk swap URL please see the below link:

http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html

To enable a continuous deployment model with zero downtime and still be able to roll back almost immediately to the previous version, the best option is to use a blue/green deployment strategy. In this strategy, two identical environments are created (blue and green) with different application versions running on them.

This allows you to test and deploy changes to the green environment while the blue environment continues to serve production traffic. Once the green environment has been successfully tested, traffic can be shifted to it by changing the CNAME record in DNS.

If there are issues with the new version of the application, traffic can be quickly shifted back to the blue environment, minimizing downtime.

Option A, enabling rolling updates in the Elastic Beanstalk environment, may result in some downtime during the update process. While it is possible to set an appropriate pause time for application startup, this does not provide a zero-downtime deployment model.

Option B, creating a second Elastic Beanstalk environment running the new application version, and swapping the environment CNAMEs, is a valid blue/green deployment strategy. This allows for testing of the new version in the green environment and minimal downtime during deployment. However, it does not provide a way to easily roll back to the previous version if there are issues.

Option C, developing the application to poll for a new application version in your code repository, downloading and installing it to each running Elastic Beanstalk instance, is not a recommended approach for continuous deployment with zero downtime. This method does not allow for testing of the new version before deployment, which can result in issues and downtime.

Option D, creating a second Elastic Beanstalk environment with the new application version, and configuring the old environment to redirect clients using the HTTP 301 response code to the new environment, is not a recommended approach for continuous deployment with zero downtime. This method can result in longer downtime during deployment and can also cause issues with search engines indexing your site.

Therefore, the best option for enabling continuous deployment with zero downtime and the ability to roll back almost immediately in an emergency to the previous version is to create a second Elastic Beanstalk environment with the new application version and use a blue/green deployment strategy.