CloudFormation を介してデプロイされたアプリケーションは、Lambda および DynamoDB と統合された API Gateway REST API を使用します。開発、テスト、および本番ステージがあり、それぞれに独自の DynamoDB テーブルがあります。本番環境に昇格された変更は、開発環境とテスト環境では機能したにもかかわらず、予期せぬ問題を引き起こしました。次のリリースでは、開発者は本番トラフィックの 20% を新しい API デプロイに、80% を既存の本番デプロイにルーティングし、単一の顧客がエラーを目にする可能性を最小限に抑える必要があります。最適なアプローチは何ですか？

API Gateway のカナリアデプロイは、新しい API バージョンへのトラフィックを徐々にシフトさせることで、リスクを最小限に抑えながら変更を導入する最適な方法です。本番ステージにカナリアデプロイを設定し、トラフィックの20%を新しいデプロイにルーティングすることで、問題が発生した場合の影響を限定できます。 他の選択肢は適切ではありません。 変更を20%ずつ5回デプロイする方法は手動で非効率的です。 Route 53の重み付けルーティングはAPI Gatewayのステージレベルのルーティングには直接適用できません。 Application Load BalancerをAPI Gatewayの前に配置することは可能ですが、API Gateway自体にカナリアデプロイ機能があるため、より複雑で不要な構成になります。