An application deployed via CloudFormation uses API Gateway REST APIs integrated with Lambda and DynamoDB. There are development, testing, and production stages, each with its own DynamoDB table. Changes promoted to production have caused unexpected problems even though they worked in dev and test. For the next release, the developer needs to route 20% of production traffic to the new API deployment and 80% to the existing production deployment, minimizing the chance that any single customer sees errors. What is the best approach?

The best approach is to configure canary deployment settings for the production API stage. API Gateway's canary deployments allow you to route a percentage of traffic to a new deployment while the majority of traffic continues to use the existing stable deployment. This minimizes the impact of potential issues, as only a small subset of users is affected. If problems arise, you can roll back quickly. Deploying 20% of changes incrementally is inefficient and still carries risk with each deployment. Changing Route 53 DNS records to point to a testing stage is not ideal for production traffic; testing stages often lack the robustness and monitoring of production. Placing an Application Load Balancer in front of the API Gateway is an unnecessary architectural overhead for this specific problem, as API Gateway itself offers canary deployment capabilities.