信頼性の非機能要件とDR・BCP

高可用性（HA）をどう捉えるか

クラウド上では、単一コンポーネントの障害が起きてもサービスを継続できるようにすることが「高可用性」の中心です。ダウンタイムを限りなくゼロに近づけるアーキテクチャ目標として語られることが多く、SAA では「どのレイヤーで冗長を取るか」が選択肢とセットで出ます。

AWS のサービスは大きく二つに分けて覚えると混乱しにくいです。

• サービス側で高可用が組み込まれているもの … 例: S3（耐久性モデル）、Route 53、Lambda、SQS など。データプレーンの冗長を意識しすぎなくてよいケースが多いです。
• ユーザーがマルチ AZ・ELB・Auto Scaling などで高可用を“組み立てる”もの … 例: EC2 上のアプリ、RDS／ELB／Direct Connect など。単一 AZ・単一インスタンスのままでは SPOF になりやすい、という文脈で試験に出ます。

Well-Architected における「信頼性」と設計の観点

信頼性（Reliability）は、障害による中断を減らし、復旧の影響を抑えるための柱です。試験の長文シナリオでは、次のような設計の方向性が一文でまとめられていることがあります（用語を拾えるようにしておくとよいです）。

• インフラの障害復旧の自動化 … 手作業の Runbook だけに頼らず、フェイルオーバー・再起動・スケールを自動化する。
• 復旧手順の検証 … BCP に即した訓練（ゲームデイ、フェイルオーバー演習）で RTO／RPO が達成可能か確認する。
• 需要変化に応じた水平スケーラビリティ … 需要予測だけに頼らず、Auto Scaling などで台数を追従させる。
• キャパシティの推測に頼りすぎない … ピーク見積もりの過剰プロビジョニングだけではなく、伸縮と監視で合わせる考え方。
• モニタリングと自動化 … CloudWatch やイベント駆動で異常を検知し、対処につなぐ。

これらは「単語暗記」ではなく、どの選択肢がこの柱に最も沿うかを選ぶ問題に変換されます。

RTO と RPO

障害や災害を想定した設計では、次の指標が議論の土台になります。

• RTO（Recovery Time Objective） … 障害発生からどれくらいの時間内に業務を再開するかの目標。スタンバイへのフェイルオーバー時間、DNS 切り替え、バックアップからのリストアに要する時間の上限イメージです。
• RPO（Recovery Point Objective） … どの時点までのデータで復旧すればよいかの目標。バックアップ間隔、非同期レプリカのラグ、同期レプリケーションの有無とセットで決まります。RPO を短くするほど、同期レプリケーション・頻繁なスナップショット・マルチ AZ など、コストと複雑さが増えがちです。

シナリオで効く対応の引き算

試験では、文章の許容損失と許容ダウンタイムを読み取り、次のような対応を選べるとよいです。

要件の読み取り	検討しやすい施策の方向
RPO を極小にしたい（データ損失をほぼ不可）	マルチ AZ の同期スタンバイ、適切なレプリケーション設計、ミッションクリティカルならさらに厳密な戦略
RTO を短くしたい（すぐ業務再開）	スタンバイと自動フェイルオーバー、ヘルスチェック付き DNS、温／熱スタンバイ
長期保管だが即時復旧は不要	スナップショット・クロスリージョンコピー、コールドスタンバイ

関連する非機能の言葉

• 耐障害性（Fault Tolerance） … コンポーネント障害があっても冗長構成により継続運用しやすくする性質。HA と混同されやすいが、試験では「冗長コンポーネント」「自動フェイルオーバー」などのキーワードでセットに出ることがあります。
• 復元可能性 … 障害・災害後に手順とバックアップに基づいて復旧する能力。BCP・バックアップ戦略とセットです。
• 拡張性 … 負荷増に応じてスケールアウトやリードレプリカなどで伸ばせるか。信頼性の柱の「水平スケール」とつながります。

耐障害性を高めるパターン（概要）

代表的な考え方です（詳細は ELB・RDS・S3 の各トピックへ）。

• 別 AZ／別リージョンにバックアップやレプリカを置き、単一データセンターや単一リージョン障害に備える。
• スタンバイ構成を用意し、DNS やヘルスチェックと組み合わせてフェイルオーバーできるようにする。
• **事業継続計画（BCP）**として、復旧手順を文書化し、定期的に復旧・フェイルオーバーを訓練し、RTO／RPO が現実的か検証する。

トレードオフと試験で落とし穴になりやすい点

可用性を上げるほど、コスト・構成の複雑さ・運用負荷は増えやすいです。すべてをマルチリージョン・アクティブ・アクティブにするのは強力ですが、データ整合性・運用・料金のすべてが重くなります。

• 「S3 は高耐久だからアプリも自動で高可用」 … 誤り。S3 のオブジェクト耐久性と、EC2 アプリの可用性は別問題です。
• 「バックアップさえ取れば RPO は常にゼロ」 … 誤り。スナップショット間隔とトランザクションログの有無で RPO は決まります（RDS の PITR は別トピック）。
• 「RTO だけ短くすればよい」 … シナリオによっては RPO（データの鮮度） の方が致命的、という問題が出ます。

ビジネス要件に合わせて、どのレイヤーまで冗長にするかを決めるのが設計の本質です。

公式ドキュメント（深掘り）

• Reliability pillar - AWS Well-Architected Framework
• AWS Well-Architected Framework の概要