AWS 認定資格 ラボ
SAA（Solutions Architect Associate）攻略 ・

SAA 高可用性設計パターン集｜Multi-AZ と Multi-Region を RTO/RPO で選び切る

AWS SAA-C03 で頻出の「高可用性（HA）／耐障害性」設計を、Multi-AZ と Multi-Region の2階層で体系化する。結論は「まず1リージョン内を Multi-AZ で多重化し、リージョン障害まで守る要件のときだけ Multi-Region に広げる。その広げ方は RTO/RPO でバックアップ&リストア／パイロットライト／ウォームスタンバイ／マルチサイト Active-Active の4段階から選ぶ」こと。ELB+Auto Scaling の水平多重化、RDS Multi-AZ の自動フェイルオーバー、Aurora Global Database・S3 レプリケーション・DynamoDB グローバルテーブルによるリージョン間レプリケーション、Route 53 フェイルオーバールーティングまで、SAA 本番のシナリオでそのまま選択肢を絞れる粒度で解説する。

#AWS #SAA #SAA-C03 #Solutions Architect #高可用性 #Multi-AZ #Multi-Region #ディザスタリカバリ #試験対策 #AWS認定資格

「可用性を上げたい」と言われて、反射的に Multi-Region を選ぶ——それは多くの場合、過剰設計であり SAA-C03 では誤答になる。 高可用性（HA）と耐障害性は、SAA の配点26%を占めるドメイン2「弾力性のあるアーキテクチャの設計」の中核であり、他ドメインのシナリオにも「可用性を最も高める構成はどれか」という形で繰り返し顔を出す、事実上の最重要テーマだ。攻略の鍵は、可用性設計を 「Multi-AZ（1リージョン内の多重化）」と「Multi-Region（リージョン間の冗長化）」の2階層で捉え、要件が求める障害範囲に応じて必要十分な階層を選ぶこと。そして Multi-Region に広げる際は、RTO/RPO を軸に4つの DR 戦略から1つを選び切る。本記事では、各パターンの中核サービス・自動フェイルオーバーの仕組み・頻出ひっかけを、本番でそのまま選択肢を絞れる粒度まで分解する。読み終えれば、「単一障害点をなくし、コストとのバランスも取れた構成はどれか」という問いに、迷わず正解を引き当てられるようになる。

※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます

📑 目次

  1. 結論：可用性は「Multi-AZ が先、Multi-Region は要件次第」
  2. 高可用性を測る2つのものさし：RTO と RPO
  3. Multi-AZ パターン：1リージョン内で単一障害点を消す
  4. Multi-Region パターン：4つの DR 戦略を RTO/RPO で選ぶ
  5. リージョン間レプリケーションとフェイルオーバーの実装
  6. 頻出ひっかけパターンと打ち手の整理
  7. 次のアクション チェックリスト
  8. 関連記事
  9. 関連サイト

1. 結論：可用性は「Multi-AZ が先、Multi-Region は要件次第」

SAA-C03 の可用性設計問題を最短で解く骨格は、**「まず1リージョン内を Multi-AZ で多重化し、リージョン全体の障害まで守る要件があるときだけ Multi-Region に広げる」**という順序で考えることだ。これが本記事の結論である。

理由は明快で、AWS の可用性は「単一障害点（SPOF）をなくす」ことに尽きるが、その障害の“範囲”には階層があるからだ。1台のインスタンス障害・1つの AZ（アベイラビリティゾーン）障害までは Multi-AZ で守れる。そしてこれが大多数の要件を満たす。一方、リージョン全体が使えなくなる事態や、地理的に離れた場所での事業継続（BCP）まで求められる場合に初めて、コストと複雑さの跳ね上がる Multi-Region が視野に入る。

具体例で見よう。「Web アプリの可用性を高めたい」——これは ELB と Auto Scaling を複数 AZ にまたがって配置すれば十分だ（Multi-AZ）。「DB の障害に自動で切り替えたい」——RDS Multi-AZ のスタンバイが自動フェイルオーバーする（Multi-AZ）。ここでいきなり別リージョンへの複製を持ち出すのは、コスト観点で誤答になりやすい。逆に「リージョン障害が起きても数分で復旧させたい」「地理的に離れた DR サイトが要る」と明示されて初めて、Aurora Global Database や Route 53 フェイルオーバーによる Multi-Region 構成が正解になる。

2. 高可用性を測る2つのものさし：RTO と RPO

可用性・DR 設計の選択肢を評価するには、RTO と RPO という2つの指標を必ず押さえる。SAA ではこの2語がシナリオの要件文にそのまま埋め込まれ、正解の DR 戦略を一意に決める“鍵”として機能する。

  • RTO（Recovery Time Objective／目標復旧時間）：障害発生から復旧までに許容できる 時間。「何時間以内に復旧するか」。短いほど高コスト。
  • RPO（Recovery Point Objective／目標復旧時点）：障害時に許容できる データ損失の量を時間で表す。「どの時点まで戻れるか＝どれだけのデータ損失を許すか」。短い（＝ゼロに近い）ほど高コスト。

この2つのものさしを持つと、DR 戦略は「RTO/RPO をどこまで短くしたいか」の一直線上に並ぶ。コストは RTO/RPO を短くするほど上がる——このトレードオフを選択肢の評価軸にするのが、可用性問題の解き方の本質だ。

3. Multi-AZ パターン：1リージョン内で単一障害点を消す

まず土台となるのが Multi-AZ だ。AWS の1リージョンは、物理的に分離された複数の **AZ（データセンター群）**で構成される。リソースを複数 AZ に分散すれば、1つの AZ で停電・水害・機器障害が起きても、他 AZ でサービスを継続できる。SAA で問われる Multi-AZ パターンは、レイヤーごとに定石が決まっている。

レイヤー別の Multi-AZ 定石

レイヤーMulti-AZ の実装障害時の挙動
Web/アプリ層ALB + Auto Scaling を複数 AZ に展開障害 AZ を切り離し、健全 AZ で継続・自動補充
リレーショナル DBRDS Multi-AZ（同期スタンバイ）プライマリ障害時にスタンバイへ自動フェイルオーバー
高可用 DBAurora（3 AZ に6コピー）ストレージ分散＋レプリカ昇格で高速復旧
ストレージS3（標準で複数 AZ に冗長化）設計不要で 99.999999999% の耐久性

Web 三層アーキテクチャの黄金パターン

SAA で「可用性の高い Web アプリ構成」を問われたときの模範解答は、ほぼ1つに収束する。**複数 AZ にまたがる ALB + Auto Scaling グループ + Multi-AZ RDS（または Aurora）**だ。フロントは Route 53 でドメインを解決し、静的配信は CloudFront でキャッシュする。ステートは DynamoDB や ElastiCache に外出しし、EC2 自体はステートレスに保つ——こうすればどの AZ が落ちても、Auto Scaling が健全 AZ でインスタンスを補充し、ELB がトラフィックを振り直す。

4. Multi-Region パターン：4つの DR 戦略を RTO/RPO で選ぶ

リージョン障害まで守る要件が出て初めて、Multi-Region が正解候補になる。AWS はリージョン間のディザスタリカバリを、RTO/RPO の短さ（＝コスト）に応じた4つの戦略として体系化している。SAA では、この4戦略を RTO/RPO の要件から逆算して選ぶ問題が定番だ。

AWS の4つの DR 戦略（RTO/RPO とコストのトレードオフ）
評価項目
バックアップ&リストア
パイロットライト
ウォームスタンバイ 推奨
マルチサイト Active-Active
RTO の目安 数時間〜1日 数十分〜数時間 数分 ほぼゼロ（無停止）
RPO の目安 数時間 数分 数秒〜数分 ほぼゼロ
待機側の状態 データのみ退避 コア最小限が起動 縮小版が常時稼働 本番同等が両リージョン稼働
コスト 最小 小 中 最大
キーワード 「コスト重視」「復旧に時間可」 「重要部分だけ待機」 「縮小構成で即応」 「無停止」「RTO/RPOほぼゼロ」
RTO/RPO を短くするほどコストが上がる。要件の『許容ダウンタイム』と『許容データ損失』から、必要十分な戦略を1つ選ぶ。

4戦略の見分け方

  • バックアップ&リストア：別リージョンに バックアップや S3 レプリケーションでデータだけ退避し、災害時にインフラを一から構築して復元する。最も安いが RTO は最長。「コスト最優先」「復旧に時間がかかってよい」がキーワード。
  • パイロットライト：DB のレプリカなどコアだけを常時稼働させ、アプリ層は停止しておく。災害時にサーバーを“点火”して起動・スケールする。バックアップ&リストアより速い。
  • ウォームスタンバイ：本番の縮小版を常時稼働させ、災害時は即座にトラフィックを受けてスケールアップする。「縮小構成で待機」「すぐ受けられるが本番容量ではない」がキーワード。
  • マルチサイト Active-Active：両リージョンで本番同等を常時稼働させ、平常時からトラフィックを分散する。RTO/RPO ほぼゼロだが最も高コスト・高複雑。「無停止」「ダウンタイムを許さない」がキーワード。

5. リージョン間レプリケーションとフェイルオーバーの実装

Multi-Region を実現するには、「データをどう複製するか」と「トラフィックをどう切り替えるか」の2つを実装する必要がある。SAA では、この2レイヤーの中核サービスを問う問題が出る。

データのリージョン間レプリケーション

データ種別リージョン間レプリケーションの手段特徴
リレーショナル DBAurora Global Database通常1秒未満のレプリケーション遅延・高速なリージョン昇格
NoSQLDynamoDB グローバルテーブルマルチリージョンの Active-Active・双方向レプリケーション
オブジェクトS3 クロスリージョンレプリケーション（CRR）バケット単位で別リージョンへ非同期コピー
バックアップAWS Backup のクロスリージョンコピー復旧ポイントを別リージョンに保管

トラフィックのフェイルオーバー

リージョン間の切り替えは、Route 53 の DNS ルーティングが担う。SAA 頻出は次の2つだ。

  • フェイルオーバールーティング：ヘルスチェックと組み合わせ、プライマリが異常になったらセカンダリリージョンへ自動で切り替える。Active-Passive 構成の定番。
  • レイテンシールーティング／地理的近接ルーティング：ユーザーを最も近い・最速のリージョンへ振り分ける。Active-Active 構成でグローバルにレイテンシを最小化する。

さらに、DNS の TTL に依存せず即座にリージョン間フェイルオーバーしたい場合は、AWS Global Accelerator が選択肢になる。固定のエニーキャスト IP を使い、AWS のバックボーン経由で健全なリージョンへ高速に振り向ける。「DNS キャッシュの影響を受けずに素早く切り替えたい」がキーワードになったら Global Accelerator を疑おう。

6. 頻出ひっかけパターンと打ち手の整理

可用性設計は、正しい打ち手と“やりがちな誤答”がはっきり対になっている。ここを表で押さえれば、本番のシナリオで選択肢を機械的に振るえる。

7. 次のアクション チェックリスト

高可用性設計パターンを、今日からの学習に落とし込むための具体アクションをまとめる。

8. 関連記事

9. 関連サイト

AWS 公式