AWS SAA-C03 D2レジリエントアーキテクチャ｜DR4戦略・RTO/RPO・Auto Scaling試験対策

1. はじめに — D2レジリエントアーキテクチャ設計とは

本記事は「AWS SAA-C03 試験対策」シリーズの Vol2 です。
シリーズ全体の学習法・出題4ドメインの俯瞰は Vol0 ロードマップ をご参照ください。
D1「セキュアアーキテクチャ設計」を先に学びたい方は Vol1 からお読みください。

ここから扱うのは試験の第2ドメイン、D2「Design Resilient Architectures（レジリエントアーキテクチャ設計）」 です。
公式試験ガイド v1.1 における出題比率は 26% で、65問換算で約17問、SAA-C03 の4ドメインのうち D1（30%）に次ぐ2番目の比重を占める重要な出題分野です。

D2 で問われるのは「障害が起きても止まらないシステムをどう設計するか」という設計力です。
単なる AWS サービスの暗記では得点できず、どの構成がどの課題を解決するか という判断がすべての問題の核心になります。

1-1. D2の頻出サービス（実データ集計）

問題バンク400問の実データ集計によると、D2 では以下のサービスが頻出です。
試験準備では、これらを中心に重点的に学習することを推奨します。

Lambda・RDS・EC2 の3本柱が圧倒的に出現頻度が高い点に注目してください。
これらのサービスが絡む「どう耐障害化するか」というシナリオが D2 の中心をなします。

2. 疎結合アーキテクチャ — SQS・SNS・EventBridge

2-1. なぜ疎結合が必要か

密結合なシステムでは、コンポーネント A とコンポーネント B が直接 API で連携しています。
B が障害・過負荷で応答しなくなると、A も処理を止めざるを得ません。
疎結合の設計では間に メッセージキューやイベントバス を挟み、AとBを切り離します。
B が遅くても A の処理を止めず、B が復旧すれば溜まったメッセージを順次処理し始めます。

疎結合はスケーリングの面でも有効です。
A と B を独立してスケールできるため、ボトルネックになっている部分だけをスケールアウトできます。

2-2. SQS — キューによる非同期デキュー

Amazon SQS（Simple Queue Service） は、メッセージキューを提供するマネージドサービスです。
送信者（Producer）が SQS にメッセージを送り、受信者（Consumer）が独立したペースでメッセージを取り出して処理します。
メッセージが消えることなく永続化されるため、Consumer が一時的に停止しても処理を損失しません。

Standard キューと FIFO キューの違い

Standard キューはスループットが事実上無制限であるため、大量メッセージを高速処理したい場合に適しています。
FIFO キューは名前の通り「先入れ先出し」を厳密に保証するため、順序の整合性が求められる処理に使います。

可視性タイムアウト（Visibility Timeout）

Consumer がメッセージを取り出した後、一定時間（デフォルト30秒）は他の Consumer から見えなくなります。
この時間内に処理を完了してメッセージを削除しなければ、タイムアウト後にメッセージが再び見えるようになり、別の Consumer が再処理します。
処理に時間がかかる場合は、Consumer 側でタイムアウトを延長（ChangeMessageVisibility API）します。

DLQ（デッドレターキュー）

処理に何度も失敗したメッセージを別キューに隔離する仕組みです。
maxReceiveCount で最大再試行回数を設定し、超過すると DLQ へ自動転送されます。
DLQ をモニタリング・分析することで、処理できないメッセージの原因を特定して修正できます。
DLQ のメッセージ数を CloudWatch でアラーム監視することが推奨されます。

Long Polling

Short Polling は空のキューに対して即座に「空です」と返します。
Long Polling（最大 20 秒待機）はメッセージが届くまで待つため、空キューへのリクエスト数を大幅に削減できます。
「SQS のコストと CPU 使用率を下げたい」という問題では Long Polling（WaitTimeSeconds=20）が正解です。

2-3. SNS — Pub/Subとファンアウトパターン

Amazon SNS（Simple Notification Service） は、Pub/Sub（発行-購読）モデルのメッセージ配信サービスです。
Publisher がトピックにメッセージを発行すると、そのトピックを購読するすべての Subscriber に同時配信します。

ファンアウトパターン は、SNS トピックに複数の SQS キューを購読させる設計です。
たとえば「注文完了イベント」を SNS へ発行すると、在庫更新キュー・配送指示キュー・請求書発行キューが同時にメッセージを受け取ります。
新しい処理を追加する際も、既存の処理に影響を与えず購読を追加するだけで済むため、拡張性が非常に高い設計パターンです。

SNS は SQS・Lambda・HTTP エンドポイント・メール・モバイルプッシュなど多様な Subscriber をサポートします。
「1つのイベントを複数のシステムへ同時に通知したい」という要件では SNS + SQS のファンアウトパターンが定石です。

2-4. EventBridge — イベントバス

Amazon EventBridge は、AWS サービス・独自アプリ・外部 SaaS からのイベントを受け取り、設定したルールに基づいてターゲットへルーティングするイベントバスです。

EventBridge の最大の特徴は、AWS サービス間の連携を コードを書かずに設定だけで実現できる 点です。
たとえば「EC2 インスタンスが停止したら Lambda を呼び出して通知する」という処理を、ルール設定のみで実現できます。

「サービス間の連携を疎結合にしたい」「AWS サービスのイベントに反応して自動化したい」「外部 SaaS のイベントをトリガーにしたい」という設問では EventBridge が答えになるケースが多くあります。

3. Auto Scaling — 弾力性の実現

3-1. EC2 Auto Scaling の仕組み

EC2 Auto Scaling は、EC2 インスタンス数を需要に応じて自動的に増減させる仕組みです。
起動テンプレート（Launch Template） でインスタンスの設定（AMI・インスタンスタイプ・セキュリティグループ等）を定義し、Auto Scaling グループ（ASG） でスケーリングの上下限・ポリシーを管理します。

ASG には3つの容量設定があります。
– 最小サイズ（Min）: 常に維持される最低インスタンス数
– 希望するキャパシティ（Desired）: 通常時の稼働インスタンス数
– 最大サイズ（Max）: スケールアウトしても超えない上限

起動テンプレート vs 起動設定（Launch Configuration）

試験では「起動テンプレートを使う」ことが推奨される設計とされています。

「新機能が使いたい」「オンデマンドとスポットを組み合わせてコスト最適化したい」という場面では起動テンプレートを選択します。

3-2. スケーリングポリシーの種類

Auto Scaling には3種類のスケーリングポリシーがあります。それぞれの特徴と使い分けを整理します。

「シンプルに CPU 70% を維持したい」→ ターゲット追跡スケーリング
「特定の閾値ごとに大幅にスケールアウトしたい」→ ステップスケーリング
「毎朝9時に容量を事前に増やしたい」→ スケジュールスケーリング

3-3. ALB/NLB との統合 — ヘルスチェックと接続ドレイン

Auto Scaling と ALB（Application Load Balancer） を組み合わせることで、障害インスタンスへのトラフィックを自動的に停止できます。

• ヘルスチェック: ALB はターゲット（EC2インスタンス）に定期的にリクエストを送り、応答しない場合は「Unhealthy」と判定してトラフィックを自動停止します。Auto Scaling と連携させれば、Unhealthy なインスタンスを自動で終了・置換します。
• 接続ドレイン（Deregistration Delay）: スケールイン時に除外するインスタンスへの新規接続を停止しつつ、既存の接続が完了するまで待機します（デフォルト300秒）。既存セッションを切断せずに安全にインスタンスを縮退できます。

4. データベースの高可用性 — RDS・DynamoDB・Aurora

4-1. RDS Multi-AZ — 自動フェイルオーバー

RDS Multi-AZ は、プライマリインスタンスと別 AZ のスタンバイインスタンスとの間で 同期レプリケーション でデータを常時同期する構成です。
プライマリで障害が発生すると、自動フェイルオーバー によりスタンバイが新しいプライマリに昇格します。
フェイルオーバーには通常 1〜2 分かかり、アプリケーションは DNS の切り替えによって接続先が透過的に変わります。

Multi-AZ の重要な注意点: 読み取りオフロードには使えません。
スタンバイインスタンスは通常の読み取りリクエストには利用できません（フェイルオーバー専用のスタンバイ）。
「読み取り性能を向上させたい」という要件には 読み取りレプリカ を使います。

4-2. RDS 読み取りレプリカ — 読み取り負荷の分散

「レポート処理やダッシュボードの読み取りで DB が重い」→ 読み取りレプリカを追加してオフロード
「DB の障害でサービスが止まる」→ Multi-AZ で自動フェイルオーバー

この2つは 目的が全く異なる ため、試験では混同しないよう注意が必要です。

4-3. Aurora Multi-AZ — エンドポイントの種別

Amazon Aurora は MySQL/PostgreSQL 互換のマネージドデータベースで、ストレージレイヤーが複数 AZ にわたって自動的に6つのデータコピーを維持します。
Aurora では複数のエンドポイントを使い分けます。

Aurora のフェイルオーバー時間は標準 RDS より短く（通常30秒以内）、ストレージ自体が高可用性を持つ設計のため、より高い可用性が求められる場面で Aurora が推奨されます。

4-4. DynamoDB — グローバルテーブルと DAX

DynamoDB グローバルテーブル は、複数の AWS リージョンにテーブルを自動的にレプリケートする機能です。
各リージョンでの読み書きが可能な マルチリージョン・マルチアクティブ 構成を実現します。
グローバルサービスで各地域のユーザーへのレイテンシを下げつつ、リージョン障害に備えることができます。

DAX（DynamoDB Accelerator） は、DynamoDB の前段に置くインメモリキャッシュです。
読み取りレイテンシをミリ秒単位からマイクロ秒単位に短縮でき、読み取り集中型ワークロードのスループットを大幅に向上させます。
DAX を使っても、アプリケーション側のコード変更はほぼ不要（DynamoDB クライアントを DAX クライアントに切り替えるだけ）です。

TTL（Time to Live） は、期限切れアイテムを自動的に削除する機能です。
セッションデータ・一時データの管理コストを削減でき、容量とコストを節約したいシナリオで有効です。

5. DR戦略4パターン — RPO/RTOによる選択

5-1. RPO と RTO の定義

DR（ディザスター・リカバリー）設計を理解するには、まず2つの重要指標を押さえます。

• RPO（Recovery Point Objective: 目標復旧時点） — 「どの時点のデータまで失って許容できるか」という許容データ損失量。例: RPO=1時間 → 直近1時間分のデータ損失まで許容できる。
• RTO（Recovery Time Objective: 目標復旧時間） — 「障害発生から何時間以内にサービスを復旧させるか」という目標時間。例: RTO=4時間 → 4時間以内に復旧しなければならない。

RPO が短いほどデータ損失が少なく（より安全）、RTO が短いほど早く復旧できます。
しかし、どちらも短くするほどコストが上がります。事業要件とコストのバランスで適切なパターンを選択します。

5-2. DR戦略4パターン

DR 戦略は RPO/RTO と費用のトレードオフで4パターンに分類されます。

Backup & Restore（バックアップ＆リストア）

最もシンプルで安価な DR 手法です。
S3 へのスナップショット・AWS Backup による定期バックアップを取得し、障害時はリストアします。
コストは最小ですが、RPO/RTO が大きい（データ損失と復旧時間が長い）ため、ビジネスクリティカルではないシステムや、長い停止を許容できるシステムに適しています。

Pilot Light（パイロットライト）

常にサービス提供に必要なコアコンポーネント（データベース等）だけを DR 先で稼働させておき、障害時に残りのリソース（EC2・ALB 等）を起動する手法です。
灯油ストーブの「パイロットライト（点火用の小さな炎）」が常に燃えている状態からの名前です。
RDS のレプリケーションや S3 へのデータ同期は常時実施するため、RPO は短く保てます。
ただし障害時にサーバーリソースを起動するため、RTO は数十分〜時間単位になります。

Warm Standby（ウォームスタンバイ）

本番の縮小版（最小構成）を DR 先リージョンで常時稼働させておく手法です。
本番ほどのキャパシティはありませんが、システム全体が動いているため、障害時はスケールアップ（インスタンス数・サイズ増加）のみで対応できます。
Pilot Light より RTO が短く、Active-Active より低コストです。
「数分以内に復旧したいが Active-Active ほどコストをかけられない」という要件に適しています。

Active-Active（アクティブ-アクティブ）

複数リージョンで完全稼働し、通常時から負荷を分散するマルチリージョン構成です。
Route 53 で両リージョンにトラフィックを分散し、一方のリージョンが完全停止しても他のリージョンが即座にすべてのトラフィックを引き受けます。
コストは最高ですが、RPO・RTO ともにほぼゼロを実現できます。
「ダウンタイムゼロが事業要件」「グローバルユーザーへの最小レイテンシが必要」という場合に選択します。

5-3. Elastic Disaster Recovery（DRS）

AWS Elastic Disaster Recovery（DRS） は、オンプレミス・AWS・他クラウドのシステムを AWS へ DR するマネージドサービスです。
継続的なブロックレベルレプリケーション により RPO は秒単位、フェイルオーバーにより RTO は分単位を実現します。
「従来のバックアップ・リストアから DRS に移行して RTO を大幅に改善したい」というシナリオで頻出です。
フェイルバック（AWS から元環境への戻し）もサポートしています。

6. Route 53 — フェイルオーバーとルーティング

6-1. ヘルスチェックの種類

Route 53 ヘルスチェック は、エンドポイントの死活を監視する機能です。
ヘルスチェックの結果を DNS フェイルオーバーと連動させることで、障害時の自動切り替えを実現します。

Endpoint ヘルスチェックは世界各地の Route 53 ヘルスチェッカーからリクエストを送信します。
「エンドポイントのヘルスが特定のリージョンのユーザーからは正常に見えるが、別のリージョンからは異常」というケースで Calculated ヘルスチェックが有効です。

6-2. フェイルオーバールーティング

フェイルオーバールーティング は、Active-Passive 構成 での自動切り替えを実現します。
プライマリリソースのヘルスチェックが失敗すると、自動的にセカンダリ（フェイルオーバー先）へトラフィックが切り替わります。
「東京リージョンに障害が発生した際、大阪リージョンへ自動切替」という構成がこれに当たります。

フェイルオーバールーティングには プライマリ と セカンダリ の2つのレコードを設定します。
プライマリのヘルスチェックが失敗している間は、セカンダリへのルーティングが有効になります。

6-3. 主要ルーティングポリシー

7. Lambda・Fargate の耐障害設計

7-1. Lambda の同時実行制限

Lambda は同時実行数（Concurrency）に制限があります。
デフォルトではアカウント・リージョン単位で 1,000 が上限です（引き上げ申請可能）。

• 予約同時実行（Reserved Concurrency） — 特定の Lambda 関数に専用の同時実行数を確保します。他の関数に使われても、この関数用の枠は必ず確保されます。重要な関数のスロットリングを防ぎたい場合に設定します。逆に、特定の関数の実行数に上限を設けたい場合にも使います。
• プロビジョニング同時実行（Provisioned Concurrency） — コールドスタートをなくすために事前から実行環境を温めておく機能です。最初のリクエストでも即座に応答できるため、レイテンシが重要な関数（API バックエンド等）で有効です。コストは上がりますが、一定のパフォーマンスを保証できます。

7-2. Lambda のエラーハンドリングと DLQ

Lambda の非同期呼び出しでは、処理失敗時に自動的に再試行します（最大2回・合計3回の試行）。
最終的に失敗した場合は DLQ（Dead Letter Queue） に移動させることができます。
SQS または SNS を DLQ として指定します。

また、Lambda Destinations（送信先） は成功・失敗の結果をそれぞれ別の送信先（SNS/SQS/EventBridge/別Lambda）へ転送する機能で、DLQ より詳細な制御が可能です。
「成功時は A へ、失敗時は B へ」という分岐を設定でき、ワークフローの柔軟性が増します。

7-3. Fargate — ECS との組み合わせ

AWS Fargate は、ECS/EKS でコンテナを実行するサーバーレスコンピューティングエンジンです。
EC2 インスタンスの管理が不要で、タスク単位で起動・停止します。
OS パッチ適用・インスタンス管理の手間がなくなり、アプリケーションの開発に集中できます。

ECS Service Auto Scaling を使うと、CPU 使用率やカスタムメトリクスに基づいてタスク数を自動調整できます。
マルチ AZ 配置 により、1つの AZ に障害が発生しても他の AZ でタスクが継続稼働します。

8. Step Functions — ワークフロー耐障害化

8-1. Standard vs Express Workflow

AWS Step Functions は、複数の Lambda 関数や AWS サービスをステートマシンとして連携し、複雑なワークフローを管理するサービスです。
視覚的なフロー図で処理の進行状況を確認できるため、デバッグが容易です。

「注文処理・人間の承認フロー・複数日にわたるバッチ処理」→ Standard Workflow
「IoT センサーデータの高頻度処理・5分以内のマイクロサービス連携」→ Express Workflow

8-2. エラーハンドリング — Retry と Catch

Step Functions の各ステートに Retry と Catch を設定できます。

• Retry: エラー発生時に自動的に再試行します。MaxAttempts・IntervalSeconds・BackoffRate で詳細に制御できます。たとえば「Lambda のスロットリングエラー時は指数バックオフで3回まで再試行」といった設定が可能です。
• Catch: 再試行しても失敗した場合に、別のステート（エラーハンドリング用のステート）へ遷移させます。エラーの種類ごとに異なるハンドリングを設定できます。

この仕組みにより、個々の Lambda はシンプルな処理ロジックだけを持ち、ワークフロー全体のエラー処理を Step Functions に集約できます。

8-3. Wait / Callback パターン

Wait for a Callback（.waitForTaskToken） パターンは、外部システムや人間の承認を待つ長時間タスクを実現します。
Step Functions がタスクトークンを発行し、処理を開始した後にワークフローを一時停止します。
外部システムや人間が処理を完了したら、そのトークンを使って Step Functions に結果を送信し、ワークフローが再開します。

たとえば「人間の承認が必要なドキュメントワークフロー」では、承認依頼メール送信後にワークフローを停止し、承認者がリンクをクリックしたタイミングでトークンを送信して処理が再開します。
最長1年間待機できるため、長期にわたるビジネスプロセスにも対応できます。

9. CertTrend LMS D2問題演習

SAA-C03 の D2 は、D1（セキュア）と並んで試験の最重要ドメインです。
本記事でD2の体系的な知識を身につけたうえで、問題演習による定着を図ることが合格への近道です。
CertTrend LMS では SAA-C03 の 400 問（D2 は 104 問）をドメイン別・難易度別に演習できます。

問題演習で重点的に確認するポイントを以下に示します。

• SQS/SNS の使い分け: キュー型（SQS）vs Pub/Sub型（SNS）の使い分け・ファンアウトパターン
• Multi-AZ と読み取りレプリカの混同: 目的（可用性 vs 性能）とレプリケーション方式の違い
• DR パターンの RPO/RTO 基準: 4パターンをコスト・復旧目標で瞬時に選択できるか
• Route 53 ルーティングポリシーの選択: シナリオ別に適切なポリシーを選べるか
• Lambda vs Fargate vs EC2 の使い分け: 実行時間・環境・コストの観点から選択できるか

問題演習では、単に正誤を確認するだけでなく「なぜその選択肢が正解で、他の選択肢はなぜ不正解か」を解説から読み解くことが重要です。
D2 の問題は設計判断の問題が多いため、消去法と原則の組み合わせで確実に得点を積み上げましょう。

10. 実務で深掘り — DR・レジリエンス本番運用記事

SAA-C03 の試験対策では広く体系的に理解することが重要ですが、実際の設計・構築では更に深い知識が必要です。
試験合格後の本番運用に向けた深掘りとして、関連する実践記事もご活用ください。

試験対策シリーズの次の記事では、D3「高性能アーキテクチャ設計」（24%/96問）を解説します。
S3 の転送高速化・CloudFront・ElastiCache/DAX・Aurora リードレプリカ・Kinesis・Athena/Redshift といった高性能化のサービス群を体系的に整理します。