導入
「サーバーが1台落ちたらサイト全体が止まった」——これがSAAで最も嫌われる設計です。どこか1点が壊れただけでシステム全体が止まる箇所を 単一障害点（SPOF: Single Point of Failure） と呼びます。SAAの回復性問題の大半は、突き詰めると「このSPOFをどう消すか」です。
説明
SPOFを消す基本戦略は2つだけです。
- 冗長化（Redundancy）：同じ役割のリソースを複数用意する
- 複数AZへの分散：冗長化したリソースを、異なるアベイラビリティゾーンに置く
1台のEC2だけでWebサーバーを動かしていれば、そのインスタンスが落ちればサービス停止です。同じAZ内で2台に増やしても、AZごと（データセンターごと）の障害には耐えられません。必ず異なるAZに分散して冗長化するのがSAAの大原則です。
この原則をそのまま体現するのが、SAAで繰り返し登場する定番構成です。
flowchart TD
U["利用者"] --> ELB["Elastic Load Balancing"]
ELB --> A1["EC2（AZ-a）"]
ELB --> A2["EC2（AZ-c）"]
A1 --> ASG["Auto Scaling グループ<br/>（AZをまたいで台数を自動調整）"]
A2 --> ASG
A1 --> RDS["RDS Multi-AZ<br/>（プライマリ＋スタンバイ）"]
A2 --> RDS
| コンポーネント | 役割 | SPOFをどう消すか |
|---|---|---|
| Elastic Load Balancing（ELB） | 複数AZのインスタンスへリクエストを分散 | ELB自体もAWSがマネージドで冗長化・ヘルスチェックで不健全なインスタンスを自動除外 |
| Auto Scaling | 需要と障害に応じてインスタンス数を自動調整 | 落ちたインスタンスを自動で置き換え、複数AZに均等配置 |
| RDS Multi-AZ | 別AZに同期レプリカ（スタンバイ）を待機させる | プライマリ障害時に自動フェイルオーバー |
この「ELB＋Auto Scaling（複数AZ）＋Multi-AZ RDS」の組み合わせが、SAAにおける高可用性アーキテクチャの標準形です。以降のレッスンは、この形にどう機能を足していくかという話になります。
読んでみよう
問題文に「単一障害点をなくしたい」「可用性を高めたい」とあれば、まず「冗長化されているか」「複数AZに分かれているか」をチェックしましょう。選択肢に1台構成・単一AZ構成が混ざっていたら、それはまず不正解です。