Deploying a High-Risk Application Version with Controlled User Rollout

Deploying a High-Risk Application Version

Prev Question Next Question

Question

You need to deploy a new application version to production.

Because the deployment is high-risk, you need to roll the new version out to users over a number of hours to make sure everything is working correctly.

You need to control the proportion of users seeing the new version of the application down to the percentage point.

You use ELB and EC2 with Auto Scaling Groups and custom AMIs with your code pre-installed assigned to Launch Configurations.

There are no database-level changes during your deployment.

You also need to switch back to the original version of the code quickly if something goes wrong.

What is the best way to meet these requirements?

Answers

A. Create a second ELB, Auto Scaling Launch Configuration, and Auto Scaling Group using the Launch Configuration. Create AMIs with all code pre-installed. Assign the new AMI to the second Auto Scaling Launch Configuration. Use Route53 Weighted Round Robin Records to adjust the proportion of traffic hitting the two ELBs.

B. Use the Blue-Green deployment method to enable the fastest possible rollback if needed. Create a full second stack of instances and cut the DNS over to the new stack of instances, and change the DNS back if a rollback is needed.

C. Create AMIs with all code pre-installed. Assign the new AMI to the Auto Scaling Launch Configuration to replace the old one. Gradually terminate instances running the old code (launched with the old Launch Configuration) and allow the new AMIs to boot to adjust the traffic balance to the new code. On rollback, reverse the process by doing the same thing, but changing the AMI on the Launch Config back to the original code.

D. Migrate to use AWS Elastic Beanstalk. Use the established and well-tested Rolling Deployment setting AWS provides on the new Application Environment, publishing a zip bundle of the new code and adjusting the waiting period to spread the deployment over time. Re-deploy the old code bundle to roll back, if needed.

Show Answer

Explanations

Click on the arrows to vote for the correct answer

A. B. C. D.

Answer - A.

Weighted Routing.

Weighted routing lets you associate multiple resources with a single domain name (example.com) or subdomain name (acme.example.com) and choose how much traffic is routed to each resource.

This can be useful for a variety of purposes, including load balancing and testing new versions of software.

To configure weighted routing, you create records with the same name and type for each of your resources.

You assign each record a relative weight that corresponds with how much traffic you want to send to each resource.

Amazon Route 53 sends traffic to a resource based on the weight that you assign to the record as a proportion of the total weight for all records in the group.

For more information, refer to page 265 of the below link.

https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/route53-dg.pdf

This is an example of a Blue-Green Deployment.

You can shift traffic all at once, or you can do a weighted distribution.

With Amazon Route 53, you can define a percentage of traffic to go to the green environment and gradually update the weights until the green environment carries the full production traffic.

A weighted distribution provides the ability to perform canary analysis where a small percentage of production traffic is introduced to a new environment.

You can test the new code and monitor errors, limiting the blast radius if any issues are encountered.

It also allows the green environment to scale out to support the full production load if you're using Elastic Load Balancing.

For more information on Blue-Green Deployments, please visit the below URL:

https://d0.awsstatic.com/whitepapers/AWS_Blue_Green_Deployments.pdf

The best way to meet these requirements is option C:

Create AMIs with all code pre-installed. Assign the new AMI to the Auto Scaling Launch Configuration to replace the old one. Gradually terminate instances running the old code (launched with the old Launch Configuration) and allow the new AMIs to boot to adjust the traffic balance to the new code. On rollback, reverse the process by doing the same thing, but changing the AMI on the Launch Config back to the original code.

Option C uses an incremental approach to deploy the new version of the application while ensuring that the risk of failure is minimized. This method allows for a gradual rollout of the new version to a small percentage of users at a time, providing an opportunity to monitor the application for any issues that may arise.

The steps involved in this method are:

Create a new AMI with the updated code pre-installed.
Create a new Launch Configuration and assign the new AMI to it.
Update the Auto Scaling Group to use the new Launch Configuration.
Gradually terminate instances running the old code (launched with the old Launch Configuration) and allow the new AMIs to boot to adjust the traffic balance to the new code.
Monitor the application to ensure everything is working as expected.
Repeat the process until all instances are running the new code.

If something goes wrong during the deployment, the process can be reversed quickly by changing the AMI on the Launch Configuration back to the original one, and terminating the new instances.

Option A suggests using a second ELB, Auto Scaling Launch Configuration, and Auto Scaling Group. However, this method is complex and requires additional resources. It also introduces additional complexity with Route53 Weighted Round Robin Records, which can lead to issues with DNS caching.

Option B suggests using the Blue-Green deployment method. While this method provides the fastest possible rollback if needed, it requires a full second stack of instances, which is expensive and can be complex to manage.

Option D suggests migrating to AWS Elastic Beanstalk. While this service provides an established and well-tested Rolling Deployment setting, it may not be the best option for all applications, especially if the application has a complex infrastructure. Additionally, migrating to Elastic Beanstalk may require significant time and resources.

Prev Question Next Question