モジュール 12 · SAA-C03

アーキテクチャパターン：高可用性、ディザスタリカバリー、疎結合

Multi-AZ、マルチリージョン、RTO / RPO に応じた 4 つの DR 戦略、サーバーレスとイベント駆動アーキテクチャ、多層キャッシュ。

分野弾力性のあるアーキテクチャ
分野高性能なアーキテクチャ
図 12
出題パターン 10
サービス 16

5 分で押さえる要点

RPO は許容できるデータ損失の最大量 (時間で表します)、RTO はサービスの復旧までに許容できる最大時間です。RPO 15 分とは、データのコピーが 15 分より古くなってはならないという意味です。問題で RPO / RTO と予算が示されるので、それに合う DR 戦略を選びます。
1 つのリージョン内の高可用性 (HA) = すべての階層を少なくとも 2 つの AZ に配置すること。ディザスタリカバリー (DR) = 別のリージョンに代替手段を用意すること。ALB + 複数 AZ の Auto Scaling グループ + RDS Multi-AZ なら、1 つの AZ の喪失に耐えられます。リージョン全体の喪失には DR が必要です。
Backup & restore：データ (と設定) のバックアップだけを別のリージョンに保存します。最も安価ですが、RTO / RPO は最長 (数時間程度) です。素早く正確に再構築するには、インフラを IaC (CloudFormation、CDK) で記述しておき、AMI と設定もバックアップします。
Pilot light：データは DR リージョンで常時稼働して継続的に複製され、アプリケーションサーバーは「停止」状態 (未デプロイまたは 0 台) で、必要時に起動します。RTO は数十分程度です。Elastic Disaster Recovery は、サーバー向けの pilot light そのものです。
Warm standby：DR リージョンで縮小版を全機能が動く状態で稼働させ、すぐにトラフィックを受けられ、スケールアップするだけで済みます。pilot light との違い：pilot light は処理を始める前にマシンを起動する必要がありますが、warm standby は低い処理能力ですぐに処理できます。
Multi-site active/active：複数のリージョンでフル容量を同時に稼働させます。RTO はほぼ 0 で、最も高価かつ複雑です。削除または破損したデータはすべてのリージョンに伝播します。時点指定のバックアップは引き続き必要です。
Aurora Global Database：別のリージョンへの複製は通常 1 秒未満で、セカンダリリージョンのプライマリへの昇格は 1 分未満です。複数リージョンのリレーショナルデータベースで、RPO は秒単位、RTO は分単位です。DynamoDB グローバルテーブルは任意のリージョンで書き込みでき、最後の書き込みが優先されます。
障害時のトラフィック切り替え：Route 53 フェイルオーバー (ヘルスチェック)、Application Recovery Controller (能動的なフェイルオーバースイッチ)、Global Accelerator (静的 IP、エンドポイントを即時切り替え)。Route 53 は DNS の TTL に依存し、Global Accelerator は DNS キャッシュの影響を受けません。CloudFront のオリジンフェイルオーバーは、失敗したリクエストごとにセカンダリオリジンを試すだけです。
SQS による疎結合：送信側が処理をキューに入れ、ワーカーが自分の処理能力に合わせて処理します。キューがピーク負荷を吸収します。Auto Scaling グループ内のワーカーは、待機中のメッセージ数 (ApproximateNumberOfMessagesVisible / インスタンスあたりのバックログ) に応じてスケールします。
ファンアウト：1 つのイベントを複数の受け手が独立して処理する → SNS から複数の SQS キューへ送信 (または複数のルールを持つ EventBridge)。受け手ごとに専用のキューがあるため、処理が遅い / 失敗する受け手が他に影響しません。
ステートレスなアプリケーション：セッションをマシンに保持せず、ElastiCache または DynamoDB に保存します。Auto Scaling がマシンを自由に追加 / 削除 / 置き換えでき、sticky session は不要です。
多層キャッシュ：エッジに CloudFront、データベースの前に ElastiCache、DynamoDB の前に DAX、読み取り負荷にはリードレプリカ。読み取りレイテンシーの短縮やデータベース負荷の軽減が問われたら、ボトルネックに最も近い階層のキャッシュを選びます。
サーバーレス (API Gateway + Lambda + DynamoDB + S3) は自動でスケールし、使用量に応じた課金で、サーバー管理が不要です。「負荷が不均一、運用担当が少ない、従量課金」→ サーバーレス。

構成図

1 つのリージョン内の高可用性：すべての階層を 2 つの AZ に配置

ALB は 2 つの AZ にまたがり、Auto Scaling グループは両方の AZ に最小台数のマシンを維持し、RDS Multi-AZ には同期スタンバイがあります。1 つの AZ を失ってもシステムは稼働し続けます。

ステップ

ALB は両方の AZ のマシンに負荷を分散し、異常なマシンは除外します。
RDS は別の AZ のスタンバイへ同期書き込みを行います。AZ a が故障するとスタンバイが自動で昇格し、Auto Scaling が AZ b のマシンを補充します。

Backup & restore 型の DR

DR リージョンにはバックアップだけがあります。災害時は CloudFormation でインフラを再構築してからデータを復元します。最も安価ですが、最も遅い方法です。

ステップ

AWS Backup が EC2、RDS などをスケジュールに従ってバックアップします。バックアップの頻度が RPO を決めます。
バックアップは DR リージョンにコピーされます。
災害時：CloudFormation を実行してインフラを構築し、データを復元します。RTO は時間単位です。

Pilot light 型の DR

DR リージョンでは、データが常時稼働して継続的に複製されます。アプリサーバーは設定済みですが稼働していません。フェイルオーバー：アプリサーバーを起動し、データベースを昇格し、DNS を切り替えます。

ステップ

通常時はすべてのトラフィックが主リージョンに向かいます。
データは DR リージョンへ継続的に複製されます (RPO は秒)。
フェイルオーバー：Auto Scaling を 0 から増やし、DR リージョンの Aurora を昇格し、DNS を切り替えます。RTO は数十分程度です。

Warm standby 型の DR

DR リージョンには、全機能が動く縮小版があります。ヘルスチェックが失敗すると Route 53 フェイルオーバーがすぐにトラフィックを切り替え、その後 Auto Scaling がフル容量まで増やします。

ステップ

主リージョンがすべてのトラフィックを処理します。
DR リージョンでは縮小版が稼働しており、データは継続的に複製されます。
ヘルスチェックが失敗すると、Route 53 が DR リージョンへ切り替えます。縮小版がすぐに処理を始め、Auto Scaling が徐々に増やします。RTO は数分です。

DynamoDB グローバルテーブルによる multi-site active/active

両方のリージョンが同時にトラフィックを処理します。Route 53 レイテンシールーティングがユーザーを最寄りのリージョンへ誘導し、DynamoDB グローバルテーブルが両方での書き込みを可能にします。

ステップ

Route 53 は、各ユーザーに対してレイテンシーが最も低いリージョンを返します。
各リージョンが自分で処理し、自分の global table のコピーに書き込みます。
DynamoDB が双方向に複製します。リージョンが故障したら Route 53 がそのリージョンを除外し、RTO はほぼ 0 です。

SQS による疎結合：キューに応じてワーカーをスケール

Web は注文を受け付けてすぐに応答し、重い処理はキューに入ります。ワーカーはマシンあたりの待機メッセージ数に応じて Auto Scaling し、何度も失敗したメッセージは dead-letter queue に送られます。

ステップ

Web は注文をキューに入れ、すぐに顧客へ応答します。
ワーカーがメッセージを取得して処理し、完了したら削除します。
ワーカーあたりの待機メッセージ数が増えると、Auto Scaling がワーカーを追加します。
許容回数を超えて失敗したメッセージは、確認のため dead-letter queue に移されます。

ファンアウト：SNS から複数の SQS キューへ

「新規注文」イベントが SNS によって 3 つのキューにプッシュされます。各サービスに専用のキューがあるため、遅延や失敗があっても他のサービスに影響しません。

ステップ

注文サービスはイベントを 1 つ発行するだけで、誰が受信するかを知る必要はありません。
SNS が登録済みの各キューにコピーを送信します。
各受け手が自分の速度で処理し、失敗した場合は自分のキュー内で再試行します。

多層キャッシュとマシン外へのセッション保存

CloudFront はエッジでキャッシュし、ElastiCache はよく使うクエリ結果とセッションを保持し、データベースには残りだけが届き、リードレプリカが追加の読み取り負荷を担います。

ステップ

キャッシュ可能なコンテンツは CloudFront がエッジですぐに返し、残りだけが ALB へ向かいます。
アプリはまず ElastiCache を参照します (cache-aside)。セッションもここにあるため、アプリは状態を持ちません。
キャッシュミスの場合にのみデータベースへクエリし、結果をキャッシュに書き戻します。リードレプリカが追加の読み取り負荷を担います。

サーバーレス Web アプリケーション

静的なフロントエンドは S3 から CloudFront 経由で配信し、API Gateway が Lambda を呼び出し、データは DynamoDB に保存します。すべてのコンポーネントが自動でスケールし、使用量に応じて課金されます。

ステップ

静的ページはエッジでキャッシュされ、プライベートな S3 から取得されます。
API 呼び出し：API Gateway が Lambda を起動し、Lambda が DynamoDB を読み書きします。リクエストがないときは稼働しているサーバーはありません。

ECS Fargate 上のマイクロサービス：path ベースの ALB、Cloud Map、サービスごとに 1 つのデータベース

ALB はパスに応じて各サービスへルーティングします。サービス同士は Cloud Map の名前 (正常なタスクだけを返す) で呼び出し合うため、IP を知る必要はありません。各サービスが専用のデータベースを持つので、デプロイもスケールも独立して行えます。

ステップ

ALB がパスを判定します。/orders/* は orders サービスへ、/users/* は users サービスへ送られます。
payments のタスクは自分で Cloud Map に登録します。orders は payments.shop.local の名前を解決して直接呼び出し、正常なタスクだけを受け取ります。
サービスごとに専用のデータベースを持ちます。1 つのサービスのスキーマ変更やスケールが、他のサービスに波及しません。

ハイブリッドアーキテクチャ：Transit Gateway でオンプレミスを複数の VPC に接続

Direct Connect を主回線、Site-to-Site VPN をバックアップとし、どちらも Transit Gateway に接続することで、オンプレミスからすべての VPC に到達できます。DNS は Route 53 Resolver エンドポイントで双方向に解決します。

ステップ

通常時：オンプレミスは Direct Connect (Direct Connect gateway 経由の transit VIF) を通って Transit Gateway に入ります。
Direct Connect が故障すると、BGP がインターネット経由の VPN に切り替わります。
Transit Gateway は、そのルートテーブルに従って、オンプレミスをアタッチ済みのすべての VPC に接続します。
プライベートホストゾーンの名前は、inbound endpoint 経由でオンプレミスから名前解決されます。

ディザスタリカバリー戦略を選ぶ

4 つの戦略は、最も安価で復旧が最も遅いものから、最も高価でほぼ無停止のものの順に並んでいます。業務が要求する RTO / RPO を満たす最も安価なものを選びます。

ステップ

RPO は秒単位だが、マシンの構築待ちは許容できる場合：pilot light (データベースは継続複製、アプリは必要時に起動)。
停止が許されない場合：複数リージョンの active/active で、最も高価です。

比較表

4 つのディザスタリカバリー戦略

戦略	DR リージョンにあるもの	一般的な RPO / RTO	コスト	よく使うサービス
Backup & restore	バックアップのみ	数時間	最も低い	AWS Backup (別リージョンへコピー)、スナップショット、S3 CRR、CloudFormation
Pilot light	データは稼働・継続複製、アプリサーバーは停止	数十分	低い	Aurora Global Database、別リージョンの RDS リードレプリカ、Elastic Disaster Recovery
Warm standby	全機能が動く縮小版	数分	中程度	pilot light と同様 + Auto Scaling、Route 53 フェイルオーバー
Multi-site active/active	フル構成で同時に稼働	ほぼ 0	最も高い	DynamoDB グローバルテーブル、Aurora Global Database、Route 53 / Global Accelerator

データベースのレプリケーション：耐障害性か、読み取りのスケールか

	RDS Multi-AZ (インスタンス)	リードレプリカ	Aurora Global Database	DynamoDB グローバルテーブル
目的	リージョン内の耐障害性	読み取りのスケール (別リージョンなら DR も)	マルチリージョン DR、ユーザーに近い場所での読み取り	複数リージョンでの書き込み / 読み取り
レプリケーション	同期	非同期	非同期、通常 1 秒未満	非同期
セカンダリが読み取りに対応	いいえ (standby)	はい	はい	はい、書き込みも可
切り替え	自動フェイルオーバー	手動で昇格	セカンダリリージョンを昇格 (1 分未満)	不要：どのリージョンでも書き込み可能

疎結合：処理の受け渡し方法の選択

	SQS	SNS	EventBridge	Kinesis Data Streams
タイプ	キュー (1 つの受け手が各メッセージを処理)	Pub/sub で複数の受け手へプッシュ	イベントバス、内容によるフィルタリング	順序付きストリーム、再読み取り可能
適した用途	ピーク負荷の吸収、ワーカーのスケール	ファンアウト、通知	AWS サービス / SaaS の統合、ルール	大量のリアルタイムデータ
メッセージの保持	最大 14 日	保持しない	アーカイブして再生可能	24 時間〜365 日

キャッシュの置き場所

階層	サービス	軽減するもの
エッジ (ユーザーの近く)	CloudFront	キャッシュ可能な静的コンテンツ / API のレイテンシーとオリジンへの負荷
アプリケーション	ElastiCache (Redis OSS / Valkey / Memcached)	繰り返されるデータベースクエリ、セッションの保存
DynamoDB の前	DAX	読み取りレイテンシーをマイクロ秒単位に短縮
データベース	リードレプリカ	プライマリへの読み取り負荷

よく出る出題パターン

1Web アプリケーションが 1 つの AZ の 1 台の EC2 で稼働しています。妥当なコストで 1 つの AZ の喪失に耐える必要があります。

答えを見る

正解: 2 つ以上の AZ にまたがる ALB + Auto Scaling グループ、データベースは RDS Multi-AZ
各階層が 2 つの AZ に存在します。AZ が故障すると ALB は正常なマシンにのみ転送し、RDS は自動でフェイルオーバーします。

不正解: より大きなインスタンスに変更する
依然として 1 台のマシン、1 つの AZ です。

不正解: 別のリージョンにレプリカを構築する
1 つの AZ の喪失という要件には過剰で、コストも高くなります。

2社内システムで、リージョン全体の喪失時に RPO 24 時間、RTO 8 時間を許容できます。DR のコストを最小にしたいと考えています。

答えを見る

正解: Backup & restore：AWS Backup でバックアップを別のリージョンにコピーし、インフラは CloudFormation で記述する
RPO / RTO が時間単位なら、backup & restore で十分で最も安価です。

不正解: Warm standby
縮小版を常時稼働させるため、必要以上に高コストです。

3Aurora MySQL を使うアプリケーションで、リージョン喪失時に RPO 数秒、RTO 約 30 分が必要です。コストはできるだけ低くします。

答えを見る

正解: Pilot light：Aurora Global Database で DR リージョンへ複製し、アプリサーバーは IaC で用意するものの停止しておき、フェイルオーバー時に起動する
データは継続的に複製され (RPO は秒)、残りは起動するだけで済みます (RTO は数十分)。

不正解: 毎日のスナップショットによる backup & restore
RPO が最大 1 日になります。

不正解: Multi-site active/active
要件は満たせますが、コストがはるかに高くなります。

4リージョン喪失時に数分以内にサービスを再開する必要があります。最初は低い処理能力で稼働することを許容できます。

答えを見る

正解: Warm standby：DR リージョンで縮小版を稼働させ、Route 53 フェイルオーバーを使い、切り替え後に Auto Scaling で容量を増やす
すぐにトラフィックを受けられ、スケールアップするだけで済みます。

不正解: Pilot light
アプリサーバーが停止しているため、処理を始める前に起動と設定が必要です。

5グローバルなアプリケーションで RTO をほぼ 0 にし、アジアと欧州のユーザーを最寄りのリージョンから配信し、どこでもデータを書き込める必要があります。

答えを見る

正解: DynamoDB グローバルテーブルと Route 53 レイテンシールーティングによる multi-site active/active
すべてのリージョンで読み書きでき、リージョンが故障したら Route 53 がそのリージョンを除外します。

不正解: プライマリリージョンに書き込む Aurora Global Database
書き込みを受け付けるリージョンは 1 つだけです (他のリージョンは読み取り専用、または書き込みを転送)。

6セール時間帯に注文が殺到し、後段の処理システムが過負荷になって注文が失われます。

答えを見る

正解: Web とワーカーの間に SQS を置き、ワーカーを待機メッセージ数で Auto Scaling する
キューが注文を安全に保持し、ワーカーは処理能力に応じて処理し、バックログに合わせてスケールします。

不正解: ワーカーのインスタンスサイズを大きくする
やはり上限があり、負荷が低い時間帯にもコストがかかります。

7新しい注文ごとに、メール送信、在庫更新、分析の記録を同時に行う必要があります。1 つが失敗しても他に影響してはいけません。

答えを見る

正解: SNS トピックから 3 つの SQS キューへ送信し、受け手ごとに 1 つのキューを用意する
ファンアウト：各受け手が自分のコピーを受け取り、独立して処理・再試行します。

不正解: 3 つの受け手で 1 つの SQS キューを共有する
各メッセージは 1 つのコンシューマーだけが処理します。

8Auto Scaling がマシンを置き換えるたびに、ユーザーがログアウトされます。

答えを見る

正解: セッションを ElastiCache (または DynamoDB) に保存し、アプリケーションのマシンをステートレスに保つ
どのマシンでもセッションを読み取れます。マシンを増減してもユーザーに影響しません。

不正解: ALB で sticky session を有効にする
置き換えられたマシンではセッションが失われます。マシン間の負荷も偏ります。

9同じ読み取りクエリが繰り返されるため、リレーショナルデータベースが過負荷になっています。

答えを見る

正解: データベースの前に ElastiCache を置き (cache-aside)、必要に応じてリードレプリカを追加する
繰り返されるクエリはメモリから返され、データベースには書き込み負荷とまれなクエリだけが残ります。

不正解: ディスクの IOPS を増やす
クエリが繰り返される問題の解決にはなりません。

10API の呼び出し量が非常に不規則で、小規模なチームはサーバーを管理したくありません。

答えを見る

正解: API Gateway + Lambda + DynamoDB
0 まで自動でスケールし、リクエスト単位で課金されます。

不正解: 大きなインスタンスを常時稼働させる EC2 Auto Scaling
誰も呼び出さない時間にも料金がかかり、OS の管理も必要です。

早見表

何に耐える必要があり、どれだけ速く復旧する必要がありますか？

やりたいこと	使うもの
1 つの AZ の喪失	Multi-AZ：複数 AZ の ALB + Auto Scaling、RDS Multi-AZ · 図を見る
リージョンの喪失、RPO / RTO が時間単位、最も安価	Backup & restore (AWS Backup で別リージョンへコピー + IaC) · 図を見る
リージョンの喪失、RPO は秒、RTO は数十分	Pilot light · 図を見る
リージョンの喪失、RTO は数分	Warm standby · 図を見る
RTO がほぼ 0、グローバルに配信	Multi-site active/active · 図を見る
ピーク負荷で後段が過負荷になる	SQS + キューに応じてスケールするワーカー · 図を見る
1 つのイベントを複数の受け手が処理する	SNS → 複数の SQS (ファンアウト) または EventBridge · 図を見る
読み取りが遅く、データベースが過負荷	CloudFront / ElastiCache / DAX / リードレプリカ · 図を見る
負荷が不規則で、サーバーを管理したくない	サーバーレス：API Gateway + Lambda + DynamoDB · 図を見る
障害時も安全な、能動的な DNS フェイルオーバー	Application Recovery Controller + Route 53

落とし穴

HA と DR を混同する：Multi-AZ はリージョン全体の喪失には対応できません。
リージョン内の自動フェイルオーバーに RDS リードレプリカを選ぶ：それは Multi-AZ です。リードレプリカは読み取りのスケール用で、手動で昇格する必要があります。
Pilot light と warm standby を混同する：pilot light は処理を始める前にアプリサーバーを起動する必要があり、warm standby はすぐに処理できます。
IaC なしで backup & restore を行う：手作業での再構築では RTO に間に合いません。
active/active や継続的なレプリケーションがバックアップの代わりになると思い込む：削除または破損したデータもそのまま複製されます。
DR を定期的にテストしない：一度も実行したことのない計画では、RTO を満たせるか分かりません。
セッションをマシンの外に出す代わりに sticky session を使う。
同じイベントを複数の受け手が受け取る必要があるのに SQS キューを 1 つだけ使う：SNS / EventBridge によるファンアウトが必要です。
実際の処理量はキューの長さにあるのに、ワーカーを CPU でスケールする。
DNS フェイルオーバーが TTL に依存することを忘れる：切り替えのレイテンシーを低くし、DNS キャッシュに依存したくない場合は Global Accelerator を使います。
DR リージョンのサービスクォータを忘れる：スケールアップする段階になって上限が足りないことに気づきます。

このモジュールのサービス

変わりやすい数値 (AWS ドキュメントで確認済み)

Pilot light は、追加のリソースを起動するまでリクエストを処理できません。Warm standby は低い処理能力ですぐに処理でき、スケールアップするだけで済みます。 2026-10-16 確認 ↗
Aurora Global Database はセカンダリリージョンへ通常 1 秒未満のレイテンシーで複製し、セカンダリリージョンを 1 分未満で昇格できます。 2026-10-16 確認 ↗
DynamoDB グローバルテーブルはすべてのリージョンで読み取りと書き込みができ、同時書き込みは last writer wins (最後の書き込みが優先) の原則で解決されます。 2026-10-16 確認 ↗
AWS Elastic Disaster Recovery はブロックレベルで継続的にレプリケーションし、pilot light 戦略を使用します。 2026-10-16 確認 ↗
CloudFront のオリジンフェイルオーバーは、失敗したリクエストごとにセカンダリオリジンへ切り替えます。以降のリクエストは引き続きプライマリオリジンに送られます。 2026-10-16 確認 ↗
AWS Backup はバックアップを別のリージョンやアカウントにコピーしますが、スケジュールに従った自動復元は行いません。 2026-10-16 確認 ↗
Cloud Map を使うと、アプリケーションが API または DNS でリソースを検出でき、ヘルスチェックを有効にした場合は正常なリソースのみを返します。 2026-10-19 確認 ↗

このモジュールの問題を解く →