変更要約: SOA-C02 第3章を Associate 級に深掘り（比較表・シナリオ・FAQ・ひっかけ＋深掘り段落、図を日本語化）
3.3一貫したインスタンス構築（AMI と起動テンプレート）
ゴールデン AMI による事前構築、起動テンプレート（AMI＋インスタンスタイプ＋ユーザーデータ）、ユーザーデータによる起動時設定といった、一貫した素早いプロビジョニングを理解します。
同じ構成のインスタンスを速く・確実に増やすには、構成をイメージとテンプレートに固めるのが定石です。AMI と 起動テンプレート を使います。
3.3.1AMI と起動テンプレート
- ゴールデン AMI：OS とソフトを事前構築したイメージ。起動を速め、構成を統一する。
- 起動テンプレート：AMI・インスタンスタイプ・ユーザーデータなどをまとめた起動設定。ASG から参照する。
- ユーザーデータ：起動時にスクリプトを実行して初期設定（ブートストラップ）を行う。
「起動を速く・構成を統一＝ゴールデン AMI」「ASG の起動設定＝起動テンプレート（起動設定は非推奨）」「起動時スクリプト＝ユーザーデータ」 は SOA で頻出です。AMI に焼くか、ユーザーデータで都度設定するかの判断も問われます。
一貫した素早いスケールには「何を AMI に焼き、何を起動時に注入するか」の切り分けが要です。ゴールデン AMI は OS とミドルウェア・依存を事前構築したイメージで、起動が速く構成のばらつきを無くします（パッチ適用版を定期的に作り直して更新）。AMI ビルドの自動化には EC2 Image Builder が便利です。起動テンプレート は AMI・インスタンスタイプ・キーペア・セキュリティグループ・ユーザーデータ などをまとめ、バージョン管理できる推奨の起動設定です（旧 起動設定（Launch Configuration） はレガシーで非推奨）。ASG は起動テンプレートを参照し、複数インスタンスタイプや スポット/オンデマンド混在 も指定できます。ユーザーデータ は初回起動時にスクリプトを実行する ブートストラップ で、環境ごとに変わる設定（接続先・フラグ）は Parameter Store から取得すると AMI を使い回せます。AMI はリージョン単位なので、他リージョン展開には AMI コピーが必要。共有は Launch Permission やプライベート共有で行い、不要な世代は 廃止（deprecate）/登録解除 してコストと混乱を避けます。
| 要素 | 役割 |
|---|---|
| ゴールデン AMI | OS＋依存を事前構築・高速起動 |
| 起動テンプレート | 起動設定をバージョン管理（推奨） |
| 起動設定（レガシー） | 非推奨・テンプレートへ移行 |
| ユーザーデータ | 起動時のブートストラップ |
シナリオ：スケールアウトが遅く、構成もばらつく。 ミドルや依存を ゴールデン AMI（EC2 Image Builder で自動ビルド）に焼き込み、起動時間を短縮。ASG は 起動テンプレート（旧・起動設定から移行）を参照し、環境差は ユーザーデータ＋Parameter Store で注入。他リージョンには AMI コピーで展開します。
Q. 起動を速く・構成統一？ ゴールデン AMI。Q. ASG の起動設定は？ 起動テンプレート（起動設定はレガシー）。Q. 起動時スクリプト？ ユーザーデータ。Q. 環境ごとの設定は？ Parameter Store から注入。Q. 他リージョンへ？ AMI コピー。
混同に注意：
①新規は起動テンプレートを使う（起動設定はレガシーで新機能非対応）。
②AMI はリージョン単位——他リージョンにはコピーが要る。
③すべてをユーザーデータで設定すると起動が遅くなる——安定依存は AMI に焼く。
④古い AMI/スナップショットの放置はコスト増、世代管理（deprecate/登録解除）を。
変化の少ない依存は AMI に焼き込み、環境ごとに変わる設定はユーザーデータやパラメータストアで注入すると、速度と柔軟性を両立できます。
3.3.2この節のまとめ
- ゴールデン AMI＋起動テンプレートで一貫・高速なプロビジョニング
- 起動時設定はユーザーデータ
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. インスタンスの起動を速め、構成を統一するために OS とソフトを事前構築したものは何ですか？
Q2. Auto Scaling グループがインスタンスを起動する際に参照する、推奨の起動設定はどれですか？
Q3. EC2 の起動時にスクリプトを実行して初期設定を行いたい。何を使いますか？