AWS認定資格 WEB問題集＆徹底解説
デベロッパー–アソシエイト
合格に向けて、もっと深く学習する
豊富な問題と詳細なAWSサービス解説を、24時間無料でお試しいただけます
問題文と選択肢
デベロッパーは、Amazon API Gateway を使用するウェブアプリケーションを構築しています。デベロッパーは、開発 (dev) ワークロードと本番 (prod) ワークロード用に異なる環境を維持したいと考えています。この API は、dev 用 1 つと prod 用 1 つの 2 つのエイリアスを持つ AWS Lambda 関数によってサポートされます。
デベロッパーは、管理オーバーヘッドを最小限に抑えながら、これらの環境をどのように維持できますか。
デベロッパーは、管理オーバーヘッドを最小限に抑えながら、これらの環境をどのように維持できますか。
- 環境ごとに REST API を作成する。API を Lambda 関数の対応する dev および prod エイリアスと統合する。API をそれぞれのステージにデプロイする。ステージ URL を使用して API にアクセスする。
- REST API を 1 つ作成する。エイリアスを直接指定する代わりにステージ変数を使用して、API を Lambda 関数と統合する。API を dev と prod の 2 つの異なるステージにデプロイする。値として異なるエイリアスを持つステージ変数を各ステージに作成する。異なるステージ URL を使用して API にアクセスする。
- REST API を 1 つ作成する。API を Lambda 関数の dev エイリアスと統合する。API を dev ステージにデプロイする。Canary が Lambda の prod エイリアスと統合される Canary リリースデプロイを設定する。
- REST API を 1 つ作成する。API を Lambda 関数の prod エイリアスと統合する。API を prod ステージにデプロイする。Canary が Lambda の dev エイリアスと統合される Canary リリースデプロイを設定する。
解説
頻出度★★★★★
この問題は、「1 つの API で dev/prod を出し分ける × 管理オーバーヘッド最小」の要件で、ステージ変数に Lambda エイリアスを持たせてステージごとに切り替えるという API Gateway の定番パターンを選べるかがポイント
A. 環境ごとに REST API を作成する。API を Lambda 関数の対応する dev および prod エイリアスと統合する。API をそれぞれのステージにデプロイする。ステージ URL を使用して API にアクセスする。
環境ごとに REST API を作れば動作はするが、API を 2 つ管理することになる。
リソース・メソッド・認可設定・使用量プラン等の変更をそのつど両方の API に反映する必要があり、設定のドリフト（不一致）も起きやすい。
要件の「管理オーバーヘッドを最小限に抑える」に反するため、より効率的な選択肢 B がある以上は選べない。
正解
B. REST API を 1 つ作成する。エイリアスを直接指定する代わりにステージ変数を使用して、API を Lambda 関数と統合する。API を dev と prod の 2 つの異なるステージにデプロイする。値として異なるエイリアスを持つステージ変数を各ステージに作成する。異なるステージ URL を使用して API にアクセスする。
Lambda 統合のバックエンド指定に ${stageVariables.alias} のようなステージ変数を埋め込み、dev ステージには alias=dev、prod ステージには alias=prod を設定する。
これにより REST API は 1 つのまま、デプロイ先のステージだけで呼び出す Lambda エイリアスが切り替わる。
API 定義の管理は一箇所に集約され、環境ごとに異なるステージ URL でアクセスできるため、管理オーバーヘッド最小で dev/prod を分離できる唯一の正解。
C. REST API を 1 つ作成する。API を Lambda 関数の dev エイリアスと統合する。API を dev ステージにデプロイする。Canary が Lambda の prod エイリアスと統合される Canary リリースデプロイを設定する。
Canary リリースデプロイは、1 つのステージ内で本番トラフィックの一部（数％）を新しいバージョンに振り分ける段階的リリースの仕組みであり、環境を分離する機能ではない。
この構成では prod のリクエストが確率的にしか prod エイリアスに届かず、dev と prod のトラフィックが混ざる。
開発環境と本番環境を独立して維持するという要件を満たさない。
D. REST API を 1 つ作成する。API を Lambda 関数の prod エイリアスと統合する。API を prod ステージにデプロイする。Canary が Lambda の dev エイリアスと統合される Canary リリースデプロイを設定する。
選択肢 C と統合先を入れ替えただけで、本質的な誤りは同じ。Canary の割合に応じて一部のリクエストだけが dev エイリアスに流れる構成であり、環境の分離にはならない。
しかも本番ステージに開発中のコードを混ぜることになり、本番に未検証のコードが流れるという点でむしろ危険。
Canary は「新バージョンを本番へ段階的に出す」ための機能だと押さえておく。
構成図
1 つの REST API ├─ dev ステージ（stageVariables.alias = dev） ──▶ Lambda 関数：dev エイリアス └─ prod ステージ（stageVariables.alias = prod）──▶ Lambda 関数：prod エイリアス
これだけ覚える（記憶フック）
API Gateway の環境分離＝ステージ＋ステージ変数。Lambda 統合の ARN に ${stageVariables.alias} を埋め込む。
API Gateway の環境分離＝ステージ＋ステージ変数。Lambda 統合の ARN に ${stageVariables.alias} を埋め込む。
正解への思考ルート
問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。| 要件 | 判断ポイント |
|---|---|
| dev と prod で異なる環境を維持する | API Gateway ではステージが環境の単位。ステージごとに固有の URL が払い出される →選択肢（A・B）は候補 |
| Lambda 関数には dev / prod の 2 つのエイリアスがある | ステージ変数を Lambda 統合の ARN に埋め込むことで、ステージごとに呼び出すエイリアスを切り替えられる →選択肢（B）が正解 |
| 管理オーバーヘッドを最小限に抑える | REST API を環境ごとに作るとAPI 定義を二重管理することになり、変更のたびに両方へ反映が必要 →選択肢（A）を消す |
| 環境を確実に分離する（トラフィックを混ぜない） | Canary リリースは同一ステージ内のトラフィック分割であり、環境分離の手段ではない →選択肢（C・D）を消す |
ひっかけポイント
- 選択肢 A は「動くが管理が重い」典型的な準正解。REST API の数を増やすと定義の二重管理が発生する点で、管理オーバーヘッド最小の要件に負ける
- Canary リリース（選択肢 C・D）は環境分離の機能ではなく段階的デプロイの機能。「Canary＝新しいものを試す」という語感で環境の切り替えに使えそうに見えるのが罠
- ステージ変数は Lambda のエイリアスだけでなく、統合先の HTTP エンドポイントや Lambda 関数名の切り替えにも使える。「環境ごとに値を変えたい」ならまずステージ変数
- ステージ変数で Lambda を切り替える場合、各エイリアスに対して API Gateway からの呼び出し許可（リソースベースポリシー）が必要。設定漏れで 500 エラーになる点も実務・出題の頻出ポイント
出題バリエーション
同じ知識が本番では条件を変えて出題されます。| 問題文がこう変わったら | 正解はこう変わる |
|---|---|
| 「dev/prod でバックエンドの HTTP エンドポイント URL を切り替えたい」 | 同じくステージ変数を統合 URI に埋め込むのが正解。 |
| 「本番の新バージョンにトラフィックの 10% だけ流して様子を見たい」 | Canary リリースデプロイが正解に変わる（本問とは逆に、Canary が主役）。 |
| 「Lambda 側で重み付きの段階的デプロイを行いたい」 | Lambda エイリアスの加重ルーティングや CodeDeploy の Linear/Canary デプロイが正解軸に。 |
| 「ステージごとにスロットリングやキャッシュ設定を変えたい」 | ステージ設定（メソッドレベルのスロットリング・ステージキャッシュ）が論点になる。 |
＋ 質問 / コメント
解答・解説に疑問がある場合や、よりよい解説がある場合など、お気軽にコメントください。ただし、短文コメントは表示されません。また、中傷などコメントの内容によっては、会員機能を停止させて頂きます。教え学び合える場になれば嬉しいです。（コメント投稿にはログインが必要です）
正答率 71%
No.5 解説
デベロッパーは、Amazon API Gateway を使用するウェブアプリケーションを構築しています。デベロッパーは、開発 (dev) ワークロードと本番 (prod) ワークロード用に異なる環境を維持したいと考えています。この API は、dev 用 1 つと prod 用 1 つの 2 つのエイリアスを持つ AWS Lambda 関数によってサポートされます。
デベロッパーは、管理オーバーヘッドを最小限に抑えながら、これらの環境をどのように維持できますか。
デベロッパーは、管理オーバーヘッドを最小限に抑えながら、これらの環境をどのように維持できますか。
- 環境ごとに REST API を作成する。API を Lambda 関数の対応する dev および prod エイリアスと統合する。API をそれぞれのステージにデプロイする。ステージ URL を使用して API にアクセスする。
- REST API を 1 つ作成する。エイリアスを直接指定する代わりにステージ変数を使用して、API を Lambda 関数と統合する。API を dev と prod の 2 つの異なるステージにデプロイする。値として異なるエイリアスを持つステージ変数を各ステージに作成する。異なるステージ URL を使用して API にアクセスする。
- REST API を 1 つ作成する。API を Lambda 関数の dev エイリアスと統合する。API を dev ステージにデプロイする。Canary が Lambda の prod エイリアスと統合される Canary リリースデプロイを設定する。
- REST API を 1 つ作成する。API を Lambda 関数の prod エイリアスと統合する。API を prod ステージにデプロイする。Canary が Lambda の dev エイリアスと統合される Canary リリースデプロイを設定する。