【AMIの役割（耐障害性と高可用性）】
目次
🔍 1. 結論
💎 一言でいうと Amazon Machine Image (AMI) は、EC2インスタンスのOS・アプリ・設定を丸ごと保存した「サーバーの金型（テンプレート）」 です。ゴールデンAMI を用意しておくことで、Auto Scalingが新しいインスタンスを起動する際の時間（ダウンタイム）を極限まで短縮し、システムの弾力性を高めます。
- 起動時に一からソフトウェアをインストールするのではなく、すべて入った「ゴールデンAMI」から起動するのがベストプラクティス。
- リージョンをまたいだコピーが可能で、災害復旧（DR）時のベース環境となる。
📈 2. SAAで出やすいポイント
- ゴールデンAMIアプローチ: Auto Scalingの起動設定において、ベアメタルのOSから起動して User Data（起動スクリプト）で何分もかけてソフトウェアをインストールするのは非効率です。あらかじめ全てのミドルウェアとアプリを組み込んだ AMI（ゴールデンAMI）を作成しておくことで、数秒〜数十秒での即時スケールアウト（弾力的な対応） が可能になります。
- クロスリージョンコピー (Cross-Region Copy): AMIは作成されたリージョンに依存しますが、他のリージョンへ簡単にコピーできます。メインリージョンが被災した際、別リージョンでコピー済みのAMIからEC2を起動することで迅速なDR（ディザスタリカバリ）が実現します。
- EBSスナップショットとの関係: AMIの実態は、ルートボリューム（およびデータボリューム）の EBSスナップショット と、起動に必要なメタデータのセットです。
🗝 3. キーワードでの判断
| 問題文のキーワード | 疑う機能・構成 |
|---|---|
| ⏱️ 「Auto Scalingのスケールアウト（EC2起動）にかかる時間を短縮したい」 | ゴールデンAMIの作成と利用 |
| 🌍 「別リージョンに全く同じWebサーバー環境を複製（DR）したい」 | AMIのクロスリージョンコピー |
| 🔄 「障害発生時に、素早く同じ設定のサーバーを復旧したい」 | AMIからの復元 |
⚠️ 4. ひっかけポイント
🚫 よくある誤答パターン – 「EC2 User Data (ブートストラップ) だけで全てのインストールを行う」 → 環境構築を自動化できますが、起動のたびにダウンロードやビルドが走るため「起動が遅い」のが欠点です。試験で「起動時間を最短にしたい（素早くスケールしたい）」と問われたら、User Dataではなく AMI が正解です。 – 「EBSスナップショットから直接EC2を起動する」 → EC2を起動するためには「AMI」が必要です。EBSスナップショットからAMIを登録（作成）するステップが挟まります。
💡 5. 覚え方
🧠 暗記ショートカット – AMI = 「たい焼きの型」。 – 型さえ作っておけば、注文（トラフィック）が殺到しても、一瞬で同じ味のたい焼き（EC2）を大量生産できる。 – 型を海外の支店に送れば（クロスリージョンコピー）、海外でもすぐ同じたい焼きが焼ける。
📚 6. 関連サービス
| アイコン | サービス名 | AMIとの関連 |
|---|---|---|
| 💻 | Amazon EC2 | AMIから生成される実体のサーバー |
| 📈 | Auto Scaling | AMI（起動テンプレート）を使って、需要に応じてEC2を自動で増減させる |
| 🔧 | EC2 Image Builder | 最新のOSパッチを当てたAMIを「自動で定期作成」するサービス |
🗒️ 7. Obsidian管理メモ
- 見返すタイミング: Auto Scalingの最適化、ディザスタリカバリのリージョン戦略の学習時
- 関連ノート候補:
AWS_SAA_Golden_AMI_vs_UserData
8. HTMLファイル名:
AWS_弾力性設計_AMI.html
