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 gradually updating changes to the production stage in a sequential manner, which can lead to longer deployment times and increases the risk of errors for customers as changes are rolled out piece by piece rather than allowing for controlled testing of the complete new functionality. This method does not effectively route traffic based on percentages as required.
Using Amazon Route 53 with a weighted routing policy can direct traffic between two different APIs, but the solution would not work as intended in this context. The developer wants to route traffic between two stages of the same API, not between two different APIs. Furthermore, this option does not facilitate a seamless deployment process with the planned updates, and it does not address monitoring or error minimization effectively.
While deploying an Application Load Balancer (ALB) to route traffic to different stages could theoretically allow for weighted traffic distribution, it adds unnecessary complexity to the architecture for a straightforward API deployment. The use of an ALB in this scenario is not typical for direct integration with API Gateway, which can handle canary deployments and traffic distribution more simply.
Configuring canary settings for the production stage API is the best approach as it allows the developer to direct a specific percentage of traffic (20% in this case) to a new version of the API while maintaining the remaining 80% on the current version. This method allows for real-time monitoring of the new deployment, minimizes the risk of errors for customers, and enables quick rollback if issues are detected.
As far as I’m aware, the answer is:
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