AWS SAA 試験勉強（4日目）
投稿日：2026/03/04
AWS 認定ソリューションアーキテクト – アソシエイト（SAA-C03）において、最も配点が高いテーマの一つが 「高可用性（High Availability）」 です。
試験では「この要件において、最もダウンタイムを短縮できる構成はどれか？」といった、状況に応じた最適解を選ぶ力が問われます。
今回は、鉄板の設計パターンを整理します。
高可用性設計の4大原則
AWSで「壊れない」システムを作るための基本ルールです。
- 単一障害点（SPOF）の排除: 一箇所壊れたら全部止まる、という箇所をゼロにする。
- マルチAZ（Availability Zone）構成: 物理的に離れたデータセンター群に分散させる。
- 自動フェイルオーバー: 障害検知から切り替えまでを自動化する。
- 疎結合（Decoupling）: システムのコンポーネント同士を「SQS」などで切り離し、一部の故障が全体に波及するのを防ぐ。
パターン①：Web 3層アーキテクチャ（最も標準的な形）
最も出題頻度が高い、伝統的なWebアプリの構成です。
- ALB (Application Load Balancer): 複数のAZにあるEC2へ通信を振り分け。
- Auto Scaling: 負荷や障害に応じて、EC2の台数を自動調整。
- RDS (Multi-AZ):
- メイン（プライマリ） と 待機系（セカンダリ） を別AZに配置。
- データの同期レプリケーションを行い、障害時は自動でエンドポイントが切り替わる。
試験のひっかけ：
「RDS リードレプリカ」は 読み取り性能の向上 が目的であり、自動フェイルオーバー（可用性向上）の機能は持ちません。
可用性なら「Multi-AZ」を選びましょう。
パターン②：サーバーレスによる高可用性
サーバーの管理（パッチ当てやスケーリング設定）をAWSに丸投げする構成です。
- 構成: API Gateway + Lambda + DynamoDB
- メリット:
- 標準でマルチAZに対応。
- インフラのプロビジョニングが不要なため、人為的ミスによる障害が減る。
- キーワード: 「運用負荷の最小化」「迅速なデプロイ」。
パターン③：ディザスタリカバリ（DR）の4つの戦略
リージョン全体がダウンするような大規模災害に備える設計です。
コストと復旧スピード（RTO/RPO）のトレードオフが問われます。
- バックアップ＆リストア: データを別リージョンに保存。最も安価だが、復旧に時間がかかる。
- パイロットライト: DBなど最小限のコア部分だけを別リージョンで動かしておく（火種だけ残すイメージ）。
- ウォームスタンバイ: 本番より小規模な構成を別リージョンで常に動かしておく。
- マルチサイト（アクティブ/アクティブ）: 両方のリージョンでフル稼働。RTOはほぼゼロだが、コストは最大。
パターン④：SQSによる疎結合と「メッセージの保護」
急激な負荷スパイク（アクセス集中）からシステムを守るパターンです。
- 構成: EC2（Web） → SQS → EC2（Worker）
- メリット:
- 後続の処理が遅れても、SQSがリクエストを保持するためデータが消えない（バッファリング）。
- 処理能力を超えたリクエストが来ても、システム全体がクラッシュするのを防げる。
- キーワード: 「非同期処理」「スケーラビリティの確保」。
パターン⑤：S3による高耐久・高可用ストレージ
- 耐久性: 99.999999999% (11ナイン)。データが消える確率はほぼゼロ。
- 可用性: 標準クラスなら3つ以上のAZに自動コピー。
- 重要機能: クロスリージョンレプリケーション (CRR)。法規制や災害対策で、物理的に遠く離れた場所にバックアップを置く必要がある場合に有効。
試験での「考え方テンプレート」
問題文の中に以下のキーワードがあったら、右側のサービスを連想してください。
- 「単一障害点をなくしたい」 → マルチAZ / ELB
- 「DBのダウンタイムを最小化したい」 → RDS Multi-AZ
- 「急激な負荷でもリクエストを落としたくない」 → SQS
- 「運用負荷を下げつつ、可用性を上げたい」 → サーバーレス (Lambda/DynamoDB)
- 「リージョン障害に備えたい」 → Route 53 (フェイルオーバー) / クロスリージョンレプリケーション
まとめ（4日目の振り返り）
高可用性設計のキモは、「自動化」 と 「分散」 です。
「人間が頑張らなくても、AWSが勝手に直してくれる」構成を作れるかどうかが、ソリューションアーキテクトとしての腕の見せ所になります。