通过 CloudFormation 部署的应用程序使用与 Lambda 和 DynamoDB 集成的 API Gateway REST API。该应用程序有开发、测试和生产阶段，每个阶段都有自己的 DynamoDB 表。推广到生产环境的更改导致了意外问题，尽管它们在开发和测试环境中运行良好。对于下一个版本，开发人员需要将 20% 的生产流量路由到新的 API 部署，将 80% 的流量路由到现有的生产部署，从而最大限度地减少任何单个客户看到错误的可能性。最佳方法是什么？

正确答案是配置 API Gateway 阶段的金丝雀部署。API Gateway 的金丝雀部署功能允许您将一小部分流量（例如 20%）路由到新的 API 部署，同时保持大部分流量（80%）指向现有部署。这使得在将新版本完全推广到所有用户之前，可以在生产环境中测试新版本，从而最大限度地降低风险。 将计划更改分批部署到生产环境效率低下且风险较高，因为每次部署都可能引入新问题。更改 Route 53 DNS 记录以指向测试阶段的 API 不合适，因为测试阶段通常不具备生产级别的可伸缩性、安全性和数据隔离。在 REST API 前放置 Application Load Balancer (ALB) 是不必要的复杂，因为 API Gateway 本身就提供了流量管理功能，并且 ALB 通常用于在 EC2 实例或容器之间分配流量，而不是直接在 API Gateway 阶段之间。