Disaster Recovery Strategyを再評価する

ゴール

DRを最初から設計し直すのではなく、

現在のRTO / RPO
+
現在のDR構成
+
以前取得した評価結果
+
評価後に発生した変更

を比較し、

以前の証拠をそのまま利用できる

一部だけ再評価が必要

DR戦略そのものの見直しが必要

のどれに該当するか判断できるようにします。

1. 再評価の基準日は「最後に証明した時点」

DR戦略を再評価するときは、まず、

最後に現在のDR能力を
有効に証明できたのはいつか

を確認します。

例えば、

2025年

RTO = 60分
RPO = 15分

復旧テスト
RTO = 42分
RPO = 8分

だったとします。

この結果から証明できるのは、

その時点の要件
+
その時点の構成

に対してDR戦略が成立していたことです。

その後の変更まで自動的に保証するものではありません。

2. 以前の証拠が今も有効かを確認する

再評価では、

以前の復旧テスト結果があるか

だけではなく、

その結果を取得した後に
何が変わったか

を確認します。

例えば、

以前の復旧テスト
↓
成功

その後
↓
認証基盤を変更
新しい外部依存サービスを追加
データ構成を変更
ワークロード規模が大幅に増加

しているなら、以前のテスト結果が現在構成をすべて証明しているとはいえません。

重要なのは、

テスト結果が古い

という日付だけではなく、

その後の変更が
以前証明した復旧経路へ影響するか

です。

ワークロード規模の増加も、この「評価後に発生した変更」の一例として扱います。

3. 要件変更は以前の合格判定を無効にすることがある

構成が変わっていなくても、RTO / RPOが変われば再評価が必要です。

例えば、

以前

RTO = 60分
RPO = 15分

実績

RTO = 40分
RPO = 8分

なら、以前は目標達成です。

しかし現在の要求が、

RTO = 15分
RPO = 2分

へ変更された場合、

構成変更なし
+
以前は合格

でも、現在要件を満たしている証拠にはなりません。

つまり、

同じDR構成
≠
同じ評価結果

です。

評価基準そのものが変われば、現在の基準で再評価します。

4. 変更がどの復旧経路へ影響するかを対応付ける

すべての変更がDR全体を無効にするとは限りません。

例えば、

認証サービスを変更

した場合、

フェイルオーバー後
↓
利用者が復旧環境へログイン

する経路には影響する可能性があります。

一方、その変更が、

復旧環境から通常環境へ戻す
データ同期経路

に影響しないなら、以前のフェイルバック評価の一部は引き続き利用できる可能性があります。

したがって、

変更あり
↓
全部最初から再テスト

と機械的に判断するのではなく、

変更
↓
影響する復旧経路
↓
無効になった評価証拠

を対応付けます。

5. 「変更された部分」と「証拠が古くなった部分」を対応付ける

再評価では次のように整理できます。

ポイントは、

変更そのもの

と、

その変更によって
何の証拠が無効になったか

を分けることです。

6. フェイルオーバーとフェイルバックの証拠を別々に扱う

DR戦略全体に変更があっても、

フェイルオーバーの証拠

と、

フェイルバックの証拠

が同じタイミングで無効になるとは限りません。

例えば、

データベース構成変更
↓
変更後にフェイルオーバーテスト実施
↓
成功

しかし
フェイルバックテストは変更前が最後

なら、

フェイルオーバー
→ 現在構成で証明済み

フェイルバック
→ 現在構成では未証明

と整理します。

DRテストをしたことがある

という一括評価ではなく、

現在構成について
どの経路まで証明済みか

を確認します。

7. DRギャップは「現在要求」と「現在有効な証拠」の差から探す

再評価では、

以前成功したか

ではなく、

現在の要求

と、

現在も有効な証拠

を比較します。

例えば、

現在RTO
20分

最後に有効な実測
18分

で、その後に復旧経路へ影響する変更がなければ、既存証拠を利用できる可能性があります。

一方、

実測18分
↓
その後アプリケーション構成変更
↓
変更後の復旧時間未測定

なら、

現在RTOを満たしていることを
現在証明できていない

こと自体がDRギャップです。

8. 「未達」と「未証明」を区別する

再評価では、この2つを混同しません。

未達
=
現在の評価結果が
目標を超えている

一方、

未証明
=
以前は目標を満たしたが
その後の変更により
現在も満たすことを証明できない

です。

例えば、

RTO 15分

最新実測
22分

なら明確な未達です。

一方、

以前の実測
10分

その後
復旧経路を変更

変更後テストなし

なら、

15分を超えると判明した

わけではありません。

しかし、

現在も15分以内

という証拠が失われています。

この未証明状態もDRギャップとして扱います。

9. AWS Resilience Hubで構成変化やドリフトを確認できる

AWS Resilience Hubでは、レジリエンスポリシーへ目標RTO / RPOを設定し、現在のアプリケーション構成に対する推定ワークロードRTO / RPOを評価できます。

さらに評価時には、以前の成功した評価と比較して、

アプリケーションポリシーのドリフト

リソースの追加 / 削除

推定RTO / RPOのドリフト

などを確認できます。

例えば、

前回評価
↓
ポリシー準拠

その後
↓
リソース追加
構成変更

今回評価
↓
ポリシードリフト検出

なら、

以前準拠していた

という結果をそのまま現在へ適用しません。

変更後の構成を再評価し、現在の目標に対する状態を確認します。

10. AWS Resilience Hubのドリフトは再評価のきっかけとして使う

AWS Resilience Hubで、

Changes detected

や、

Drifted

といった状態が確認された場合、

以前の評価が失敗していた

という意味に限定して考えません。

重要なのは、

以前評価したアプリケーション

と、

現在評価すべきアプリケーション

の間に差があることです。

入力ソースへリソース追加・削除などのドリフトがある場合は、現在のリソースを取り込み、公開・再評価して、現在構成に対する評価結果を取得します。

11. 再評価した結果、変更不要でもよい

再評価の目的は、

必ずDR戦略を変更する

ことではありません。

例えば、

RTO / RPO変更なし

復旧経路へ影響する構成変更なし

現在のワークロード規模でも
既存結果を利用できる

フェイルオーバー / フェイルバックの
必要な証拠も現在有効

なら、現在のDR戦略を維持できます。

再評価とは、

変更する作業

ではなく、

現在も妥当であることを
確認する判断

です。

12. 再評価の流れ

現在のRTO / RPOを確認
↓
最後に有効なDR評価を確認
↓
その評価後の変更を洗い出す
↓
各変更が影響する復旧経路を特定
↓
無効になった評価証拠を特定
↓
必要な部分だけ再評価
↓
現在要求と現在有効な証拠を比較
↓
DRギャップを特定
↓
必要なら戦略を改善

中心となる判断は、

何が変わったか
↓
何の証拠が古くなったか

です。

13. 混同ポイント

14. SAP-C02での判断フロー

既存DR戦略あり
↓
最後に有効な評価はいつ？
↓
その後に何が変わった？
├─ RTO / RPO
├─ アプリケーション
├─ 依存関係
├─ データ
├─ 復旧環境
└─ ワークロード規模
↓
その変更は
どの復旧経路へ影響する？
↓
以前のどの証拠が無効になった？
↓
必要な部分だけ再評価
↓
現在の要求を
現在有効な証拠で満たせる？
│
├─ はい
│   ↓
│   現在のDR戦略を維持可能
│
└─ いいえ / 未証明
    ↓
    DRギャップを特定
    ↓
    必要な部分を改善

15. このページで扱わないこと

ここでは、

RTO / RPOの定義方法

バックアップ / 復元
パイロットライト
ウォームスタンバイ
マルチサイト
などのDR方式の基本比較

復旧テストの具体的な実施手順

フェイルオーバーの具体的操作

フェイルバックの具体的操作

データレプリケーション方式の設計

サービスクォータ不足への対応

は扱いません。

このページで完成させるのは、

以前のDR評価
↓
その後の変更
↓
証拠の有効範囲を再判定
↓
現在のDRギャップを特定
↓
維持 / 改善の必要性を判断

することです。

まとめ

DR戦略を再評価するときは、

以前成功したか

だけを確認しません。

最後に有効だった評価
+
その後の変更
+
変更が影響する復旧経路
+
現在も有効な評価証拠

を確認します。

最も重要なのは、

何が変わったか
↓
何の証拠が古くなったか

を対応付けることです。

現在要求を満たしていない

だけでなく、

以前は満たしていたが
現在も満たすことを証明できない

状態もDRギャップとして扱います。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド — タスク 3.4
• AWS Well-Architected Framework — Plan for Disaster Recovery
• AWS Well-Architected Framework — Test disaster recovery implementation to validate the implementation
• AWS Resilience Hub — Resiliency policies
• AWS Resilience Hub — Reviewing assessments reports
• AWS Resilience Hub — Drift detection