はじめてのDR/BCP対応の考え方

はじめに

AWSにWebアプリを載せて、無事に動いている。バックアップも一応取れている。……そこで、ある日こう聞かれます。

「もし東京リージョンが丸ごと落ちたら、どうなるの?」

答えに詰まりました。バックアップは取っています。でもそのバックアップも東京にあります。つまり東京がダメになったら、バックアップごとダメになるわけです。

私のチームでこの課題に取り組むことになったとき、いちばん困ったのは「何から考えればいいのか分からない」ことでした。DR(災害復旧)やBCP(事業継続)の記事を検索すると、いきなり「マルチリージョンでActive-Activeにして……」という重厚な構成が出てきて、うちの規模には明らかに過剰。かといって「何もしない」わけにもいきません。

この記事は、DR/BCPをはじめて検討する人が、何をどの順番で決めればいいのかを整理したものです。実装の詳細よりも、決め方に重きを置いています。

想定読者

• AWSにWebアプリ(ECS + RDS + S3 のようなよくある構成)を載せて運用している
• 「DR? BCP? 聞いたことはあるけど、やったことはない」
• 専任のインフラ担当はいない、小〜中規模のチーム
• 上司や顧客に「災害対策はどうなってる?」と聞かれて答えに困った経験がある

そもそもDRとBCPは何が違うのか

最初につまずくのが用語です。ここだけ押さえれば進めます。

用語	意味	誰の話か
DR(Disaster Recovery / 災害復旧)	落ちたシステムを技術的にどう復旧させるか	エンジニアの話
BCP(Business Continuity Plan / 事業継続計画)	システムが止まっている間、業務をどう続けるか	事業側の話

つまりDRはBCPの一部です。「DBを別リージョンから復元する手順」がDR、「復旧までの3日間は電話とExcelで受注を受ける」がBCPです。

エンジニアとしてはDRに集中したくなりますが、BCP側が決まっていないとDRの目標が決まりません。ここが最初の重要ポイントです。

目標は2つの数字で決まる:RPOとRTO

DRの設計は、実はこの2つの数字を決めることから始まります。

用語	読み方	意味	質問の形にすると
RPO	Recovery Point Objective	どこまでのデータなら失っても許容できるか	「直近何時間ぶんのデータが消えても事業は続けられる?」
RTO	Recovery Time Objective	どれくらいの時間で復旧させるか	「何時間止まったら業務が本当に困る?」

この2つは技術ではなく事業の判断です。そしてこの数字が、そのまま費用に跳ね返ります。

• RPO 0(1件も失えない)を目指すなら、常に別リージョンへ同期し続ける必要がある → 高い
• RPO 24時間(1日分は許容)なら、1日1回バックアップを別リージョンへ送るだけでよい → 安い

私たちの場合、事業側と話して「業務が止まるのは仕方ない。でもデータを失うのは絶対にダメ」という優先順位がはっきりしました。この一言で方針がほぼ決まりました。

💡 ここを飛ばして技術検討に入ると、だいたい「何のためにこれを作っているのか」で迷子になります。先に数字を握るのがおすすめです。

なぜ「同じリージョンのバックアップ」では足りないのか

「毎日スナップショットを取っています」という状態は、実は壊れ方によって守れる範囲が違います。

壊れ方	同一リージョンのバックアップで守れるか
誤ってテーブルを消した	✅ 守れる
DBインスタンスが壊れた	✅ 守れる
データセンター(AZ)が1つ落ちた	✅ 守れる(AWSが複数AZに保管)
リージョンが丸ごと落ちた	❌ 守れない(バックアップも同じリージョン)

つまり別リージョンへの退避は、この最後の1行のためだけに用意するものです。逆に言えば、それ以外の壊れ方は既存のバックアップで守れているので、慌てて全部作り直す必要はありません。

「どのリスクに対して、いくら払うのか」を切り分けて考えると、話が整理しやすくなります。

選択肢は4段階ある

AWSの一般的な整理では、DRの構成は4段階に分かれます。上に行くほど速く復旧できて、上に行くほど高くつきます。

#	方式	別リージョンに置くもの	RTOの目安	費用感
①	マルチサイト	本番と同等の環境が常時稼働	ほぼ0	2倍以上
②	ウォームスタンバイ	縮小版が常時稼働	数分〜数十分	中〜高
③	パイロットライト	DBは待機、サーバーは停止	数十分〜数時間	中
④	バックアップ&リストア	データだけ(サーバーもDBも動かさない)	数時間〜数日	最小

初めて取り組むなら、まず④から検討するのが現実的だと思います。理由は3つあります。

1. 費用が段違いに安い(サーバーを動かさないので、ストレージ代だけ)
2. 既存の構成をほとんど変えなくていい(退避の配線を足すだけ)
3. ④が土台になる(将来③②へ上げるときも、データの退避は必ず必要)

私たちも④を選びました。「業務は止まってもいいが、データは失わない」という優先順位にちょうど合っていたためです。

決め方の順番

ここが本題です。私たちが実際に踏んだ順番を、そのまま並べます。

手順1. 事業として許容できる線を先に決める

前述のRPO/RTOです。エンジニアだけで決めず、事業側に聞いて言葉にしてもらうのが大事です。私たちの場合は次の一文に落ちました。

東京が止まれば業務も止まる。ただしデータは失わない。復旧は東京の復旧を待つのが基本線。

この水準ならRPOは最大24時間(1日1回の退避)、RTOは「東京が戻るまで」で成立します。この一文が後の判断すべての基準になりました。

手順2. 退避するものを「再生成できるか」で仕分ける

全部を退避するとお金がかかります。そこで失ったら二度と戻らないものだけに絞ります。判断基準はシンプルに「再生成できるか?」の一問だけです。

対象	退避する?	理由
データベース(RDS)	✅ する	失ったら終わり。最重要
ユーザーがアップロードしたファイル(S3)	✅ する	再生成できない
コンテナイメージ(ECR)	✅ する	厳密には再ビルドできるが、復旧時にビルド環境も落ちている可能性があるので置いておく
検索用に生成したベクトルデータ	❌ しない	元ドキュメントから再生成できる
キャッシュ(Redis等)	❌ しない	消えても再構築される
認証基盤(Cognito等)	⚠️ 対象外	そもそもリージョンを跨いで複製できない。別途対応が必要

3列目の「理由」を書いておくのがポイントです。後から「なぜこれは退避していないの?」と聞かれたときに答えられます。

⚠️ 認証基盤のように「複製する手段がそもそも無い」ものもあります。この場合は「復旧時に作り直す」「ユーザーに再登録してもらう」といった運用側の手当てになります。技術で解決できない部分を早めに洗い出しておくと、あとで慌てません。

手順3. 退避先をどこにするか決める

「別リージョンへ」と言っても、置き方は複数あります。

案	内容	メリット	デメリット
A	同じAWSアカウントの別リージョン	構成が単純。権限設計が楽	アカウントごと侵害されると一緒に消える
B	別アカウントの別リージョン	アカウント侵害・誤操作に強い	クロスアカウントの権限設計が必要で複雑

セキュリティを突き詰めればBですが、私たちはAを選びました。理由は「顧客ごとにAWSアカウントを分けている構成なので、データが顧客のアカウント外に出ないほうが説明しやすい」という点でした。

正解は環境次第です。ただ**「なぜそちらを選んだか」を1行でも残しておくこと**が、後任者への最大の親切になります。

手順4. 保持期間を決める

何日分を持っておくかです。長くすればストレージ代が増えます。

私たちは7日にしました。「気づくのに1週間かかる誤操作はまず無い」「リージョン障害なら数日で復旧する」という2つの想定からです。ここも数字なので、決めた値をどこかに書いておくのが重要です(あとで「なんで7なんだっけ?」となります)。

手順5. コストを見積もって合意を取る

最後にお金です。バックアップ&リストア構成の費用は、ほぼストレージ代と転送代だけです。サーバーを動かさないので、いわゆる「二重の実行費用」は発生しません。

参考として、小規模環境1つ(DBが数GB、アップロードファイルが数十MB、コンテナイメージが十数GB)での月額の目安は次のようなイメージでした。

項目	目安
DBのバックアップを別リージョンに保管	数十円〜数百円
ファイルの複製(ストレージ+転送)	数十円
コンテナイメージの複製	数百円
合計	月あたり数百円〜1,000円程度

実際の額はデータ量に完全に依存するので、検証環境で先に有効化して実測するのが確実です。私たちも本番の前に検証環境で動かし、実額を見てから展開しました。

「月数百円でリージョン障害からデータを守れる」と言えると、費用の議論はかなり通りやすくなります。

完成した構成

決めたことを図にすると、こうなりました。

ポイントは右側の注記です。別リージョンには「置き場所」しか作りません。DBインスタンスもサーバーも起動しないので、費用がストレージ代だけに収まります。

退避の頻度が対象ごとに違うことにも注目してください。

対象	頻度	理屈
データベース	1日1回	スナップショットのコピーなので、こまめにやっても意味が薄い(RPO 24時間の合意と一致)
ファイル	書き込むたび	S3の複製機能が自動でやってくれる。追加費用も小さい
コンテナイメージ	pushのたび	同上

「全部を1日1回」にしなくてよく、安くリアルタイムにできるものはリアルタイムにするのが素直です。

初心者がつまずきやすいポイント

私たちが実際に踏んだ・気づいた落とし穴です。実装の詳細に入る前に、これだけ知っておくと事故が減ります。

1. 「バックアップがある」は「復旧できる」ではない

いちばん大事な点です。データが別リージョンにあっても、そこから起動する手順が無ければ復旧できません。

• 復旧手順書を書く(誰が、どのコマンドで、どの順に)
• 年1回でも実際に復元してみる(これをやると必ず何か見つかります)
• 「切り替える」判断を誰がするのかを決める(技術判断ではなく経営判断)

「退避の仕組みを作った」で止めてしまうと、いざというときに動けません。仕組みづくりは半分で、残り半分は手順とリハーサルです。

2. 暗号化のカギはリージョンを跨げない

見落としがちな技術的制約です。暗号化されたデータを別リージョンへコピーするとき、コピー先のリージョンにも暗号化キーが必要になります。AWSが自動で用意してくれるキーはリージョンを跨げないので、コピー先に自分でキーを作る必要があります。

「なぜかコピーだけ失敗する」の典型的な原因なので、最初に押さえておくと時間を節約できます。

3. 複製は「これから書くもの」だけが対象

S3の複製機能を有効にしても、すでに入っているファイルは複製されません。設定した時点より後に書き込まれたものだけが対象です。

既存分も揃えたいなら、別途まとめてコピーする作業(バックフィル)が必要になります。「有効にしたから安心」と思ったまま既存データが片方にしか無い、という状態になりがちです。

4. 設定した気になって、実は動いていない

これがいちばん怖いパターンです。退避の設定はデプロイが成功しても、実際に動くのは深夜だったりします。

私たちの構成では、「退避元の設定」と「退避先の置き場所」を別々に作ります。もし退避先を作らずに退避元だけを設定すると、デプロイは成功したまま、毎晩のコピーだけが静かに失敗し続けます。誰も気づきません。

対策は2つです。

• 作る順番を決めて手順書に書く(置き場所を先に作る)
• 失敗したら通知が飛ぶようにする(通知先の設定を忘れると意味が無いので、そこまでセットで)

5. リージョンによって使えるサービスが違う

退避先のリージョンで、使いたいサービスが提供されていない場合があります。私たちも事前に「このリージョンでこのサービスは使えるか」を1つずつ確認しました。

さらに、組織のポリシー(SCP等)で特定リージョンの利用が禁じられていることもあります。「作れるかどうか」を小さく試してから本番の設計に入るのがおすすめです。

6. 復旧に必要なのはデータだけではない

データが揃っていても、次のものが東京に集中していると復旧できません。

• デプロイの手段(ソースコードの置き場、ビルド環境)
• ドメイン名の切り替え(どこを向けるか)
• 認証基盤(ログインできないとアプリが使えない)

私たちも「コードの置き場もビルド環境も東京にある」という事実に気づきました。ここは今回のスコープ外として、リスクとして文書に残しました。全部解決しなくてもよいので、把握して書いておくことが大切です。

決めたことは必ず文書に残す

DR/BCPは「作って終わり」の仕組みではなく、何年も後に、別の人が使う仕組みです。少なくとも次を残しておくとよいと思います。

残すもの	内容
到達水準	「データは失わない。復旧は元リージョンの復旧を待つ」など、一文で言える形
RPO / RTO	決めた数字とその根拠
退避する/しないの一覧	しない理由まで書く(再生成できる、複製不可、など)
設定値	保持日数、実行時刻など。あとで必ず「これ何だっけ」となる
復旧手順	誰が、何を、どの順に
切り替えの判断基準	誰が判断するのか
やらなかったこと	認証基盤、ビルド環境など。リスクとして明記する

いちばん抜けがちなのは最後の「やらなかったこと」です。ここが空白だと、後任者は「対応済み」と誤解します。

まとめ

• DRは技術、BCPは業務。BCP側(どれだけ止まって平気か)が決まらないとDRの目標が決まらない
• 設計は**RPO(どこまで失えるか)とRTO(いつ復旧するか)**の2つの数字から始める。これは事業判断
• 同一リージョンのバックアップではリージョン障害だけが守れない。別リージョン退避はそこだけのための投資
• 構成は4段階。初めてならいちばん安い「バックアップ&リストア」から。将来上位へ上げる土台にもなる
• 退避対象は「再生成できるか」で仕分ける。できるものは退避しない
• 費用はストレージ代中心で、小規模なら月数百円〜。検証環境で実測してから合意を取る
• 仕組みを作って半分。復旧手順とリハーサル、そして「やらなかったこと」の記録まででワンセット

「DR対応、何もしていないな……」と気になっていた方が、最初の一歩を決めるための材料になれば嬉しいです。

実際にAWS CDKでコード化した話(1日1回のバックアップ+別リージョンへのコピー、S3の複製、イメージの複製をまとめて作る)は、需要があれば実装編として別途書きます。