【EC2の役割（耐障害性と高可用性）】
目次
🔍 1. 結論
💎 一言でいうと EC2単体では弾力性（Resiliency）はありません。EC2を 「Auto Scaling Group」に入れ、複数のAZ（Multi-AZ）にまたがって配置する ことで、初めて「障害に強く、負荷変動に耐えられる」弾力性のあるコンピューティング層が完成します。
- 1つのインスタンスがダウンしても、Auto Scalingが自動で新しいEC2を起動（自己修復機能）。
- トラフィックが増えれば自動で台数が増える（スケールアウト）。
- セッション状態を持たない「ステートレス」なアプリ設計が必須。
📈 2. SAAで出やすいポイント
- ELBヘルスチェックとの連動: EC2単体のステータスチェックだけでなく、ELBからのヘルスチェック（アプリが応答しているか）と連動させることで、ハングアップしたEC2を即座に破棄して新しいものと交換できる。
- マルチAZ展開: Auto Scaling Groupの設定で複数のサブネット（異なるAZ）を指定しておくと、EC2インスタンスを各AZに均等になるように自動配置してくれる。1つのAZが停電しても別のAZのEC2がカバーする。
- ステートレス設計: EC2インスタンスはいつでも「殺されて、新しく作られる」運命にあるため、EC2の中のローカルディスクにユーザーのログイン状態（セッション）などを保存してはいけない。DynamoDBやElastiCacheに外出しする。
🗝 3. キーワードでの判断
| 問題文のキーワード | 疑うサービス・構成 |
|---|---|
| 🔄 「障害が発生したEC2インスタンスを自動で復旧させたい」 | Auto Scaling (ヘルスチェックによる置換) |
| 🛡️ 「1つのデータセンターが落ちてもWebアプリを動かし続けたい」 | EC2をMulti-AZのAuto Scaling Groupに配置 |
| 🚫 「スケールイン（台数削減）時にデータが消えてしまう」 | EC2に状態を保存している(ステートフル)。セッションを外出しする |
⚠️ 4. ひっかけポイント
🚫 よくある誤答パターン – 「EC2のインスタンスタイプを大きくして（スケールアップ）障害に備える」 → AWSのベストプラクティスでは、巨大な1台よりも「小さな複数台（スケールアウト）」が弾力性の正解です。 – 「障害時にCloudWatchアラームで管理者にメールし、手動で再起動する」 → 「自動復旧」がクラウドの弾力性です。手動操作は不正解。
💡 5. 覚え方
🧠 暗記ショートカット – 弾力性のあるEC2 = 「トカゲのしっぽ」。 – 切れても（ダウンしても）すぐに生えてくる（Auto Scaling）。ただし、しっぽに大事なもの（セッションデータ）をしまっておくと一緒に無くなるので注意。
📚 6. 関連サービス
| アイコン | サービス名 | 弾力性における役割 |
|---|---|---|
| 📈 | Auto Scaling | EC2の増減と死活監視（自己修復）を担う |
| ⚖️ | ELB | 増減するEC2に対してトラフィックを綺麗に振り分ける |
| 💿 | AMI | スケールアウト時に、常に同じ設定のEC2を爆速で立ち上げるための「金型」 |
🗒️ 7. Obsidian管理メモ
- 見返すタイミング: Auto Scaling、ステートレスアーキテクチャの学習時
- 関連ノート候補:
AWS_SAA_Auto_Scaling,AWS_SAA_Stateless
8. HTMLファイル名:
AWS_弾力性設計_EC2.html
