本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリ第10弾として、BCPについて解説する記事です。
地震・停電・クラウド障害・サイバー攻撃・人的ミスでもサービスを止めない／早期復旧させるための設計と手順を扱います。RPO/RTOの決め方・DR戦略の4パターン・バックアップ3-2-1ルール・ランサムウェア対策、そして冗長化は訓練しなければ無価値という現実まで解説します。
本記事のテーマについてさらに詳しく知りたい方は『AWSの基本・仕組み・重要用語が全部わかる教科書』も参考にしてみてください。
この記事の結論
- RPO / RTOを業務部門と合意してから技術を選ぶ
- マルチAZ+3-2-1バックアップが標準ライン
- バックアップは別アカウント+Object Lockでランサムウェアから守る
- 復旧訓練をしない冗長化は無価値。四半期に1回は戻す訓練をする
この記事を読む前に
本記事はサーバーやネットワークといったインフラ寄りの用語が多めに登場します。IT用語にあまり馴染みがない方は、基礎編の「サーバーとクラウドの基本」と「Webサービスが動く仕組み」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもBCP/DR設計とは何か
BCP/DR設計とは、ざっくり言えば「地震・停電・サイバー攻撃などでシステムが止まったとき、どれだけ早く復旧させるかの計画」です。
防災用の非常袋を想像してください。災害が来てから水や食料を探しても手遅れで、事前に用意しておくから意味があります。BCPも同じで、「何時間以内に復旧するか（RTO）」「どの時点のデータまで戻せるか（RPO）」を事前に決め、バックアップ・冗長構成・復旧手順を整えておく工程です。計画だけでなく定期的に訓練しないと、いざという時に動かないのも防災と同じです。
なぜBCP/DR設計が重要なのか
もしBCP/DR設計をしなかったらどうなるか。大規模障害は数年に一度、必ずどこかで起きます。2011年の東日本大震災、2021年のAWS東京リージョン障害、2024年のCrowdStrike世界規模障害──「想定外」は日常的に発生します。
備えがないと「数日間サービス停止」という事態に直結し、顧客の信頼失墜・売上損失・契約違反が降りかかります。特にSaaS事業では、1回の長時間停止で顧客が競合に流れ、二度と戻ってこないという事例を何度も見ます。BCPは顧客信頼と直結する備えです。
RPOとRTO ― 業務部門との合意が出発点
BCP設計の中心概念は2つの目標値です。RPO（Recovery Point Objective）は「何時点のデータまで戻せるか」＝データ損失の許容量、RTO（Recovery Time Objective）は「何分/何時間で復旧するか」＝停止時間の許容量です。
目安として、金融取引・決済のようなミッションクリティカル系はRPOゼロ・RTO数秒〜数分、ECサイトや社内基幹はRPO数分・RTO 1時間以内、社内ツールならRPO 24時間・RTO数日で十分です。要求が厳しいほどコストは指数関数的に増えるため、RPO/RTOを無闇に厳しくすると本来不要な莫大なインフラ投資が発生します。「どこまで止まっても許容できるか」を業務部門と冷静に合意するのが先決で、技術先行で決めてはいけません。
可用性の階段
可用性レベルごとに、投資額が桁違いに変わります。
| 可用性 | 年間停止時間 | 構成 |
|---|---|---|
| 99.0% | 3.65日 | 単一サーバー |
| 99.9% | 8.76時間 | 冗長化・マルチAZ |
| 99.99% | 52.6分 | マルチリージョン |
| 99.999% | 5.26分 | マルチクラウド・Active/Active |
マルチAZ（99.9〜99.95%）が現実的な標準ラインです。それ以上の可用性は金融・医療・通信など特別な要件がある場合に限り、それ以外は過剰投資になるケースが大半です。
DR戦略の4パターン
AWS Well-Architected Frameworkで整理されるDR戦略の4パターンです。右に進むほどRTOは短くなりますが、コストは数倍になります。
| 戦略 | 仕組み | RTO |
|---|---|---|
| Backup & Restore | バックアップから復元 | 数時間〜1日 |
| Pilot Light | DBだけ常時同期、アプリは停止 | 数十分〜1時間 |
| Warm Standby | 縮小規模で常時稼働 | 数分 |
| Multi-site Active/Active | 両サイト完全稼働 | ゼロ〜数秒 |
Pilot Lightは消えかけの種火を灯しておくイメージで、セカンダリ環境にDBだけを同期複製し、災害時にアプリを起動して復旧します。Warm Standbyはセカンダリを本番より小さな規模で常時稼働させ、障害時はスケールアップするだけなのでさらに速い。両者はRPO/RTO要件と月額コストの綱引きで選びます。
Active/Activeは両リージョンが常に稼働する最高峰の構成ですが、双方向DBレプリケーション・セッション共有・書き込み競合の処理など、データ整合性の設計難度が段違いです。「真に必要な場合のみ採用」が鉄則で、過剰採用で複雑性の沼に沈む案件が後を絶ちません。
バックアップの3-2-1ルールとランサムウェア対策
3-2-1ルールはバックアップの世界的な標準指針です。3つのコピー（オリジナル+2つ）を持ち、2種類のメディアで保管し、1つはオフサイト（地理的に離れた場所・別クラウド）に置く。クラウドならS3のCross-Region Replication・AWS Backupの統合バックアップ・Glacier Deep Archiveへのコールドコピーで実装します。
そして現在最大級の脅威がランサムウェアです。バックアップごと暗号化されると身代金を払うしかなくなるため、原則は「管理者権限を奪われてもバックアップだけは消せない設計」です。具体的には、書き込み後に変更不可にするObject Lock（WORM）、本番アカウントの権限侵害でも触られない別アカウントへの隔離、S3オブジェクト削除にMFAを必須化するMFA Deleteを組み合わせます。本番と同じアカウント内のS3に置くだけのバックアップは、アカウント侵害時に全て消される可能性があります。
冗長化と訓練 ― 訓練しない冗長化は機能しない
冗長化の典型は、Webアプリ・APIサーバーのActive-Active（ロードバランサーで負荷分散）と、DBのActive-Standby（データ整合性のため単一書き込み）です。AuroraやCloud SQLはマネージドでこれを自動実現します。
ただし冗長化しただけでは不十分で、「本当に切り替わるか」を定期的に確認しないと、いざという時に動きません。これがChaos Engineeringの考え方です。計画的な障害演習（Game Day）、ランダムにインスタンスを停止するChaos Monkey（Netflix発祥）、本番相当環境でのFailoverテスト──日本企業でも四半期に1回のフェイルオーバー訓練が推奨されます。帳簿上の冗長化は無力です。
どう選べばいいのか ― 規模別の3シナリオ
個人開発・スタートアップなら ― マネージドの自動バックアップ+PITR
DR戦略はBackup & Restoreで十分だと思います。RDSのようなマネージドDBであれば自動バックアップとPITR（任意時点復元）が標準機能ですので、有効化した上で「実際に別インスタンスへ復元してみる」訓練を一度やっておいてください。RPO 24時間・RTO数時間を受け入れてしまえば、コストはほぼゼロで済みます。
中小SaaSなら ― マルチAZ+3-2-1+四半期訓練
本番はマルチAZを標準にし、バックアップは3-2-1ルール+別アカウント保管+Object Lockまで整えます。顧客影響の大きい基幹部分だけPilot Lightで別リージョンにDBを同期し、四半期に1回のリストア訓練・フェイルオーバー訓練を運用カレンダーに固定します。
大企業・規制業種なら ― Warm Standby以上+訓練の制度化
金融・決済・医療などゼロダウンタイム要求がある系はWarm StandbyまたはActive/Activeを検討し、FISC等の業界基準に沿ったDR計画・年次監査・訓練記録を制度化します。リージョン全停止（2021年AWS東京リージョン障害）やサプライチェーン障害（2024年CrowdStrike）まで想定に入れるのがこの規模の責務です。
AI判断軸 ― IaCで宣言・訓練もスクリプト化できるか
AI駆動開発が前提になると、BCP・DR設計は「全てIaCで宣言し、訓練もスクリプト化できること」が条件になります。なおRPO/RTOのビジネス要件との合意はAI時代でも人間の仕事です。AIがインフラを復旧させても、「どれくらいの損失までなら許容するか」を決めるのは経営判断であり続けます。
IaCで定義されたDR構成はAIによる検証が可能
DR構成がTerraform / CDKでコード化されていれば、AIが「本番とDR環境の差分」を検出できます。本番に新サービスを追加した際のDR側への反映漏れがコード上のdiffとして可視化されるため、AIがPRレビューで指摘する運用が成立します。手動構築のDR環境では本番との設定差分がドキュメントでしか追えず、気づいた時にはDR環境が数ヶ月前の構成のまま放置されている状況が頻発します。
Chaos Engineeringスクリプトの自動生成
AWS Fault Injection Simulator（FIS）のテンプレートやLitmusChaosのYAMLは、AIが生成しやすいフォーマットです。「AZ障害を模擬するFISテンプレートを書いて」のような指示に、AIは標準テンプレートに沿ったコードを出せます。これによりDR訓練のシナリオ作成コストが下がり、年1回の大掛かりな訓練ではなく、月次で小規模な障害注入テストを回す運用が現実的になります。
やってはいけないこと
BCPは帳簿上の装備ではなく、「動くことを毎回確認する運用」で初めて価値を持ちます。特に危険な6つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| バックアップを取るがリストア訓練をしない | 本番障害時に「戻せない」が発覚する → 四半期に1回は実リストアする |
| バックアップを本番と同じアカウントに保管 | 侵害・ランサムウェア時に消される → 別アカウント+Object Lockにする |
| RPO / RTOを業務と合意せず技術先行で設計 | 過剰投資か過小投資になる → 許容停止時間を先に合意する |
| Active/Activeを人員不足で採用 | 平時から構成管理が追いつかず障害時に壊れている → 要件に見合う戦略に落とす |
| フェイルオーバー先の容量を見積もらない | 本番負荷が乗った瞬間に過負荷で二次障害 → 切替先の容量をテストで確認する |
| リージョン全停止を想定に入れない | 2021年AWS東京・2024年CrowdStrikeのように全停止は実在する → 影響範囲と代替手段を決めておく |
CrowdStrike 2024年障害（更新検証プロセス欠落で世界850万台のWindowsがブルースクリーン）は、自分のクラウドが正常でもサプライチェーンの一部が止まるだけで全体が止まるという現代BCPの前提を突きつけました（詳細は付録「重大インシデント事例集」）。
筆者メモ ― GitLabの「5種類全滅」事件
2017年1月31日、GitLabの運用者が本番DBを誤って削除し、用意されていた5種類のバックアップがどれも機能しないことが発覚した有名な事件があります（詳細は付録「重大インシデント事例集」）。本記事のBCP視点で重要なのは、バックアップを取っている≠戻せるという残酷な事実です。
バックアップの仕組みは壊れるし、権限は変わるし、ログは流れます。動くことを毎回確認する運用まで含めて、はじめて「備えている」と言えます。取っている数ではなく、「戻せた回数」で評価します。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- 機能別のRPO / RTO（業務と合意）
- DR戦略（Backup / Pilot / Warm / Active）
- バックアップ保管期間と世代数・地理的分散
- ランサムウェア対策（Object Lock・別アカウント）
- フェイルオーバー手順と責任者
- 障害訓練の頻度（半期・四半期等）
- 連絡・エスカレーションフロー
言語化した答えはADRとして残します。書き方の具体例は以下の記事で解説しています。
この記事に関連する記事
まとめ
本記事はBCP・DR設計について、RPO/RTO・可用性の階段・DR戦略・3-2-1バックアップ・ランサムウェア対策まで含めて解説しました。如何だったでしょうか。
業務部門とRPO/RTOを合意してから技術を選ぶ。マルチAZ+3-2-1バックアップが標準ライン。冗長化は訓練しなければ無価値。この3点を外さなければBCP設計の核は押さえられます。
次回はシステムアーキテクチャカテゴリの最終記事、「コスト管理（FinOps）」について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は AWS ディザスタリカバリ も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（21/95）