透過 CloudFormation 部署的應用程式使用與 Lambda 和 DynamoDB 整合的 API Gateway REST API。該應用程式有開發、測試和生產階段，每個階段都有自己的 DynamoDB 資料表。推廣到生產環境的變更導致了意外問題，即使這些變更在開發和測試環境中運作正常。對於下一個版本，開發人員需要將 20% 的生產流量路由到新的 API 部署，並將 80% 的流量路由到現有的生產部署，同時將任何單一客戶看到錯誤的可能性降到最低。最佳方法是什麼？

正確答案是為生產 API 階段設定 canary 部署設定，將 canary 流量百分比設定為 20%，套用計畫的更新，然後部署變更。API Gateway 的 canary 部署功能允許您將一小部分流量路由到新的部署版本，同時將大部分流量路由到現有的穩定版本。這使得在不影響所有生產用戶的情況下，可以對新版本進行真實世界的測試和監控。如果出現問題，可以輕鬆回滾，將單一客戶看到錯誤的可能性降到最低。 其他選項不夠理想： 將 20% 的計畫變更部署到生產環境並重複五次效率低下且風險較高，每次部署都可能引入問題。 使用 Route 53 加權路由指向測試階段 API 會將生產流量導向非生產環境，這可能導致資料不一致或其他意外行為。 在 REST API 前方放置 Application Load Balancer 並將生產和測試階段註冊為加權目標，雖然技術上可行，但引入了不必要的複雜性，因為 API Gateway 本身就提供了 canary 部署功能，更適合這種情境。