AWS認定資格 WEB問題集＆徹底解説
デベロッパー–アソシエイト
問題文と選択肢
- リージョンを指定するCloudFormationパラメータを作成し、デプロイ時に手動で入力する
- AWS::Region組み込み疑似パラメータを使用する
- AWS Lambda関数を使用したカスタムリソースを作成し、デプロイ時にリージョン情報を取得する
- すべてのAWSリージョンの情報を含むマッピングをテンプレート内に定義し、適切な値を参照する
A. リージョンを指定するCloudFormationパラメータを作成し、デプロイ時に手動で入力する
リージョン名をパラメータとして受け取る構成でも動作はするが、デプロイのたびに人が正しいリージョン名を入力する必要があり、入力ミスで実際のデプロイ先と食い違う値が渡るリスクがある。
CloudFormation はスタックを作成しているリージョンをすでに知っているため、それを人手で教え直すのは冗長。
自動化・効率性の観点で、疑似パラメータを使う方法に明確に劣る。
B. AWS::Region組み込み疑似パラメータを使用する
AWS::Region は CloudFormation があらかじめ用意している疑似パラメータで、テンプレート内に「Ref AWS::Region」（YAML なら !Ref 'AWS::Region'）と書くだけで、そのスタックが作成されているリージョン名（ap-northeast-1 など）が実行時に自動で解決される。
パラメータの宣言も追加リソースも不要で、同じテンプレートをどのリージョンにデプロイしてもそのまま動く。
同様の疑似パラメータに AWS::AccountId、AWS::StackName、AWS::Partition などがあり、本問のように「デプロイ先の環境情報を動的に参照したい」場面での定石。追加コスト・追加運用がゼロである点で最も効率的。
C. AWS Lambda関数を使用したカスタムリソースを作成し、デプロイ時にリージョン情報を取得する
Lambda 関数によるカスタムリソースを作れば技術的にはリージョンを取得できるが、組み込み機能で 1 行で済むことに対して、Lambda 関数・実行ロール・カスタムリソースの実装と保守を丸ごと抱え込むことになる。
スタック作成・削除のたびにカスタムリソースの応答待ちが発生し、デプロイの遅延や失敗要因を増やす。
「最も効率的」という要件に真っ向から反する過剰設計。
D. すべてのAWSリージョンの情報を含むマッピングをテンプレート内に定義し、適切な値を参照する
Mappings 自体は「リージョンごとに異なる AMI ID を引く」といったリージョン依存の値を切り替える用途では有効な機能。
しかし本問の要件は「デプロイ先リージョン名そのものを参照する」ことであり、そもそもMappings から値を引くキーとして AWS::Region が必要になる（FindInMap の第 2 引数に AWS::Region を渡す形）。
全リージョンの一覧を手書きで持つと新リージョン追加のたびにテンプレートの更新が必要になり、管理が煩雑。単なるリージョン参照には不適。
リージョン・アカウントID・スタック名は「疑似パラメータ」でタダで取れる。Ref AWS::Region、自作は不要。
正解への思考ルート
問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。| 要件 | 判断ポイント |
|---|---|
| デプロイ先のリージョンをテンプレート内で「動的に」参照したい | CloudFormation の疑似パラメータ AWS::Regionが、スタック実行時のリージョンを自動で解決する →選択肢（B）が正解 |
| 同じテンプレートを複数リージョンへデプロイする | 人手入力のパラメータは実際のデプロイ先と食い違うリスクがあり、自動化にも反する →選択肢（A）を消す |
| 最も「効率的」な方法（追加リソース・追加運用を増やさない） | Lambda カスタムリソースは組み込み機能で済む処理のために実装・保守を追加する過剰設計 →選択肢（C）を消す |
| メンテナンス性（リージョン追加への追随） | 全リージョンを列挙する Mappings はリージョンが増えるたびに更新が必要。しかも参照キーに結局 AWS::Region が要る →選択肢（D）を消す |
ひっかけポイント
- 「パラメータで渡す」（選択肢 A）は一見正攻法に見えるが、CloudFormation が自分で知っている情報を人に入力させている点で非効率。設問の「動的に参照」は"手入力しない"の意
- Mappings はリージョンごとの AMI ID の出し分けで頻出するため正解に見えやすい。しかしMappings のキーとして AWS::Region を使うのが実際の書き方であり、リージョン名の取得手段そのものではない
- カスタムリソース（Lambda）は「何でもできる」ため魅力的に映るが、組み込みで解決できる要件に持ち出した時点で誤答という CloudFormation 問題の定番パターン
- AWS::Region はParameters セクションに宣言しない（宣言するとエラー）。「疑似（Pseudo）パラメータ」は最初から使える点を押さえる
出題バリエーション
同じ知識が本番では条件を変えて出題されます。| 問題文がこう変わったら | 正解はこう変わる |
|---|---|
| 「テンプレート内でAWS アカウント ID を参照したい」 | 疑似パラメータ AWS::AccountId が正解に（考え方は同じ）。 |
| 「中国リージョンや GovCloud でも動く ARN を組み立てたい」 | AWS::Partition（aws / aws-cn / aws-us-gov）を使うのが正解軸に。 |
| 「リージョンごとに異なる AMI ID を使い分けたい」 | Mappings + !FindInMap [RegionMap, !Ref 'AWS::Region', AMI] が正解に浮上。 |
| 「複数リージョン・複数アカウントへ同じスタックを一括展開したい」 | CloudFormation StackSets が正解軸に。 |
| 「テンプレートに組み込み関数では取得できない情報（外部 API の値など）を渡したい」 | ここで初めてLambda バックドのカスタムリソースが正解になる。 |
- リージョンを指定するCloudFormationパラメータを作成し、デプロイ時に手動で入力する
- AWS::Region組み込み疑似パラメータを使用する
- AWS Lambda関数を使用したカスタムリソースを作成し、デプロイ時にリージョン情報を取得する
- すべてのAWSリージョンの情報を含むマッピングをテンプレート内に定義し、適切な値を参照する