【AMIの役割（パフォーマンス最適化）】
目次
🔍 1. 結論
💎 一言でいうと パフォーマンス（高性能）の観点での AMI（Amazon Machine Image）の役割は、「EC2インスタンスの起動時間（ブートタイム）を極限まで短縮すること」 です。
- ソフトウェアのインストールや設定がすべて完了した 「ゴールデンAMI（Pre-baked AMI）」 を用意する。
- 突発的な負荷増（スパイク）で Auto Scaling が発動した際、一瞬でサーバーを起動してトラフィックをさばくことができる。
📈 2. SAAで出やすいポイント
- ゴールデンAMI vs ユーザーデータ (User Data):
- User Data: OSが起動した「後」にスクリプトを走らせて、ソフトウェアのダウンロードやビルドを行う。柔軟だが、起動完了までに数分〜数十分かかり、スパイク負荷に間に合わない（パフォーマンス劣化）。
- ゴールデンAMI: 全てが焼き込まれた状態（Pre-baked）から起動する。OSが立ち上がった瞬間にWebサーバーとして稼働できるため、数秒〜数十秒でスケールアウトが完了する。
- パフォーマンスと弾力性の交差点: 「早く起動できる（高性能）」ことは、すなわち「急な負荷変動や障害から素早く復旧できる（弾力性）」ことに直結します。
🗝 3. キーワードでの判断
| 問題文のキーワード | 疑うアプローチ |
|---|---|
| ⏱️ 「Auto Scalingのスケールアウトが間に合わず、エラーになる」 | セットアップ済みのAMI（ゴールデンAMI）を使用する |
| 🚀 「EC2の起動時間（ブートストラップ処理）を最小限にしたい」 | すべてを含んだ AMI (Pre-baked AMI) を作成する |
⚠️ 4. ひっかけポイント
🚫 よくある誤答パターン – 「より強力なインスタンスタイプに変更して起動を早める」 → インスタンスを大きくしても、起動時にソフトウェアのコンパイル等をしていれば結局時間はかかります。ソフトウェア導入プロセスを「AMIに焼き付ける」のが正解です。 – 「Step Functionsで起動シーケンスを管理する」 → 複雑すぎるアンチパターンです。シンプルにAMIを作ってください。
💡 5. 覚え方
🧠 暗記ショートカット – User Data = 「家具の組み立てキット（IKEA）」。買ってから家で組み立てるので時間がかかる。 – ゴールデンAMI = 「完成品の家具（ニトリ）」。届いた瞬間にすぐ座れる（起動が速い）。
📚 6. 関連サービス
| アイコン | サービス名 | 高性能化における関連 |
|---|---|---|
| 📈 | Auto Scaling | ゴールデンAMIを組み込んだ「起動テンプレート」を使って、高速にEC2を増やす |
| 🔧 | EC2 Image Builder | パッチ適用済みのゴールデンAMIを、手作業ではなく自動パイプラインで定期作成する |
🗒️ 7. Obsidian管理メモ
- 見返すタイミング: Auto Scalingのスケーリング速度チューニング学習時
- 関連ノート候補:
AWS_SAA_Golden_AMI
8. HTMLファイル名:
AWS_高性能設計_AMI.html
