Table of Contents
Question
A company is running an application in the AWS Cloud. The core business logic is running on a set of Amazon EC2 instances in an Auto Scaling group. An Application Load Balancer (ALB) distributes traffic to the EC2 instances. Amazon Route 53 record api.example.com is pointing to the ALB.
The company’s development team makes major updates to the business logic. The company has a rule that when changes are deployed, only 10% of customers can receive the new logic during a testing window. A customer must use the same version of the business logic during the testing window. How should the company deploy the updates to meet these requirements?
A. Create a second ALB, and deploy the new logic to a set of EC2 instances in a new Auto Scaling group. Configure the ALB to distribute traffic to the EC2 instances. Update the Route 53 record to use weighted routing, and point the record to both of the ALBs.
B. Create a second target group that is referenced by the ALDeploy the new logic to EC2 instances in this new target group. Update the ALB listener rule to use weighted target groups. Configure ALB target group stickiness.
C. Create a new launch configuration for the Auto Scaling group. Specify the launch configuration to use the AutoScalingRollingUpdate policy, and set the MaxBatchSize option to 10. Replace the launch configuration on the Auto Scaling group. Deploy the changes.
D. Create a second Auto Scaling group that is referenced by the ALB. Deploy the new logic on a set of EC2 instances in this new Auto Scaling group. Change the ALB routing algorithm to least outstanding requests (LOR). Configure ALB session stickiness.
Answer
B. Create a second target group that is referenced by the ALDeploy the new logic to EC2 instances in this new target group. Update the ALB listener rule to use weighted target groups. Configure ALB target group stickiness.
Explanation
The question you asked is about how to deploy major updates to the business logic of an application that runs on a set of EC2 instances in an Auto Scaling group behind an ALB. The company has a rule that when changes are deployed, only 10% of customers can receive the new logic during a testing window. A customer must use the same version of the business logic during the testing window. The solution that will meet these requirements is B. Create a second target group that is referenced by the ALDeploy the new logic to EC2 instances in this new target group. Update the ALB listener rule to use weighted target groups. Configure ALB target group stickiness.
A target group is a logical grouping of targets such as EC2 instances that can be registered with a load balancer. You can create one or more target groups for your load balancer depending on your application needs. You can also specify health checks for each target group to monitor the health and availability of your targets.
A weighted target group is a feature of ALB that allows you to associate multiple target groups with a single listener rule and assign weights to each target group. The weights determine how much traffic is routed to each target group. You can use weighted target groups to perform blue/green deployments or canary testing for your application by routing different proportions of traffic to different versions of your application code.
ALB target group stickiness is a feature of ALB that enables the load balancer to bind a user’s session to a specific target in a target group. This ensures that all requests from the user during the session are sent to the same target. You can use ALB target group stickiness to ensure that a customer uses the same version of the business logic during the testing window.
Here is a step-by-step explanation of the solution:
- Create a second target group that is referenced by the ALB. This new target group will have the updated business logic deployed on a set of EC2 instances.
- Deploy the new logic to the EC2 instances in the new target group. This ensures that the updated business logic is available for a portion of the customers.
- Update the ALB listener rule to use weighted target groups. This allows you to configure the ALB to distribute the traffic between the two target groups (old and updated logic) based on the specified weights. For example, you can set the weight of the new target group to 10% and the weight of the old target group to 90%. This ensures that only 10% of the customers receive the updated logic during the testing window.
- Configure ALB target group stickiness. This ensures that a customer continues to use the same version of the business logic until the end of the testing window. Stickiness is achieved by using cookies to track the user’s session and directing them to the same target group throughout their session.
By following these steps, the company can deploy the updates as per their requirements and ensure that only 10% of customers receive the new logic during the testing window while keeping the customer’s experience consistent.
The other options are not correct because:
A. Create a second ALB, and deploy the new logic to a set of EC2 instances in a new Auto Scaling group. Configure the ALB to distribute traffic to the EC2 instances. Update the Route 53 record to use weighted routing, and point the record to both of the ALBs. This option is not correct because it does not leverage the benefits of using weighted target groups for performing blue/green deployments or canary testing for your application. Using a second ALB would increase the operational overhead and cost of managing and monitoring two load balancers instead of one. Using Route 53 weighted routing would also not guarantee that a customer uses the same version of the business logic during the testing window as it depends on DNS caching and propagation.
C. Create a new launch configuration for the Auto Scaling group. Specify the launch configuration to use the AutoScalingRollingUpdate policy, and set the MaxBatchSize option to 10. Replace the launch configuration on the Auto Scaling group. Deploy the changes. This option is not correct because it does not meet the requirement of allowing only 10% of customers to receive the new logic during a testing window. Using a new launch configuration with an AutoScalingRollingUpdate policy would replace all instances in your Auto Scaling group with new instances that have the updated application code. Setting the MaxBatchSize option to 10 would only control how many instances are replaced at a time, not how much traffic is routed to them.
D. Create a second Auto Scaling group that is referenced by the ALB. Deploy the new logic on a set of EC2 instances in this new Auto Scaling group. Change the ALB routing algorithm to least outstanding requests (LOR). Configure ALB session stickiness. This option is not correct because it does not leverage the benefits of using weighted target groups for performing blue/green deployments or canary testing for your application. Using a second Auto Scaling group would increase the operational overhead and cost of managing and scaling two groups instead of one. Changing the ALB routing algorithm to LOR would not guarantee that only 10% of customers receive the new logic during a testing window as it depends on factors such as request processing time and network latency.
Reference
- Step 2: Deploy the application to the Auto Scaling group – AWS CodeDeploy (amazon.com)
- Auto Scaling groups – Amazon EC2 Auto Scaling
- update-auto-scaling-group — AWS CLI 1.27.141 Command Reference (amazon.com)
- Attach a load balancer to your Auto Scaling group – Amazon EC2 Auto Scaling
Amazon AWS Certified Solutions Architect – Professional SAP-C02 certification exam practice question and answer (Q&A) dump with detail explanation and reference available free, helpful to pass the Amazon AWS Certified Solutions Architect – Professional SAP-C02 exam and earn Amazon AWS Certified Solutions Architect – Professional SAP-C02 certification.