開発者がAmazon API GatewayとAWS Lambdaを使用して、開発環境（dev）および本番環境（prod）向けのサーバーレスAPIを管理しています。APIの定義やLambda関数の更新後、リクエストを実際

Question

開発者がAmazon API GatewayとAWS Lambdaを使用して、開発環境（dev）および本番環境（prod）向けのサーバーレスAPIを管理しています。APIの定義やLambda関数の更新後、リクエストを実際にクライアントへ公開するために不可欠な操作と、単一のAPI Gatewayで環境間のエンドポイントや呼び出し先Lambda関数の差分を柔軟に管理するためのベストプラクティスはどれですか。

Accepted Answer

正解: APIを変更した後に特定のステージへAPIを「デプロイ」し、ステージ変数を使用してエンドポイントや統合先のLambda関数エイリアスを制御する。。Amazon API Gatewayでは、設定変更を行っても指定した「ステージ」に対して「デプロイ（Deploy）」を実行しない限り、クライアントがアクセスする呼び出し可能エンドポイントには反映されません。また、ステージ変数（Stage Variables）を利用することで、devやprodといった環境ごとの設定値や呼び出し先Lambda関数のエイリアス（${stageVariables.lambdaAlias}など）を同一API内で柔軟に分岐・切り替えることが可能になります。

Answer

APIを変更するたびにリソースを再再帰的に保存し、各環境に対応する個別のアカウントを作成してそれぞれにAPIを自動的に共有する。 — 設定を保存しただけではエンドポイントには反映されず「デプロイ」操作が必要です。また、環境ごとにAWSアカウントを新規作成・共有するのは運用のオーバーヘッドが非常に大きく非効率です。

Answer

APIの変更内容をリソースレベルで保存してLambda関数定義にバージョンタグを直接付与し、ルート設定から直接呼び出す。 — Lambda関数バージョンやタグの付与だけではAPI Gateway側の更新は反映されません。必ずステージへのデプロイが必要であり、ルート設定からの直接参照のみでは環境差分を柔軟に管理できません。

Answer

APIの変更を公開するためにSwagger定義ファイルを再インポートし、各環境専用のカスタムドメインを直接Lambda関数にバインドする。 — Swaggerファイルの再インポートはAPI定義の更新には使えますが、公開にはデプロイ操作が必要です。また、カスタムドメインをLambdaに直接バインドする構成は環境差分の管理として適切ではありません。

解説

解説