災害復旧（DR）設計がクラウド時代に不可欠な理由
2024年の元日に発生した能登半島地震、2025年の南海トラフ地震臨時情報の発出――日本において自然災害のリスクは常に存在する。これに加え、クラウドサービス自体の障害も現実のリスクだ。2024年にはAWSの東京リージョンで大規模障害が発生し、多数の企業サービスが数時間にわたって停止した。
「クラウドに移行したから安心」という認識は誤りだ。クラウドは高い可用性を提供するが、単一リージョンでの運用は単一障害点（Single Point of Failure）を残したままである。ビジネスの継続性を確保するためには、クラウド環境においても適切なDR（Disaster Recovery：災害復旧）設計が不可欠だ。
本記事では、RPO/RTOの定義からマルチリージョン構成のパターン、コストとのバランスまで、実践的なDR設計の知識を解説する。
RPOとRTOを正しく理解する
DR設計の出発点は、RPOとRTOの定義だ。この2つの指標がDR設計全体の方向性を決定する。
RPO（Recovery Point Objective：目標復旧時点）
障害発生時に、どの時点のデータまで復旧できればよいかを示す指標。RPOが「1時間」であれば、障害発生の1時間前までのデータが復旧できればよい。つまり、最大1時間分のデータ損失を許容するという意思決定だ。
RPOが短いほどデータ損失は少なくなるが、リアルタイムのデータレプリケーションが必要となり、コストが増大する。
RTO（Recovery Time Objective：目標復旧時間）
障害発生から、システムが復旧して利用可能になるまでの目標時間。RTOが「4時間」であれば、障害発生から4時間以内にサービスを復旧させる必要がある。
RTOが短いほど常時稼働のスタンバイ環境が必要となり、コストが増大する。
RPO/RTOとコストの関係
| RPO/RTO | DR方式 | 月額コスト目安（本番比） |
|---|---|---|
| RPO: 24時間 / RTO: 24時間以上 | バックアップ & リストア | 5～10% |
| RPO: 1～4時間 / RTO: 4～8時間 | パイロットライト | 10～20% |
| RPO: 数分 / RTO: 1～4時間 | ウォームスタンバイ | 20～50% |
| RPO: ほぼゼロ / RTO: 数分 | ホットスタンバイ（Active-Active） | 80～100% |
DR構成の4パターン
パターン1: バックアップ & リストア
最もシンプルかつ低コストなDR方式。本番環境のデータを定期的に別リージョンにバックアップし、障害発生時にバックアップからシステムを復元する。
構成のポイント:
- データベースのスナップショットを日次で別リージョンにコピー
- アプリケーションのデプロイアーティファクトをS3/Cloud Storage等に保管
- インフラ構成をIaC（Infrastructure as Code）でコード化し、復元を自動化
メリット: コストが最も低い。バックアップストレージの費用のみ。 デメリット: 復旧に時間がかかる（RTO: 数時間～1日）。復旧手順の訓練が不可欠。
パターン2: パイロットライト
DRリージョンに最小限のコアシステム（データベース等）だけを常時稼働させておく方式。障害発生時に、アプリケーションサーバー等を起動してスケールアウトする。
構成のポイント:
- データベースは常時レプリケーション（非同期でも可）
- アプリケーションサーバーは停止状態で、AMI/イメージのみ準備
- 障害検知時に自動スケーリングでアプリケーションを起動
メリット: バックアップ & リストアより復旧が速い（RTO: 1～4時間）。コストは比較的抑えられる。 デメリット: スケールアウトに時間がかかる。定期的なフェイルオーバーテストが必要。
パターン3: ウォームスタンバイ
DRリージョンに本番環境の縮小版を常時稼働させる方式。障害発生時にスケールアップして本番相当の処理能力にする。
構成のポイント:
- データベースは同期レプリケーション（またはほぼ同期）
- アプリケーションサーバーは最小インスタンスで常時稼働
- ロードバランサー、DNSフェイルオーバーを設定済み
メリット: 復旧が速い（RTO: 数十分～数時間）。フェイルオーバーの自動化が可能。 デメリット: 常時稼働分のコストが発生。本番環境の20～50%程度の運用コスト。
パターン4: ホットスタンバイ（Active-Active）
2つ以上のリージョンで同時にトラフィックを処理する方式。障害発生時は、障害リージョンへのトラフィックを正常なリージョンに切り替えるだけで復旧する。
構成のポイント:
- 全リージョンで同一構成のシステムを稼働
- データベースはマルチリージョンレプリケーション（同期）
- グローバルロードバランサーでトラフィックを分散
- データの整合性管理が最も複雑
メリット: 復旧がほぼ瞬時（RTO: 数秒～数分）。通常時もレイテンシ低減の恩恵がある。 デメリット: コストが本番環境の2倍近くに。データ整合性の設計が複雑。
クラウドプロバイダー別のDR機能
AWS
| サービス | DR関連機能 |
|---|---|
| S3 | クロスリージョンレプリケーション |
| RDS | マルチAZデプロイ、クロスリージョンリードレプリカ |
| Aurora | Aurora Global Database（秒単位のレプリケーション） |
| EC2 | AMIのクロスリージョンコピー |
| Route 53 | ヘルスチェック + DNSフェイルオーバー |
| CloudFormation | IaCによるインフラ再構築の自動化 |
| AWS Elastic Disaster Recovery | マネージドDRサービス |
Azure
| サービス | DR関連機能 |
|---|---|
| Blob Storage | Geo冗長ストレージ（GRS） |
| Azure SQL | アクティブGeoレプリケーション、自動フェイルオーバーグループ |
| Cosmos DB | マルチリージョン書き込み |
| Virtual Machines | Azure Site Recovery |
| Traffic Manager | DNSベースのトラフィックルーティング |
| Azure Resource Manager | IaCによるインフラ管理 |
Google Cloud
| サービス | DR関連機能 |
|---|---|
| Cloud Storage | マルチリージョンバケット |
| Cloud SQL | クロスリージョンリードレプリカ |
| Cloud Spanner | グローバル分散データベース（マルチリージョン標準） |
| Compute Engine | マシンイメージのリージョン間コピー |
| Cloud DNS | ヘルスチェック + ルーティングポリシー |
| Deployment Manager / Terraform | IaCによるインフラ管理 |
DR設計の実践ステップ
ステップ1: ビジネスインパクト分析（BIA）
各システム・サービスが停止した場合のビジネスへの影響を定量的に評価する。
- 売上損失（1時間あたり、1日あたり）
- 顧客への影響（SLA違反、信頼性低下）
- 法規制への影響（報告義務、罰則）
- ブランドへの影響（報道リスク、競合への流出）
BIAの結果に基づいて、システムごとにRPO/RTOを設定する。全システムに同一のRPO/RTOを適用するのではなく、ビジネスクリティカルなシステムには高い可用性を、それ以外のシステムにはコスト効率を重視した設計を行う。
ステップ2: DR構成の選定
ステップ1で定義したRPO/RTOと予算のバランスを踏まえて、4つのDRパターンから適切な構成を選定する。
多くの中小企業では、基幹システムにはパイロットライトまたはウォームスタンバイ、その他のシステムにはバックアップ & リストアという組み合わせが現実的だ。
ステップ3: インフラのコード化（IaC）
DRリージョンでのシステム復元を迅速かつ正確に行うために、インフラ構成をコードで管理する。Terraform、AWS CloudFormation、Azure Resource Managerテンプレートを活用し、本番環境と同一の構成をDRリージョンに再現できるようにする。
ステップ4: データレプリケーションの設定
データベースのレプリケーション、ストレージのクロスリージョンコピーを設定する。同期レプリケーションと非同期レプリケーションのトレードオフ（整合性 vs. パフォーマンス）を理解したうえで選択する。
ステップ5: フェイルオーバーの自動化
DNSフェイルオーバー、ロードバランサーのヘルスチェック、自動スケーリングの設定を行い、障害検知からフェイルオーバーまでの自動化を実現する。手動オペレーションが多いほど、復旧時間は延び、人的ミスのリスクも高まる。
ステップ6: DR訓練の定期実施
DR計画は、定期的な訓練（DRテスト）を行わなければ机上の空論に終わる。以下の訓練を最低でも年2回実施する。
- テーブルトップ演習: 関係者が集まり、障害シナリオに沿って手順を確認する
- フェイルオーバーテスト: 実際にDRリージョンへのフェイルオーバーを実行し、復旧手順の正確性と所要時間を計測する
- フェイルバックテスト: DRリージョンから本番リージョンへの切り戻し手順を確認する
DR設計でよくある失敗
失敗1: バックアップの復元テストをしていない
バックアップは取得しているが、そのバックアップから実際にシステムを復元したことがないケースは驚くほど多い。バックアップが破損している、復元手順が文書化されていない、復元に想定以上の時間がかかるといった問題は、テストして初めて発覚する。
失敗2: DNS TTLが長すぎる
DNSフェイルオーバーを計画しているにもかかわらず、DNS レコードのTTL（Time To Live）が長時間に設定されている場合、フェイルオーバー後もクライアントが旧IPアドレスにアクセスし続ける。DR対象のドメインはTTLを60～300秒に短縮しておく。
失敗3: DRリージョンのキャパシティを確保していない
大規模災害時には、同じリージョンにDR環境を構築している企業が一斉にリソースを確保しようとするため、リソースが枯渇する可能性がある。AWSのReserved InstancesやCapacity Reservationsを活用して、DRリージョンのキャパシティを事前に確保しておく。
失敗4: アプリケーション層の考慮が不足している
データベースのレプリケーションにばかり注目し、アプリケーション層のフェイルオーバー設計を怠るケースがある。セッション管理、キャッシュの整合性、外部API接続先の切り替えなど、アプリケーション層で必要な対応も網羅的に設計する。
コスト最適化のポイント
DR環境のコストを最適化するためのポイントを示す。
- システムの重要度に応じた段階設計: 全システムに高い可用性を求めるのではなく、ティア分けしてDR方式を使い分ける
- スポットインスタンス / プリエンプティブルVMの活用: DR訓練時のインスタンスにはスポットインスタンスを活用してコストを抑える
- IaCによる自動化: 手動復旧の工数を削減し、人件費を最適化する
- クラウドネイティブサービスの活用: マネージドサービスのマルチAZ対応を活用し、自前での冗長構成を減らす
- 定期的なコストレビュー: DR環境のリソースが過剰になっていないか、四半期ごとに見直す
まとめ
クラウドDR設計は、RPO/RTOの定義から始まる。ビジネスインパクト分析に基づいて適切なRPO/RTOを設定し、コストとのバランスを取りながらDR構成パターンを選定する。
設計したDR計画は、定期的な訓練で実効性を検証し、継続的に改善していくことが不可欠だ。「計画を作って安心」ではなく、「訓練して安心」の状態を目指すべきである。
DR設計の無料相談
「自社のシステムに適切なDR構成が分からない」「RPO/RTOの設定基準を知りたい」「マルチリージョン構成のコスト試算を依頼したい」――そのようなお悩みがありましたら、GXOにご相談ください。御社のシステム構成とビジネス要件を踏まえた最適なDR設計をご提案します。
※ 営業電話はしません | オンライン対応可 | 相談だけでもOK
GXO実務追記: システム開発・DX投資で発注前に確認すべきこと
この記事のテーマは、単なるトレンド紹介ではなく、要件定義、費用、開発体制、ベンダー選定、保守運用を決めるための検討材料です。検索で情報収集している段階でも、発注前に次の観点を整理しておくと、見積もりのブレ、手戻り、ベンダー依存を減らせます。
まず決めるべき3つの論点
| 論点 | 確認する内容 | 未整理のまま進めた場合のリスク |
|---|---|---|
| 目的 | 売上拡大、工数削減、リスク低減、顧客体験改善のどれを優先するか | 成果指標が曖昧になり、PoCや開発が終わっても投資判断できない |
| 範囲 | 対象部署、対象業務、対象データ、対象システムをどこまで含めるか | 見積もりが膨らむ、または重要な連携が後から漏れる |
| 体制 | 自社責任者、現場担当、ベンダー、保守運用者をどう置くか | 要件確認が遅れ、納期遅延や品質低下につながる |
費用・期間・体制の目安
| フェーズ | 期間目安 | 主な成果物 | GXOが見るポイント |
|---|---|---|---|
| 事前診断 | 1〜2週間 | 課題整理、現行確認、投資判断メモ | 目的と範囲が商談前に整理されているか |
| 要件定義 / 設計 | 3〜6週間 | 要件一覧、RFP、概算見積、ロードマップ | 見積比較できる粒度になっているか |
| PoC / MVP | 1〜3ヶ月 | 検証環境、効果測定、リスク評価 | 本番化判断に必要な数値が取れるか |
| 本番導入 | 3〜6ヶ月 | 本番環境、運用設計、教育、改善計画 | 導入後の運用責任と改善サイクルがあるか |
発注前チェックリスト
- [ ] 発注前に目的、対象業務、利用者、現行課題を1枚に整理したか
- [ ] 必須要件、将来要件、今回はやらない要件を分けたか
- [ ] 見積比較で、開発費だけでなく保守費、運用費、追加改修費を見たか
- [ ] ベンダー選定で、体制、実績、品質管理、セキュリティ、引継ぎ条件を確認したか
- [ ] 検収条件を機能、性能、セキュリティ、ドキュメントで定義したか
- [ ] リリース後3ヶ月の改善運用と責任分界を決めたか
参考にすべき一次情報・公的情報
上記の一次情報は、社内稟議やベンダー比較の根拠として使えます。一方で、公開情報だけでは自社の現行システム、業務フロー、データ状態、予算制約までは判断できません。記事で一般論を把握した後は、自社条件に落とした診断が必要です。
GXOに相談するタイミング
次のいずれかに当てはまる場合は、記事を読み進めるだけでなく、早めに相談した方が安全です。
- 見積もり依頼前に、要件やRFPの粒度を整えたい
- 既存ベンダーの提案が妥当か第三者視点で確認したい
- 補助金、AI、セキュリティ、レガシー刷新が絡み、判断軸が複雑になっている
- 社内稟議で費用対効果、リスク、ロードマップを説明する必要がある
- PoCや診断で終わらせず、本番導入と運用改善まで進めたい
クラウドDR（災害復旧）設計ガイド｜マルチリージョン構成とRPO/RTOの最適化を自社条件で診断したい方へ
GXOが、現状整理、RFP/要件定義、費用対効果、ベンダー比較、導入ロードマップまで実務目線で確認します。記事の一般論を、自社の投資判断に使える形へ落とし込みます。
※ 初回相談では営業資料の説明よりも、現状・課題・判断材料の整理を優先します。