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 be able 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 have been told you cannot spend too much money, so you
must not increase the number of EC2 instances much at all during the deployment, but you also need to be able to switch
back to the original version of code quickly if something goes wrong. What is the best way to meet these requirements?

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 wait period to spread the deployment over time.
Re-deploy the old code bundle to rollback if needed.

Explanation:
Only Weighted Round Robin DNS Records and reverse proxies allow such fine-grained tuning of traffic splits. The BlueGreen option does not meet the requirement that we mitigate costs and keep overall EC2 fleet size consistent, so we
must select the 2 ELB and ASG option with WRR DNS tuning. This method is called A/B deployment and/or Canary
deployment.
https://d0.awsstatic.com/whitepapers/overview-of-deployment-options-on-aws.pdf