RPO・RTOから選ぶDR戦略 ── AWS Backupのクロスリージョンコピーで作る

概要

災害対策の設計は「どれだけ戻ってよいか（RPO）」と「どれだけ止まってよいか（RTO）」の2つの数値から始まります。この2つが決まると、選ぶべき戦略はかなり絞り込めます。逆に、数値を決めずに「マルチリージョンで冗長化しましょう」と進めると、要件に対して過剰なコストを払うことになります。

たとえば「RPO 1時間・RTO 4時間」という要件なら、常時稼働の待機環境は要りません。1時間ごとにバックアップを取り、別リージョンへコピーしておき、被災時にそこから復元する構成で足ります。AWS Backupを使えば、この「定期バックアップ + クロスリージョンコピー」を1つのプランで設定できます。

この記事では、4つのDR戦略をRPO・RTO・コストの観点で整理したうえで、AWS Backupでバックアッププランを作り、別リージョンへコピーされることを確認します。

この記事のメリット

• RPOとRTOの違いを、設計への効き方の違いとして説明できるようになる
• 4つのDR戦略を、要件から選び分けられるようになる
• AWS Backupの構成要素（ボールト・プラン・ルール・リソース割り当て）を把握できる
• クロスリージョンコピーとライフサイクルの設定が何を意味するのか分かるようになる
• SCS試験でDR要件からアーキテクチャを選ぶ設問に答えられるようになる

技術解説

RPOとRTO

指標	意味	決まると何が決まるか
RPO（目標復旧時点）	障害時にさかのぼって失ってよいデータの量を時間で表したもの	バックアップやレプリケーションの頻度
RTO（目標復旧時間）	障害の発生から復旧までに許される時間	待機環境をどこまで用意しておくか

RPOは「データをどれだけ頻繁にコピーするか」、RTOは「どれだけ準備した状態で待つか」に効きます。RPO 1時間なら1時間ごとのバックアップ、RTO 4時間なら復元とデプロイに4時間かけられる、という読み方をします。

4つのDR戦略

AWSのホワイトペーパーでは、DR戦略が4つに整理されています。左から右へ行くほど復旧が速くなり、コストと複雑さが上がります。

戦略	仕組み	RTO	RPO	コスト
バックアップと復元	データを別リージョンにコピーしておき、被災時にインフラ・設定・アプリを再デプロイして復元する	長い	長い	最も低い
パイロットライト	データベースやオブジェクトストレージなどのデータ層は常に動かし、アプリケーションサーバーは止めておく。フェイルオーバー時に起動してスケールアウトする	中程度	低い	低〜中
ウォームスタンバイ	本番を縮小した「完全に動く」環境を別リージョンで常時稼働させる。フェイルオーバー時はスケールアップするだけ	短い	低い	中
マルチサイトアクティブ/アクティブ	複数リージョンで同時に稼働し、すべてのリージョンでトラフィックを処理する。フェイルオーバーという概念がない	ほぼゼロ	ほぼゼロ	最も高い

判断のしかたはこうなります。

• RTOが数時間〜1日: バックアップと復元。データのコピー先を別リージョンに用意しておく
• RTOが数十分: パイロットライト。データ層だけ常に動かしておく
• RTOが数分: ウォームスタンバイ。縮小版が常に動いている
• 停止が許されない: マルチサイトアクティブ/アクティブ

「RPO 1時間・RTO 4時間」は最初の区分に入ります。1時間ごとのバックアップで RPO を満たし、復元に4時間使える、という設計です。パイロットライトを選んでもよいですが、RTO 4時間に対しては過剰になりがちです。

AWS Backupの構成要素

AWS Backupは、複数のサービスのバックアップを1か所で設計・実行・監査するためのサービスです。

要素	役割
バックアップボールト	リカバリポイント（バックアップの実体。コンソールでは「復旧ポイント」と表示される）の入れ物。KMSキーで暗号化する
バックアッププラン	いつ・何を・どこに・どれだけ保持するかの定義
バックアップルール	プランの中の1本のスケジュール。頻度・ウィンドウ・ライフサイクル・コピー先を持つ
リソースの割り当て	どのリソースをこのプランの対象にするか。タグまたはリソースIDで指定する
Backup Vault Lock	ボールトをWORM化し、保持期間中の削除を禁止する

タグで割り当てられるのが実運用では効きます。「Backup=daily タグが付いたリソースは自動的に対象になる」という運用にしておくと、リソースが増えてもプランを直す必要がありません。

バックアップルールで決めること

項目	内容
バックアップ頻度	このプランでバックアップを作成する間隔
バックアップ期間（バックアップウィンドウ）	開始時刻、「次の時間以内に開始」（既定8時間）、「次の時間以内に完了」（既定7日）
ライフサイクル	コールドストレージへ移行するタイミングと、合計保持期間
コピー先へのコピー	別リージョン（別アカウント）のボールトへリカバリポイントをコピーする

ライフサイクルには制約があります。コールドストレージに移したバックアップは最低90日そこに置く必要があるため、合計保持期間はコールドストレージへの移行日数より90日以上長くする必要があります。また、早すぎる移行はウォームバックアップの追加作成につながるため、AWSは少なくとも8日後まではコールドストレージへ移さないことを推奨しています。

クロスリージョンコピーがDRの要

同じリージョンのボールトにバックアップがあっても、そのリージョンが被災すれば取り出せません。DRを名乗るなら、リカバリポイントを別リージョンにコピーしておくことが前提になります。

コピー先のボールトは、コピー元とは別のKMSキーで暗号化されます。コピー先リージョンにもキーが必要になる点、復元する担当者がそのキーを使える必要がある点は、権限設計で忘れやすいところです。

実践

バックアップボールトとバックアッププランを作成し、タグでEBSボリュームを割り当てます。続けてオンデマンドバックアップを取り、その復旧ポイントを別リージョンへコピーできることを確認します。

前提条件

• リージョン: ap-northeast-1（東京）、コピー先は ap-northeast-3（大阪）
• AWS Backup・EC2・KMSの操作権限を持つIAMユーザーまたはロールでコンソールにログイン済みであること
• 以下のリソースが作成済みであること

リソース種別	リソース名	用途
EBSボリューム	dr-lab-volume（8 GiB, gp3、タグ Backup=dr-lab）	バックアップ対象

このハンズオンで作成するリソースは以下のとおりです。

リソース種別	リソース名	用途
バックアップボールト	dr-lab-vault（東京）	復旧ポイントの保管先
バックアップボールト	dr-lab-vault-copy（大阪）	クロスリージョンコピーの保管先
バックアッププラン	dr-lab-plan	1時間ごとのバックアップとコピー

手順1: コピー先リージョンにボールトを作成する

AWSマネジメントコンソールで、リージョンを ap-northeast-3（大阪）に切り替えます。

上部の検索バーに Backup と入力し、「AWS Backup」を選択します。

左側ナビゲーションの「ボールト」を選択し、「ボールトを作成」をクリックして以下を設定します。

• ボールト名: dr-lab-vault-copy
• ボールトタイプ: バックアップボールト（既定のまま）
• 暗号化キー: (デフォルト) aws/backup を選択

その他の項目はデフォルトのままにして、「ボールトを作成」をクリックします。作成したボールトの詳細画面が表示されます。

手順2: 東京リージョンにボールトを作成する

リージョンを ap-northeast-1（東京）に戻し、同じ手順で dr-lab-vault を作成します。

手順3: バックアッププランを作成する

左側ナビゲーションの「バックアッププラン」から「バックアッププランを作成」をクリックします。

「新しいプランを立てる」を選び、バックアッププラン名に dr-lab-plan を入力します。

「バックアップルールの設定」で以下を設定します。

• バックアップルール名: hourly-rule
• バックアップボールト: dr-lab-vault
• バックアップ頻度: 毎時（RPO 1時間に合わせます）
• バックアップ期間: 既定のまま（開始時間 00:30、8 時間以内に開始、7 日以内に完了）
• 合計保持期間: 7 日数（既定は 35 日なので変更します。コールドストレージへの移動はオフのまま）

「コピー先にコピー – オプション」で以下を設定します。

• リージョン: アジアパシフィック (大阪)
• 送信先ボールト: dr-lab-vault-copy
• ライフサイクル: 既定の「バックアップルールと同じ設定を使用する」（合計保持期間 7 日）のまま

「プランを作成」をクリックします。作成に成功すると、続けて「リソースを割り当てる」画面が表示されます。

手順4: リソースを割り当てる

「リソースを割り当てる」画面で以下を設定します。

• リソース割り当て名: dr-lab-resources
• IAM ロール: デフォルトロールを作成
• 1. リソース選択を定義: 特定のリソースタイプを含める
• 2. 特定のリソースタイプを選択: EBS（ボリューム ID は「すべてのボリューム」のまま）
• 4. タグを使用して選択を絞り込む: キー Backup、値の条件 次と等しい:、値 dr-lab

「リソースを割り当てる」をクリックします。対象が多くなる可能性がある旨の確認ダイアログが表示された場合は、「続行」をクリックします。タグで絞り込んでいるので、対象になるのは Backup=dr-lab のボリュームだけです。

手順5: オンデマンドバックアップを実行する

スケジュールを待たずに動作を確認します。左側ナビゲーションの「保護されたリソース」を開き、「オンデマンドバックアップを作成」をクリックして以下を設定します。

• リソースタイプ: EBS
• ボリューム ID: dr-lab-volume のボリューム ID
• バックアップ期間: 今すぐバックアップを作成
• 合計保持期間: 7 日数（既定は 35 日なので変更します）
• バックアップボールト: dr-lab-vault
• IAM ロール: デフォルトロールを作成

その他の項目はデフォルトのままにして、「オンデマンドバックアップを作成」をクリックします。「ジョブ」画面に切り替わり、バックアップジョブが作成されます。

手順6: バックアップジョブの完了を確認する

「ジョブ」画面の「バックアップジョブ」タブで、ジョブのステータスが 完了 になることを確認します。今回の 8 GiB のボリュームでは、4 分ほどで終わりました。

オンデマンドバックアップにはクロスリージョンコピーの設定がありません。コピーはバックアッププランのルールに従って実行されるため、オンデマンドで作った復旧ポイントは、次の手順で手動でコピーします。

手順7: 復旧ポイントを大阪へコピーする

左側ナビゲーションの「ボールト」から dr-lab-vault を開きます。「復旧ポイント」タブで、手順5で作成した復旧ポイントの行を選択し、「アクション」→「コピー」をクリックします。

以下を設定して「コピー」をクリックします。

• リージョン: アジアパシフィック (大阪)
• 送信先ボールト: dr-lab-vault-copy
• ライフサイクル: リカバリーポイントと同じ設定を使用する

「ジョブ」画面の「コピージョブ」タブに切り替わり、コピージョブが作成されます。ステータスが 完了 になるまで待ちます（今回は 4 分ほどでした）。

リージョンを大阪に切り替え、「ボールト」→ dr-lab-vault-copy を開きます。「復旧ポイント」タブに、dr-lab-volume の復旧ポイントがステータス 完了 で入っていることを確認します。

これで「東京が使えなくなっても、大阪にデータがある」状態になりました。復元は、この復旧ポイントから新しいボリュームを作る操作になります。

まとめ

要件	選ぶ戦略
RTOが数時間〜1日	バックアップと復元（AWS Backup + クロスリージョンコピー）
RTOが数十分	パイロットライト（データ層だけ常時稼働）
RTOが数分	ウォームスタンバイ（縮小版が常時稼働）
停止が許されない	マルチサイトアクティブ/アクティブ

• RPOはバックアップの頻度、RTOは待機環境の準備度合いに効く
• 「RPO 1時間・RTO 4時間」は、1時間ごとのバックアップ + 別リージョンへのコピーで満たせる
• AWS Backupの対象はタグで割り当てると、リソースが増えてもプランを直さずに済む
• コールドストレージを使う場合、合計保持期間はコールドストレージへの移行日数より90日以上長くする必要がある
• クロスリージョンコピーが無ければDRにならない。コピー先のKMSキーと復元権限も設計に含める

参照先

• クラウドでのディザスタリカバリオプション – AWS ホワイトペーパー
• バックアッププランの作成 – AWS Backup
• バックアップのコピー – AWS Backup
• AWS Backup Vault Lock – AWS Backup
• バックアップボールトの操作 – AWS Backup
• Lifecycle – AWS Backup