SAP-C03 · LESSON 4
レジリエンス・移行・事業継続15% · 4項目
依存関係を整理して移行の単位を決め、データ同期と切り戻し条件を明確にします。RPO は失えるデータ量、RTO は戻すまでの時間として合意し、DR 方式を選びます。バックアップの存在だけで復旧可能とせず、別環境への復元・切替・整合性を訓練で確認します。
4.1移行と復旧を実測で証明する
移行と復旧を実測で証明する
概念
依存関係を整理して移行の単位を決め、データ同期と切り戻し条件を明確にします。RPO は失えるデータ量、RTO は戻すまでの時間として合意し、DR 方式を選びます。バックアップの存在だけで復旧可能とせず、別環境への復元・切替・整合性を訓練で確認します。
仕組み・手順
- 要件と成功条件を先に書き出す。
- 検証環境で操作し、成功・失敗の証跡を残す。
- 結果を確認してから、下の分野別練習で判断を確かめる。
業務での例
復元したシステムで主要取引を実行し、実測 RPO/RTO を記録する。
紛らわしい点・試験の注意
- 模試の正答率は公式スコアに換算できません。実環境の仕様も公式資料で確認してください。
ミニクイズ
Q1. RPO と RTO の説明として誤っているものはどれか。
- RPO は、障害が起きてからシステムが復旧するまでにかかる時間の目標である
- RPO と RTO を短くするほど、一般に DR の仕組みの費用は高くなる
- RPO は、許容できるデータの損失を、どの時点まで戻れればよいかという時間で表したものである
- RTO は、サービスが停止してから復旧するまでに許容できる、最大の時間の目標である
答えと解説を見る
正解：A RPO は、障害が起きてからシステムが復旧するまでにかかる時間の目標である
RPO は「どの時点までのデータを取り戻せればよいか」（データ損失の許容）、RTO は「どれだけの時間で復旧するか」。説明が逆になっている。
Q2. DMS で移行中、CDC の遅延（レイテンシー）が増え続けて追いつかない。次に行うべきこととして最も適切なものはどれか。
- LOB の列の設定を完全な LOB モードに変え、データの欠けを防ぐ
- 移行先の DB のインスタンスを大きくし、書き込みを速くする
- タスクを全量ロードからやり直し、CDC の開始の位置を新しくする
- レプリケーションインスタンスの CPU・メモリなどを確かめ、必要なら大きいクラスに変える
答えと解説を見る
正解：D レプリケーションインスタンスの CPU・メモリなどを確かめ、必要なら大きいクラスに変える
CDC の遅延は、レプリケーションインスタンスの資源不足や、移行先の書き込み性能、タスクの設定などが原因になる。メトリクスで原因を特定して対処する。 【他の選択肢】やり直しは原因を確かめずに時間がかかる。移行先の性能も原因になりうるが、まずメトリクスで確かめる。完全な LOB モードは遅くなりやすい。
参考リンク
4.2信頼性とレジリエンスに優れたアーキテクチャを設計する
概念
組織の重要なシステムは、RTO・RPO に応じた DR 戦略（バックアップと復元・パイロットライト・ウォームスタンバイ・マルチサイト）と、リージョン間のレプリケーション（Aurora グローバルデータベース・DynamoDB グローバルテーブル・S3 クロスリージョンレプリケーション）で設計します。AWS Elastic Disaster Recovery はサーバーの継続的なレプリケーションで、低コストで短い RPO を実現します。
仕組み・手順
- システムごとに RTO・RPO を決め、重要度で分類する
- 重要度に合う DR の戦略を選ぶ
- データはリージョン間で継続的にレプリケーションする
- Route 53 の ARC（Application Recovery Controller）などで切り替えを制御する
- DR の訓練を定期的に行う
業務での例
オンプレミスの重要サーバー 50 台を Elastic Disaster Recovery で AWS に継続的に複製し、災害時は数分で起動する。普段は軽量のステージング領域だけを動かす。
紛らわしい点・試験の注意
- Elastic Disaster Recovery はステージングの費用だけで、復旧時に本番の容量を起動する
- グローバルデータベースのセカンダリは読み取り専用（切り替えで昇格）
- DR の手順は訓練しないと、実際には動かないことがある
ミニクイズ
Q1. DR の訓練で大阪リージョンへの切り替えを行ったところ、EC2 の起動が途中で失敗した。原因はリージョンのサービスクォータ（上限）だった。次に行うべきこととして最も適切なものはどれか。
- 災害が起きたら、その時点で AWS サポートに連絡してクォータを引き上げてもらう運用にする
- DR 先のインスタンスタイプを最小のものに変え、クォータの範囲内で起動できるようにしておく
- 本番の規模に必要なクォータを確認し、DR 先のリージョンで事前に引き上げを申請しておく
- クォータの制限がない別のクラウドを DR 先にして、訓練は今後行わないことにする
答えと解説を見る
正解：C 本番の規模に必要なクォータを確認し、DR 先のリージョンで事前に引き上げを申請しておく
サービスクォータはリージョンごと・アカウントごとに決まっている。DR 先でも本番の規模で起動できるよう、事前に引き上げておき、訓練で確認する。
Q2. 担当者の誤った一括更新で DynamoDB のテーブルのデータが壊れた場合に、壊れる直前の状態に戻せるようにしたい。最も適切な方法はどれか。
- グローバルテーブルで別のリージョンに複製しておき、壊れたデータの複製から元に戻すようにする
- ポイントインタイムリカバリ（PITR）を有効にし、保持期間内の任意の時点に復元できるようにする
- DynamoDB Streams を無効にして、更新が他のテーブルに伝わらないようにしておくことで備える
- テーブルの読み書きのキャパシティを大きくして、更新の処理をできるだけ速く終わらせるようにする
答えと解説を見る
正解：B ポイントインタイムリカバリ（PITR）を有効にし、保持期間内の任意の時点に復元できるようにする
PITR は保持期間内の任意の時点の状態に、新しいテーブルとして復元できる。グローバルテーブルは誤った更新もすぐに複製するため、誤操作の対策にはならない。
参考リンク
4.3事業の継続性を確保するソリューションを設計する
概念
事業の継続性は、バックアップ（AWS Backup のクロスリージョン・クロスアカウントのコピー、ボールトロック）と、マルチリージョンの構成で確保します。Aurora グローバルデータベースは 1 秒未満の RPO と 1 分程度の RTO を目標にでき、DynamoDB グローバルテーブルはマルチリージョンのアクティブ/アクティブの書き込みが可能です。
仕組み・手順
- 重要なデータのバックアップを別のアカウント・リージョンにコピーする
- ランサムウェア対策に AWS Backup のボールトロックで削除を防ぐ
- 短い RPO が必要な DB は Aurora グローバルデータベースにする
- マルチリージョンの書き込みが必要なら DynamoDB グローバルテーブル
- 切り替えの手順を自動化し、訓練する
業務での例
EC サイトの注文 DB を Aurora グローバルデータベースにし、主リージョンの障害時はセカンダリを昇格させて 1 分ほどで書き込みを再開する。
紛らわしい点・試験の注意
- 同じアカウントにだけバックアップを置くと、アカウントの侵害で失う
- グローバルテーブルは最後の書き込みが優先される（競合の解決）
- バックアップの復元も定期的に試す
ミニクイズ
Q1. 新しく作られる EBS・RDS も含めて、バックアップの対象から漏れないようにしたい。最も運用の負荷が小さい方法はどれか。
- バックアップは障害が起きたときに取ればよいので、新しいリソースは特に対象に含めないでおく
- AWS Backup のバックアッププランをタグで割り当て、決まったタグの付いたリソースを自動で対象にする
- 新しいリソースを作るたびに、担当者がバックアップの台帳に追加し、手作業でスナップショットを取る
- 月に一度、全アカウントのリソースの一覧を出力して、バックアップの漏れがないか目で確認する
答えと解説を見る
正解：B AWS Backup のバックアッププランをタグで割り当て、決まったタグの付いたリソースを自動で対象にする
AWS Backup のリソースの割り当てでタグを条件にすると、タグの付いた新しいリソースも自動的にバックアップの対象になる。タグポリシーでタグの付け忘れも防げる。
Q2. DR の構成を用意しただけでは RTO を満たす証拠がない。次の作業はどれか。
- 監視アラームの通知先を削除する
- 復旧訓練で切替とデータ整合性を実測
- 構成図に RTO の数値を書き込むだけ
- 本番バックアップの保持期間を無期限にする
答えと解説を見る
正解：B 復旧訓練で切替とデータ整合性を実測
実際の復旧手順と依存関係を検証し、所要時間を測って改善します。
参考リンク
4.4信頼性を向上させる戦略を決定する
概念
既存のシステムの信頼性の改善では、単一障害点（単一 AZ・単一インスタンス・単一の接続）を見つけて冗長化し、AWS Fault Injection Service（FIS）で障害を意図的に起こして耐性を確かめます（カオスエンジニアリング）。AWS Resilience Hub で RTO・RPO の目標に対する評価もできます。
仕組み・手順
- 構成を見直し、単一障害点を洗い出す
- Resilience Hub で目標の RTO・RPO を満たすか評価する
- 冗長化（マルチ AZ・Auto Scaling・Direct Connect の 2 本化）を行う
- FIS で AZ の障害やインスタンスの停止を試し、復旧を確認する
- 結果から手順と構成を改善する
業務での例
FIS で 1 つの AZ のインスタンスを停止する実験を行い、Auto Scaling が別の AZ で台数を補うまでに 5 分かかることを確認して、最小の台数を見直す。
紛らわしい点・試験の注意
- FIS の実験は停止条件（CloudWatch のアラーム）を設定して安全に行う
- 冗長化しても、切り替えを試していなければ信頼性は保証されない
- Resilience Hub は評価と推奨、FIS は実際の障害の注入
ミニクイズ
Q1. 本番に近い環境で、AZ の障害やインスタンスの停止が起きたときに、自動復旧の仕組みと手順が本当に働くかを確かめたい。最も適切な方法はどれか。
- AWS FIS で障害を意図的に起こす実験を計画し、停止条件を決めて影響を観察する
- 障害は起きないものと考えて、自動復旧の仕組みは設計書の確認だけで十分とする
- 本番の環境で、予告なしに担当者がインスタンスを手作業で次々と停止して確かめる
- 過去に一度も障害が起きていないことをもって、仕組みが正しく働くと判断しておく
答えと解説を見る
正解：A AWS FIS で障害を意図的に起こす実験を計画し、停止条件を決めて影響を観察する
AWS FIS は障害の注入を実験として管理し、停止条件（アラーム）で安全に止められる。復旧の仕組みと手順を実際に確かめるのに使う。
Q2. 既存の構成の単一障害点（SPOF）をなくしたい。3 つの AZ のプライベートサブネットが、すべて AZ-a にある1つの NAT ゲートウェイを経由してインターネットに出ている。最も適した対策はどれか。
- Direct Connect を別のロケーションで冗長化する
- ファイルを Amazon EFS に移す
- NAT ゲートウェイを AZ ごとに配置する
- RDS をマルチ AZ 配置にする
答えと解説を見る
正解：C NAT ゲートウェイを AZ ごとに配置する
NAT ゲートウェイはその AZ の中で冗長化されているが、AZ の障害には耐えられない。各 AZ に NAT を置き、その AZ のサブネットから向ける。
参考リンク
レッスンは当サイトがAWS 認定の公式ページと公式試験ガイドをもとに独自に作成したもので、試験の内容を保証するものではありません。製品の仕様は変わることがあるため、参考リンク先の最新情報を確認してください。
ご利用上の注意（非公式・独自問題・合格保証なし）
- 本サイトの問題は、公式に公開されているスキル概要・試験ガイドをもとに当サイトが独自に作成した練習問題であり、実際の試験問題ではありません。
- Amazon Web Services、AWS、および関連するマークは、米国その他の国における Amazon.com, Inc. またはその関連会社の商標です。本サイトは AWS（Amazon Web Services）と提携しておらず、AWS による承認・推奨を受けたものではありません。
- 本コンテンツは学習の補助であり、合格を保証するものではありません。試験の内容・形式・前提条件は予告なく変更されます。受験前に必ず公式ページで最新情報を確認してください。
- 本模擬試験の正答率は、公式試験の換算（スケール）スコア（合格 720）とは換算できず、合否を予測するものではありません。
- 未ログイン時の進捗はこのブラウザ内（localStorage）に保存します。Google でログインすると学習記録をアカウントに同期します。端末内の記録とサーバー上の記録は別に削除します。詳しくは保存・同期の説明とCookie・保存設定をご確認ください。