Which approach should the developer take to meet these requirements?
Update 20% of the planned changes to the production stage. Deploy the new production stage. Monitor the results. Repeat this process five times to test all planned changes.
Update the Amazon Route 53 DNS record entry for the production stage API to use a weighted routing policy. Set the weight to a value of 80. Add a second record for the production domain name. Change the second routing policy to a weighted routing policy. Set the weight of the second policy to a value of 20. Change the alias of the second policy to use the testing stage API.
Deploy an Application Load Balancer (ALB) in front of the REST API. Change the production API Amazon Route 53 record to point traffic to the ALB. Register the production and testing stages as targets of the ALB with weights of 80% and 20%, respectively.
Configure canary settings for the production stage API. Change the percentage of traffic directed to canary deployment to 20%. Make the planned updates to the production stage. Deploy the changes.
Explanations:
This approach involves manually deploying changes in stages, which is inefficient and error-prone. It does not provide a way to control traffic routing between the old and new production stages.
Route 53 weighted routing can only be applied to DNS queries, not directly to API Gateway stages. This option does not offer a reliable solution for traffic management between stages.
An Application Load Balancer (ALB) cannot be used with API Gateway directly. API Gateway does not support registering ALB as a target. This option is not valid for routing API traffic.
Using a canary deployment in API Gateway allows precise traffic control. With this setup, 20% of traffic is routed to the new production stage and 80% to the existing one, minimizing errors.