【単一障害点の排除の役割（設計のベストプラクティス）】
目次
🔍 1. 結論
💎 一言でいうと 単一障害点（SPOF: Single Point of Failure）の排除とは、「そのコンポーネントが壊れたらシステム全体が止まってしまう箇所」をなくす 設計原理です。AWSでは主に マルチAZ（Multi-AZ）展開 と 冗長化（Redundancy） によってこれを実現します。
- SAAで「高可用性」「障害に強い」と出たら、答えは マルチAZ（Multi-AZ） が鉄則。
- EC2インスタンスは必ず複数台用意し、ELB で負荷を分散する。
📈 2. SAAで出やすいポイント
- Multi-AZ アーキテクチャ: EC2やRDSを1つのアベイラビリティゾーン（AZ）だけでなく、複数のAZに分散・配置 する。これにより、1つのデータセンター群が物理的にダウンしてもシステムが生き残る。
- ELBによるヘルスチェックとルーティング: ロードバランサー（ELB）は背後のインスタンスの健康状態（ヘルスチェック）を確認し、異常なインスタンスを切り離して正常なインスタンスにのみトラフィックを送る。
- データ層の冗長化: RDSの Multi-AZ デプロイメント（スタンバイDBを別AZに自動用意）、またはS3（デフォルトで最低3つのAZにデータを分散保存）。
🗝 3. キーワードでの判断
| 問題文のキーワード | 疑うサービス・構成 |
|---|---|
| 🛡️ 「高可用性」「単一障害点をなくす」 | マルチAZ (Multi-AZ) 構成 |
| ⚖️ 「障害インスタンスを回避する」 | ELB (ヘルスチェック) |
| 🐘 「DBのフェイルオーバー」「自動切り替え」 | RDS Multi-AZ |
| 🌍 「リージョンレベルの障害に備える（DR）」 | Route 53 (フェイルオーバールーティング) |
⚠️ 4. ひっかけポイント
🚫 よくある誤答パターン – 「1つのAZ内でEC2を複数台立ち上げる」 → EC2レベルの障害には耐えられますが、AZ自体の障害（停電など）で全滅 するため、SPOF排除としては不十分。必ず「複数のAZ」にまたがる選択肢を選ぶ。 – 「RDSのリードレプリカで可用性を高める」 → リードレプリカは「読み取り負荷分散（パフォーマンス）」が目的。障害時の自動切り替え（高可用性）の目的は Multi-AZ。
💡 5. 覚え方
🧠 暗記ショートカット – SPOF排除 = 「カゴを分ける」（Don’t put all your eggs in one basket.） – 合言葉: 「高可用性と言われたら、マルチAZ を探せ！」
📚 6. 関連サービス
| アイコン | サービス名 | SPOF排除における役割 |
|---|---|---|
| ⚖️ | ELB | トラフィックの分散と異常インスタンスの切り離し |
| 🏢 | マルチAZ (Multi-AZ) | 物理的に独立したデータセンター群へのリソース分散 |
| 🐘 | RDS Multi-AZ | プライマリDBが落ちた際にスタンバイDBへ自動切り替え |
| 🌐 | Route 53 | ヘルスチェックを用いた別リージョンへのフェイルオーバー |
🗒️ 7. Obsidian管理メモ
- 見返すタイミング: ネットワーク設計、RDSの構成オプションの学習時
- 関連ノート候補:
AWS_SAA_High_Availability,AWS_SAA_RDS_Multi_AZ
8. HTMLファイル名:
AWS_設計原理_単一障害点の排除.html
