AWS Solutions Architect — 耐障害性の高いアーキテクチャの設計：練習問題79問

Step 1: 要件確認 — AZ 障害に対してユーザー影響を最小化するには、障害発生時に自動で別 AZ のインスタンスにトラフィックをリダイレクトでき、かつ需給に応じてインスタンスを起動/停止できる仕組みが必要です。

Step 2: AWS の機能照合 — Auto Scaling グループ（ASG）は複数の AZ を跨いでインスタンスを作成でき、ALB はターゲットのヘルスチェックにより不健康なインスタンスを自動で除外します。ASG と ALB を組み合わせることで、負荷に応じたスケールアウト/インと障害時の自動振替を実現します。クロスゾーンロードバランシングにより ALB は全 AZ のターゲットに均等に配信できます（ALB はデフォルトで有効）。

Step 3: 推奨実装と運用考慮 — ASG のサブネット設定で複数 AZ を指定し、ALB のターゲットグループのヘルスチェックを適切に設定します（HTTP/HTTPS ヘルスチェック、期待レスポンスコード、タイムアウト/間隔）。さらに、ASG の最小/最大/望ましいキャパシティを適切に設定し、CloudWatch アラームで AZ 障害やスケールイベントを監視します。 Trap: よくある誤解は「ALB を各 AZ ごとに用意すれば可用性が高くなる」と考えることですが、ALB はリージョン内で高可用を提供する設計になっており、ターゲットを跨いだ ASG と連携させることの方が簡潔で管理が容易です。 Why each wrong answer fails: - 選択肢2（ASG を AZ ごとに分割し ALB は単一 AZ に登録）: ALB を単一 AZ に限定すると、その ALB 自体が障害点となり高可用性を損ないます。ASG を分割すると管理が複雑になり、自動で別 AZ のキャパシティを使い切れない場合があります。 - 選択肢3（AZ ごとに ALB を用意して Route53 でラウンドロビン）: 複数 ALB を運用するコストと運用負荷が増え、DNS キャッシュのため即時切替が保証されない（短い RTO を必要とする場面では不利）上、ヘルスチェックとトラフィック移譲の挙動が複雑になります。 - 選択肢4（常時最大数の EC2 を確保）: 可用性は確保されるかもしれませんが、コスト効率が悪く、需要変動に対する柔軟性が低下します。ASG を使うことでコストと可用性のバランスをとりつつ、障害時に自動でリソースを拡張できます。 総括すると、ASG を複数 AZ に跨らせ ALB のヘルスチェックで不健康なターゲットを除外する構成が、可用性・パフォーマンス・コストの観点で最適です。

Step 1: 要件確認 — 静的ウェブサイトのデータ保護（変更履歴や誤削除の回復）とリージョン障害時の迅速な復旧を望んでおり、かつコスト効率も重視しているため、リージョン間の複製とオブジェクトのバージョニングが望ましい。

Step 2: AWS の機能照合 — S3 のバージョニングを有効にするとオブジェクトの過去バージョンが保存され、誤削除や上書きからの復旧が可能になります。クロスリージョンレプリケーション（CRR）はバージョン付きバケット間でオブジェクトを自動的に複製し、別リージョンに迅速にデータを保持できます。さらにライフサイクルポリシーを使って古いバージョンを Glacier などの低コスト階層に移行しつつ、復旧要件に合わせて保持期間を調整できます。

Step 3: 推奨実装と運用考慮 — バージョニングと CRR を有効化し、レプリケーション先バケットのアクセス制御（バケットポリシーやKMSキー）を設定してセキュリティを確保します。ライフサイクルで過去バージョンを低コスト層に移動し、費用対効果を高めます。復旧手順（別リージョンからの復元や CloudFront のオリジン切替など）をドキュメント化して定期的にテストします。 Trap: よくある誤解は「S3 は高耐久だから単一リージョンで十分」と考える点。S3 は高い耐久性を提供しますが、リージョン単位の災害（リージョン全体の問題）に対しては CRR のようなリージョン間対策が必要です。 Why each wrong answer fails: - 選択肢2（単一リージョン + 手動ダウンロード）: 手動運用は人為的ミスや遅延リスクが高く、復旧速度と自動化の観点で実用性が低い。継続的に最新状態を保つことが難しいため SLA を満たせません。 - 選択肢3（S3 標準のみで CloudFront を使わない）: CloudFront は可用性と遅延低減に有効であり、オフロードによりオリジンコストを削減できるケースもあります。単に CloudFront を使わないことはコスト最小化になるとは限らず、リージョン障害対策には寄与しません。 - 選択肢4（EBS に保存してスナップショット）: S3 はオブジェクトストレージとして静的サイトに最適化されています。EBS はブロックストレージであり、S3 の機能（静的ウェブホスティング、バージョニング、CRR）やコスト効率、可用性に劣る上、EBS スナップショットはボリュームレベルの操作で管理が複雑です。 結論として、バージョニング＋CRR＋ライフサイクルの組合せがコストと復旧性のバランスを最も良く満たします。

Step 1: 要件確認 — 最小RPO（頻繁なバックアップやレプリケーションが必要）と短いRTO（自動化された復旧手順、迅速なリストア、クロスリージョンの可用性）が求められている。自己管理DBだとデータ整合性（トランザクション整合）も考慮する必要がある。

Step 2: AWSのサービスと設計 — AWS BackupはEBSスナップショットのスケジューリング、ライフサイクル（オンプレミスより細かい保持管理）、クロスリージョンコピーをネイティブにサポートし、運用自動化とコンプライアンス管理が容易になる。さらに、必要に応じてデータベースレベルのレプリケーション（例えばMySQLのレプリケーション、Postgresのストリーミングレプリケーション）を組み合わせるとRPOをより短くできる。

Step 3: 実装手順と運用面 — AWS Backupでスケジュールとクロスリージョンコピーを設定し、S3のライフサイクルやコスト管理をする。データベースは可能ならリードレプリカやクロスリージョンレプリケーションを追加して、フェイルオーバー時のRTOを短縮する。復旧手順はRunbook化して自動化（CloudFormation、Lambda）しておく。 Trap: 試験の落とし穴は「スナップショット頻度を高めればそれだけでRPOが極小化される」と考える点。EBSスナップショットは増分で効率的でも、データベースの整合性を保証するためにはファイルシステムのフラッシュやトランザクションログの管理が必要で、単純な頻度アップだけでは不十分な場合がある。 Why each wrong answer fails: 1) EBSスナップショットを5分ごとに取得しクロスリージョンコピーするスクリプト — 頻度だけ見れば良さそうだが、自作スクリプトは運用監視やエラー処理、セキュリティ、コスト最適化が難しい。データ整合性（DBの一貫性）や大量のコピーによるコスト増も問題で、管理が煩雑になる。 3) AMIを毎日作成し重要時のみS3へ手動転送 — 日次ではRPOが大きすぎ、手動プロセスはRTOを長引かせる。AMIはインスタンスイメージでありDBのオンラインバックアップとしては不十分な点がある。 4) バックアップしないで手動復旧 — 最短のRPO/RTO要件を満たせず、ビジネス継続性リスクが非常に高い。運用上も不適。 総括: マネージドなAWS Backupと合わせてデータベースレプリケーションを組み合わせることで、クロスリージョン耐障害性、短いRTO、管理の自動化を実現できる。

Step 1: 要件評価 — RTO 5 分未満かつ RPO 1 分未満は、ほぼリアルタイムに近いレプリケーションが必要である。リージョン障害に耐える設計のためには、クロスリージョンでの高速レプリケーションと迅速な昇格手順が必須。コストと運用性も考慮する。

Step 2: AWS の選択肢比較と理由付け — RDS マルチ AZ はリージョン内の AZ 障害に対しては同期レプリケーションで RPO=0 に近いが、リージョン障害には対応しない（同一リージョン）。RDS クロスリージョン リードレプリカは非同期複製であり、レプリケーション遅延により RPO が 1 分を超える可能性がある。EBS スナップショットの別リージョンコピーは、復旧に時間がかかり（RTO が大きい）RPO も大きくなる。Amazon Aurora Global Database はリージョン間レプリケーションを非常に低遅延（通常 1 秒以下〜数秒）で行い、セカンダリリージョンを迅速に昇格できるため、厳しい RTO/RPO に適合する。

Step 3: 実装上の注意点と運用 — Aurora Global を使う場合、プライマリでの書き込みを継続しつつ、セカンダリはリード専用であること、フェイルオーバーの手順を自動化（または手順文書化）しておくこと、そしてクロスリージョン帯域とコスト（データ転送料金、リージョン間レプリケーションの影響）を考慮する。バックアップ、ポイントインタイム回復、監視（レプリケーション遅延のアラート）も設定する。 Trap: 試験での典型的な誤解は「RDS のクロスリージョンリードレプリカは多くのケースで十分だからコスト優先で選ぶべき」と考えること。非同期であるため、厳しい RPO を保証できない点を見落としやすい。 Why each wrong answer fails: - Amazon RDS マルチ AZ 配置（選択肢1）: マルチ AZ は同一リージョン内の AZ 障害に対して有効であり、RPO はほぼゼロだが、リージョン全体の障害（リージョン消失）には耐えられない。問題はリージョン障害が想定されているので不十分。 - RDS のクロスリージョンリードレプリカ（選択肢2）: クロスリージョンのリードレプリカは非同期レプリケーションを利用するためレプリケーション遅延が発生する可能性があり、RPO を 1 分以内に確実に保てる保証がない。フェイルオーバー時にデータロスが発生するリスクがある。 - EBS スナップショットの別リージョンコピー（選択肢4）: スナップショットベースのバックアップは復旧に時間がかかる（インスタンス起動、ボリューム復元、設定適用など）ため RTO が大きく、スナップ間隔によって RPO も大きくなる。コストは低めだがミッションクリティカル要件を満たさない。 総括: 要求される短い RTO/RPO を満たすには、低レイテンシのクロスリージョン複製と迅速な昇格が可能な Aurora Global Database が最も適している。コスト/運用上のトレードオフとしては、データ転送と追加リージョンの運用コストが発生する点を考慮する必要がある。

Step 1: 要件整理 — RPO=0 はデータ損失が許容されないことを意味し、リージョン障害時に読み取りやフェイルオーバーを迅速に実行したい。これは低遅延のリージョン間複製と、迅速なフェイルオーバーメカニズムが必要。

Step 2: AWS の実装観点 — Amazon Aurora Global Database は、あるリージョンのクラスターボリュームを別リージョンへほぼリアルタイムで複製する設計になっており、通常の非同期レプリケーションよりも非常に短いラグでデータを複製できるため、実務では RPO を極めて低く抑えやすい。さらに Aurora の設計は迅速なリードレプリカ利用とフェイルオーバー計画をサポートし、グローバルな読み取り性能の向上にも寄与する。

Step 3: 運用とコストのトレードオフ — Aurora Global はコストがかかるが、RPO=0 の厳しい要件を満たすための技術的な適合度が高い。実装では書込みレイテンシー、レプリケーションの確認、フェイルオーバー手順（自動／手動）と運用テストを行うことが重要。またセキュリティ（暗号化、IAM、VPC 設計）も設計に組み込む。 Trap: よくある誤解は「RDS のクロスリージョン Read Replica を作れば RPO=0 になる」と考えることです。クロスリージョン Read Replica は非同期レプリケーションであり、ラグが発生し得るためデータ損失ゼロを保証できない場合があります。 Why each wrong answer fails: - RDS のクロスリージョン Read Replica（選択肢1）: Read Replica は非同期での複製が基本であり、プロモーションが必要であるため瞬時のフェイルオーバーや RPO=0 を保証しない。データレプリケーションの遅延により最新データが失われるリスクがある。 - スナップショットを別リージョンに保存してリストア（選択肢3）: スナップショットは復旧に時間がかかる（RTO が長い）上、スナップショット取得間隔によっては RPO を満たさない。RPO=0 を達成するには不適合。 - オンプレに同期レプリケーションを残す（選択肢4）: オンプレとの同期レプリケーションは複雑でネットワーク遅延や運用負荷が高く、かつクラウドネイティブな高速フェイルオーバーを実現するのが難しい。さらに運用の複雑さとコストが増す。 総括すると、RPO=0 に極めて近い要件と迅速なリージョン間対応が必要な場合、Aurora Global Database のように設計上リージョン間複製を最適化しているサービスを選択するのが最も適切です。

Step 1: 要件整理 — グローバルな低遅延書き込み（各地域での書き込みを可能にする）、データ整合性の確保、運用のシンプルさを重視する。

Step 2: サービス評価 — DynamoDB Global Tables は複数リージョンに対してアクティブ-アクティブにテーブルを配置し、AWS が差分のレプリケーションとコンフリクト解決の基本を管理する。これにより各リージョンのユーザーに低遅延で読み書きを提供でき、運用面でのマネージド性が高い。RDS/Aurora のようなリレーショナルデータベースはマルチリージョンでのアクティブ書き込みに標準対応しておらず、運用や一貫性確保の負荷が高くなる。S3 はオブジェクトストレージであり頻繁な書き込みやリレーショナルデータの整合性に向かない。

Step 3: 実装とトレードオフ — DynamoDB Global Tables を採用すると SLA と可用性が高く、スケーリングも自動であるが、トランザクションの性質や二相コミット的な複雑な制約が必要なユースケースではアプリ設計を工夫する必要がある。コストはレプリケーションと読み書きキャパシティに依存するので、アクセスパターンを考慮して設計する。Trap: 飽くまで「全てのユースケースで DynamoDB が万能」と考えることは誤り。複雑なリレーショナル結合や ACID を跨る複雑トランザクションには別設計が必要。 Why each wrong answer fails: - RDS を各リージョンに配置しアプリ側で矛盾解消: 各リージョンで独立して書き込むアーキテクチャは整合性管理をアプリに強いるため、運用とテストが非常に複雑になりミスが発生しやすい。スキーマの同期やデータコンフリクト解消、オペレーション負荷が増加する。 - S3 のクロスリージョンレプリケーション: S3 はオブジェクトストアであり低レイテンシの同期書き込みやトランザクション整合性を提供しない。頻繁な書き込みや更新が発生するアクティブ-アクティブ構成には不向き。 - Aurora をプライマリに集中させ他リージョンは読み取り専用: これでは書き込みは単一リージョンに集中し、グローバルな低遅延書き込み要件を満たさない。DR や読み取りスケールには有効だが、アクティブ-アクティブの書き込み要件とは方向性が異なる。 総括: グローバルに分散したアクティブ書き込みと運用のシンプルさを両立したい場合は、DynamoDB Global Tables が堅実な選択です。アプリ要件（トランザクションの複雑さや整合性モデル）を踏まえた上で適切に設計してください。

Step 1: 要件整理 — RTO 1 時間、RPO 15 分は「短時間での復旧」と「ほぼリアルタイムのデータ保全」を要求します。従って、データレプリケーションはリアルタイムまたはほぼリアルタイム（数秒〜数分の遅延）で行う必要があります。また、ビジネスはグローバルであるためリージョン障害を想定したクロスリージョン対策が必要です。

Step 2: AWS の選択肢評価 — RDS のクロスリージョンリードレプリカは継続的レプリケーションにより RPO 短縮に有効で、フェイルオーバー時にレプリカを昇格させれば RTO を短縮できます（自動昇格のためには対応アーキテクチャや Route 53 を組み合わせた切替が必要）。アクティブ-アクティブ（例：DynamoDB グローバルテーブル）にすると、書き込みを複数リージョンで処理でき、RTO と RPO 双方を最小化できます。これらはコストは上がるが要件を満たす。

Step 3: 実装と運用考慮 — リードレプリカ＋Route 53 により構成変換時の検証・自動化（Lambda、Terraform で昇格手順の自動化）を行い、DB スキーマやアプリケーションの接続設定を冗長化します。アクティブ-アクティブへ移行する場合、整合性、コンフリクト解決、運用性（監視・運用手順）を確立します。コスト対効果を検討し、必要に応じてハイブリッド（重要なテーブルはグローバルテーブル、その他はレプリカ）を採用します。 Trap: 試験でよくある誤解は「Multi-AZ = クロスリージョン DR」を混同することです。RDS の Multi-AZ は同一リージョン内のスタンバイであり、リージョン障害時には機能しません。また、単にバックアップを S3/Glacier に取る方式（コールドスタンバイ）は RTO=1時間、RPO=15分 の要件には一般に不適です。 各選択肢の失敗理由： - RDS のクロスリージョンリードレプリカ（正解）: 継続的レプリケーションで RPO を短くでき、適切に自動化すれば RTO も短縮可能。グローバル障害に対する実用的な対策。 - RDS マルチ AZ（不正解）: 高可用性は提供するが「同一リージョン内」の冗長化であり、リージョン障害時の DR 対策にならない。CRR はオブジェクト用であり DB の RPO を直接改善しない。 - アクティブ-アクティブ（正解）: 最も低 RTO/RPO を実現可能。ただし運用とコストが増大するため、移行計画や整合性設計が必要。 - バックアップ/復元（コールドスタンバイ）（不正解）: スナップショット復元は復旧に時間がかかり RTO=1時間 を満たすのが難しい。RPO もスナップショット頻度に依存し、15 分は現実的でない。 まとめとして、厳しい RTO/RPO を満たすには継続レプリケーションまたはアクティブ-アクティブが必要で、試験トラップは「Multi-AZ を DR と誤認」することです。

Step 1: 要件整理 — RTO/RPO が 24 時間と緩やかでコスト最優先ということは、常時フル稼働する冗長性は過剰投資になります。優先度が低い処理なら、復旧の自動化と復旧手順の検証に重点を置きつつ、運用コストを抑える戦略が望ましいです。

Step 2: AWS の選択肢評価 — コールドスタンバイは最も低コストな方式で、AMI、Terraform、S3 に保存した DB スナップショットなどで復旧環境を保持します。日常の運用コストは低いですが、復旧時に構築・データ復元が必要になり、RTO は復旧手順の自動化レベルに依存します。パイロットライトはコールドスタンバイより早い復旧（RTO を短縮可能）で、最低限のインフラを稼働させるためコストも比較的低い。ウォームスタンバイやアクティブ-アクティブは常時リソースを稼働させるためコストが高く、今回の要件では不適切です。

Step 3: 実装と運用考慮 — コールドスタンバイでは起動手順（CloudFormation/Terraform、Bootstrapping、DB リストア）を自動化し、定期的に DR リハーサルを行って RTO 内に復旧できることを確認します。パイロットライトは最小限の DB レプリカやスタンバイインスタンスを常時維持し、障害時にオートスケールや Auto Scaling Group のユニットを増やして稼働状態へ切替える。コスト/運用のバランスを考え、どのデータを常時レプリケートするか（トランザクションログ、増分バックアップ）を決めます。 Trap: 試験での落とし穴は「低コスト＝バックアップだけで十分」と短絡することです。コールドスタンバイでも RTO を満たすための自動化が不十分だと復旧に時間がかかる可能性があります。また「パイロットライトは停止した状態」だと誤解する受験者もいますが、パイロットライトは最小限の稼働を維持する点が特徴です。 各選択肢の失敗理由： - コールドスタンバイ（正解）: コスト最小化に最も適合。RTO/RPO が 24 時間以内であれば受容可能。ただし復旧スクリプトや手順の自動化が必要。 - パイロットライト（正解）: コールドスタンバイより早く復旧可能で、コストも中程度。夜間バッチのような非クリティカルなワークロードに適している。 - ウォームスタンバイ（不正解）: 常時中程度のリソース稼働が必要でコスト増。今回の低優先度要件では過剰投資。 - アクティブ-アクティブ（不正解）: 可用性は最大だがコストと運用複雑度が非常に高く、24 時間 RTO/RPO の制約では不必要。 結論として、コスト最優先かつ緩い RTO/RPO のケースではコールドスタンバイとパイロットライトが適切で、実際の運用では自動化と定期リハーサルが重要です。

Step 1: 要件と優先順位の確認 — 対象は非クリティカル（開発環境）、RTO = 24 時間、RPO = 12 時間。コスト最小化が主要な目的であるため、常時稼働のリソースを極力減らした設計が望ましい。

Step 2: DR モデル比較 — AWS の代表的な DR 戦略には Backup & Restore、Pilot Light、Warm Standby、Multi-site Active-Active があります。Backup & Restore は最も低コストで、データおよび設定のバックアップを別リージョンに保存し、災害時にリストアして環境を復旧します。RPO を 12 時間にするためにはバックアップ頻度を 12 時間以内に設定すれば良く、RTO も 24 時間の目標ならスナップショットからの復旧で十分対応可能です。

Step 3: 実装とコスト最適化 — スナップショット（EBS/RDS）や S3 バックアップを自動化（AWS Backup 等）して別リージョンにコピーすることで、低コストかつ管理しやすいバックアップ運用を構築します。復旧手順（CloudFormation テンプレート、Automation runbooks）を用意しておくと、実際の復旧時に 24 時間以内で復旧可能です。コストと時間のバランスから見て、Pilot Light や Warm Standby はより短い RTO を実現する代わりに常時のコストが増えます。 Trap: よくある誤解は『より高い可用性は常に良い』という考えで、要件を超える Active-Active や Warm Standby を選んで不要なコストを発生させることです。必ず RTO/RPO とコスト目標を照らし合わせて適切な戦略を選びます。 Why each wrong answer fails: - Pilot Light（選択肢 2）: Pilot Light は核心となるサービス（データベース、ネットワーク設定等）を小規模で常時稼働させ、災害時にスケールアップして切り替える手法です。Backup & Restore より RTO が短くなる一方で、コア部分を常時稼働させるコストがかかり、今回の『コスト最小化』という要件には不適切です。 - Warm Standby（選択肢 3）: Warm Standby は縮小版の本番を常時稼働させるため、復旧時間は短縮されますが常時稼働コストがかなり高くなります。非クリティカルで 24 時間 RTO が許容される環境では過剰投資となります。 - Multi-site Active-Active（選択肢 4）: Active-Active は可用性や遅延分散の観点で優れるが、設計・運用・コストのすべてで最も高コストで複雑です。非クリティカルかつ緩い RTO/RPO 要件の開発環境には不相応です。

Step 1: 要件定義 — 要は「短時間のトラフィックスパイクに対応しつつコストを最小に抑える」こと。つまり瞬時の需要変動に対応できる自動化と、予測可能な負荷に対する事前準備の両方が必要です。

Step 2: 推奨戦略 — ALB の RequestCountPerTarget を用いたターゲットトラッキング（選択肢1）は、各ターゲット（EC2）あたりのリクエスト負荷を監視し、負荷が所定値を超えれば自動でスケールアウトし、低ければ縮小します。これにより過剰プロビジョニングを避けつつ、急激な負荷増にも自動応答できます。加えて、セールのように事前に時間が分かる場合はスケジュールドスケーリング（選択肢3）を設定してピーク前にインスタンスを追加しておくことで、起動遅延による初期のパフォーマンス問題を回避できます。

Step 3: 運用上の注意点とトレードオフ — ターゲットトラッキングはリアルタイム性が高く効果的だが、インスタンス起動時間やヘルスチェック時間を考慮してしきい値を調整する必要があります。スケジュールドスケーリングは余裕をもった開始時間を設定する（起動/ウォームアップ時間分前倒し）ことが重要です。両者を組み合わせることでコスト効率を保ちながらパフォーマンスを確保できます。 Trap: 試験での落とし穴は「単一の CloudWatch アラームで全てをカバーできる」と信じることや「最小キャパシティを極端に下げればコスト節約になる」と考える点です。実運用ではアラームベースのみでは応答が遅れる場合や、極端に低い最小インスタンス数はスパイク時のオーバーロードを招きSLA違反につながります。 Why each wrong answer fails: 1（正解）: ALB の RequestCountPerTarget を使うとロードバランサの視点で各ターゲットの負荷を反映した自動スケーリングが可能で、スパイクに良く対応できる。 2（誤り）: 単一のシンプルスケーリングポリシーに頼ってしきい値を高めにすると、スケールアウトの反応が遅れパフォーマンスに影響を与える。さらに単一ポリシーでは細かな需要パターンに追随しづらい。 3（正解）: 既知のセールやキャンペーンにはスケジュールドスケーリングを併用することで、起動遅延による初期のリソース不足を防げる。コストと安定性の両立に有効。 4（誤り）: 最小インスタンス数を極端に低くするとスケールアウトまでの時間でサービス性能が低下し、手動スケールはヒューマンエラーと遅延を招くため自動運用には不適。 総括: 短期スパイク対策には ALB 指標を用いたターゲットトラッキングと、予測可能な負荷にはスケジュールドスケーリングを組み合わせるのが最もバランスの良いアプローチ。

Step 1: 要件の把握 - RTO ≤ 30 分、RPO ≤ 15 分、かつコスト抑制が条件。つまり障害発生から短時間で復旧できる一方、常時のコストは最小化したい。Web 層がステートレスならウォームスタンバイや自動スケールを活用しやすい。

Step 2: 適切な DR パターン選択 - ウォームスタンバイ（オプション 1）: セカンダリリージョンに最小限のインスタンスを常時稼働させておくことで、障害時には既存のインスタンスをスケールアップしてトラフィックを受けられる。ウォームスタンバイはフルアクティブよりコストが低く、バックアップ＆復元より速い復旧を実現できるため、RTO 30 分に適合しやすい。 - 非同期クロスリージョン DB レプリカ（オプション 3）: DB のデータを別リージョンにもレプリケートしておけば、障害時にリードレプリカを昇格して DB を利用できる。非同期レプリケーションの遅延はあるが、適切な設計と監視で RPO ≤ 15 分を目指せる。昇格処理と DNS 切替を自動化すれば、RTO も短縮できる。

Step 3: 運用と自動化 - ウォームスタンバイと DB レプリカを組み合わせることで、アプリケーション層とデータ層の両方で迅速な切替が可能となる。Route 53 のフェイルオーバー、ALB/Target Group の更新、昇格スクリプト、CloudWatch アラートによる自動化を実装しておくこと。 Trap: よくある誤解 - 「ゼロ稼働（オンデマンドでフルデプロイ）ならコストゼロで最適」: COst は最小化できるが、フルデプロイと DB リストアには多くの時間がかかり、RTO ≤ 30 分を満たすのは非常に難しい。オンデマンドは RTO 要件が緩い場合に限る。 Why each wrong answer fails - オプション 2（ゼロ稼働で障害時にフルデプロイ）: CloudFormation によるフルデプロイや DB 復元にはデプロイ時間・スナップショット復元時間が発生し、通常は 30 分では完了しない。コストは低いが RTO 要件に合致しない。 - オプション 4（RDS Multi‑AZ のみで対応）: Multi‑AZ は同リージョン内での AZ 障害に対して有効だが、リージョン全体の障害に対しては機能しない。リージョン障害への対応を手動運用に頼るのは RTO ≤ 30 分の要件を満たす保証がない。 総括: コストを抑えつつ短い RTO/RPO を満たすには、アプリ層でウォームスタンバイを用意して即時スケールできる状態にしておき、DB 層はクロスリージョンレプリカでデータを保護するという組合せが現実的で実運用向けである。

Step 1: 要件の整理 — RTO < 1 時間、RPO < 15 分、グローバルユーザー。完全なアクティブ-アクティブは高コスト・高運用負荷だが、低遅延で可用性は高い。コストを抑えたい場合、アクティブ-パッシブやセカンダリを読み取りレプリカで保持する方式が現実的。

Step 2: AWS の機能評価 — RDS のクロスリージョン読み取りレプリカや Aurora の Global DB を用いれば、セカンダリにデータを複製できる。読み取りレプリカを維持しておき、フェイルオーバー時に昇格すればダウンタイムを短縮可能。Route 53 のフェイルオーバーとヘルスチェックで DNS レベルの切り替えを自動化する。一方、RDS マルチ AZ はリージョン内の AZ 冗長であり、リージョン障害に対する DR には無効。スナップショットからの復元は時間がかかり RTO 要件を満たさない。

Step 3: 運用とコストのバランス — セカンダリを読み取りレプリカとして維持することで、コストはアクティブ-アクティブより低く抑えられるが、RPO が 15 分を満たすためにはレプリケーション遅延を監視し、必要ならより頻繁な同期や Aurora のような高速レプリケーション機能を検討する。フェイルオーバー手順とスイッチオーバーテストを定期実施する。 Trap: よくある誤りは“RDS マルチ AZ があればリージョン障害もカバーできる”という認識。マルチ AZ はリージョン内の AZ 障害対策であり、リージョン全体の障害には無効である。 Why each wrong answer fails: 1) マルチリージョンのアクティブ-アクティブ（両リージョンで書き込み） — 可用性は高いが、データ整合性のためのアプリ側ロジックやコンフリクト解決が必要で運用コストが大きく、初期導入コストと複雑さが要件を超過する可能性が高い。 3) RDS マルチ AZ のみ — マルチ AZ はリージョン内の AZ 障害に有効だが、リージョン単位の障害や災害には対応できないため、RTO/RPO のリージョンレベル要件を満たさない。 4) 定期スナップショットからの復元 — スナップショット復元は時間がかかり、RTO < 1 時間、RPO < 15 分の要件を満たせない。コストは低いが可用性要件と整合しない。 総括: コストと RTO/RPO のバランスを取るなら、アクティブ-パッシブでセカンダリは読み取りレプリカとして維持し、必要時に昇格して Route 53 でフェイルオーバーする方式が最適である。