導入
DRが「リージョン規模の災害」に備える仕組みだとすれば、日常的に起きる小さな障害（1台のインスタンス障害、1つのAZの障害）への備えが高可用性（HA）設計です。SAPでは、この2つを区別しつつ、両方を組み合わせて設計できることが求められます。
説明
高可用性設計の基本パターンを整理します。
| パターン | やること | 効果 |
|---|---|---|
| Multi-AZ配置 | 同一リージョン内の複数AZにリソースを分散 | AZ単位の障害を吸収 |
| 自動復旧 | Auto Scaling・ELBヘルスチェック・RDS Multi-AZで異常系を自動置換 | 人手を介さず数分で復旧 |
| 疎結合化 | コンポーネント間をSQS/SNS/EventBridgeで非同期に接続 | 1コンポーネントの障害が他へ連鎖しない |
| フォールトインジェクション | 意図的に障害を注入して耐障害性を検証 | 「実際に壊して確認」で設計の穴を発見 |
flowchart TD
ELB["ELB"] --> AZ1["AZ-a: EC2"]
ELB --> AZ2["AZ-b: EC2"]
AZ1 & AZ2 --> Q["SQSキュー（疎結合）"]
Q --> W["ワーカー（複数AZ）"]
W --> DB["RDS Multi-AZ"]
疎結合化がなぜHAに効くかというと、コンポーネント同士が直接同期呼び出しで繋がっていると、1つが遅延・停止すると連鎖的に全体が詰まるからです。SQSやSNS、EventBridgeを間に挟むことで、片方が一時的に停止してもキューにメッセージが溜まるだけで、復旧後に処理を再開できます。
最後に、AWSには「本当に壊れても大丈夫か」を実際に検証するサービスがあります。AWS Fault Injection Service（FIS） は、EC2の強制停止・CPU負荷・ネットワーク遅延・AZ停止のシミュレーションなど、意図的に障害を注入する実験を安全に実行できるマネージドサービスです。カオスエンジニアリングの考え方をAWS上で実践するための道具として位置づけられます。
読んでみよう
「1つのAZが落ちてもサービスを継続したい」はMulti-AZ＋自動復旧、「1つのコンポーネントの障害が他に波及しないようにしたい」は疎結合化、「本番同等の環境で実際に障害耐性を検証したい」はFISが、それぞれのキーワードに対応する定番の答えです。DR（リージョン規模）とHA（AZ・コンポーネント規模）は問題文の被害範囲で見分けてください。