はじめに
目的
本ドキュメントは、AWSを用いたディザスタリカバリー（災害復旧）の基本と実践をわかりやすくまとめたガイドです。クラウド環境での停止やデータ損失に備える方法を、具体例を交えて丁寧に解説します。
対象読者
システム運用者、開発者、または事業継続計画（BCP）に関心のある管理者を想定しています。専門知識が浅い方でも理解できるように説明します。
本書で扱う内容
・AWSディザスタリカバリーの定義と重要性
・主要な指標（RTO、RPO）の意味と使い方
・代表的な戦略（バックアップとリストア、パイロットライト、ウォームスタンバイ、マルチサイトなど）の特徴、利点、欠点、実装のポイント
各章で事例や短い手順を示します。
読み方のガイド
まず第2章で基本を押さし、第3章で指標の見極め方を学んでください。その後、各戦略の章で自社に合う方法を比較すると効率的です。
注意事項
本書は設計の考え方と実装のヒントを中心に記載します。導入時は実際の要件やコスト、運用体制を検討してください。
AWSディザスタリカバリーの定義と重要性
定義
AWSディザスタリカバリーとは、AWS上で稼働するシステムやデータを障害から守り、業務をできるだけ早く復旧させるための設計や運用の総称です。ネットワークやサーバーの停止、データ消失、地域的な災害などに備えます。
目的と効果
目的は、業務停止時間とデータ損失を最小限に抑えることです。具体例として、ECサイトがダウンした場合に別リージョンへ切り替え、数分で販売を再開する、といった対応を可能にします。これにより損失や信用低下を防げます。
なぜ重要か
事業継続は企業価値に直結します。短時間で復旧できれば顧客への影響を減らせますし、法令や契約で求められる可用性を満たせます。中小企業でもクラウドの利点を活かして低コストで対策できます。
AWSの特徴と具体例
AWSはリージョンやアベイラビリティゾーン（AZ）を提供し、データの複製や自動起動が可能です。例えばS3でデータの複製を行い、EC2のAMIを事前に作っておくことでリカバリを迅速化できます。
主要な指標 – RTO（Recovery Time Objective）とRPO（Recovery Point Objective）
定義
- RTO（復旧目標時間）: サービス停止から復旧までに許容できる最大の時間です。たとえばECサイトなら「ダウンしてから10分以内に復旧する」がRTOになります。
- RPO（復旧ポイント目標）: データの許容損失量を時間で表します。例えば「最悪でも5分分の取引データは失ってよい」がRPOです。
具体例で考える
- Webサーバー: RTOは数分、RPOは数秒〜数分と短く設定する場合が多いです。
- バッチ処理やログ解析: RTOは数時間、RPOは数時間でも許容されることがあります。
AWS Elastic Disaster Recoveryでの改善
Elastic Disaster Recoveryは継続的にレプリケーションします。これによりRPOを秒単位まで短くできます。フェイルオーバー手順を自動化すると、RTOは分単位に短縮できます。具体的には、ターゲット環境の事前準備、差分同期、起動オーケストレーションで時間を削減します。
設定と運用のポイント
- ビジネス影響で優先順位を決め、重要なサービスに短いRTO/RPOを割り当てます。
- 定期的にリカバリーテストを行い、実際の復旧時間を測定します。
- コストとリスクのバランスを見て目標値を調整します。テストで想定より時間がかかれば設定を見直します。
測定方法
復旧手順を実際に実行して時間を計測します。ログや監視でデータ同期の遅れを確認し、RPO超過がないか監視します。
バックアップとリストア戦略
概要
バックアップとリストア戦略は、定期的にデータのコピーを取り、障害時にそのコピーから復元するシンプルで費用効果の高い方法です。運用中のデータを安全に保ちつつ、災害からの復旧を目指します。
実装の主要要素
- 継続的または定期的なバックアップ（スナップショットやファイルレベル）。
- バックアップの保存場所を分散（別リージョンやオブジェクトストレージ）。
- 自動化された復元手順と実行手順書（プレイブック）。
- バックアップの整合性と暗号化、アクセス制御。
具体的な手順例
- 業務に応じてバックアップ頻度を決める（例：重要DBは毎15分、アプリ設定は毎日）。
- バックアップを自動化し、別リージョンに複製する。
- 定期的にリストアテストを実施し、復旧時間を計測する。
- 復旧手順を文書化し、担当者を訓練する。
メリットと制約
コストを抑えつつ確実にデータを保護できます。一方、障害時は新しい環境のプロビジョニングが完了するまで運用環境が使えない期間が生じますし、最後のバックアップ以降のデータは失われる可能性があります。復旧時間とデータ損失の許容度に合わせて頻度や自動化を設計してください。
パイロットライト戦略
概要
パイロットライト戦略は、DR（災害復旧）用の最小限の環境を常時稼働させ、プライマリ環境からデータを定期的に同期する方式です。平常時は軽量稼働にとどめ、障害発生時にリソースを素早く拡張して本番化します。
仕組み（簡単な流れ）
- 最小構成をDRに常時配置（小さなデータベースコピーやネットワーク設定など）。
- データを差分で同期（レプリケーションや増分バックアップ）。
- 障害時にDR側でインスタンスを追加・スケールし、DNSやロードバランサを切替えて稼働させます。
メリット
- コストを抑えつつ迅速な復旧が図れます。
- 完全な待機系を用意するより運用負荷が軽くなります。
- 定期テストで復旧手順を検証しやすいです。
注意点
- RTO（復旧時間）とRPO（復旧ポイント）の目標に合わせ、同期頻度や準備リソースを決めます。
- 起動順や依存関係の自動化が重要です。手作業だと復旧が遅れます。
- ネットワーク帯域やデータ整合性の確認を定期的に行ってください。
実践の簡単な手順
- 重要なコンポーネントを洗い出して、DRでの最小構成を決定します。
- データ同期方法を選び、スケジュールやモニタを設定します。
- 自動化スクリプトやテンプレートを用意して起動手順を標準化します。
- 定期的にフェイルオーバーテストを実施し、手順と性能を検証します。
- 運用中は同期状況とコストを見直し、目標に合わせて調整します。
適用例
- 中規模のウェブアプリやデータベースで、完全な二重化はコスト面で難しいが迅速復旧が必要な場合に向きます。
ウォームスタンバイ戦略
概要
ウォームスタンバイは本番と同じ構成をDR（災害復旧）地域に常時稼働させ、データを継続的に受け取る方式です。トラフィックは普段は本番に流れますが、災害時に素早くスタンバイへ切り替えてダウンタイムを小さくします。
主な構成要素（例）
- データ同期：RDSのクロスリージョンリードレプリカを作成し、障害時に昇格して書き込み可能にします。S3はクロスリージョンレプリケーション(CRR)、DynamoDBはグローバルテーブルを使います。
- アプリケーション：DR側で最小限のインスタンス群を常時稼働させます。トラフィック発生時に自動でスケールアップできるようにします。
- ネットワークとDNS：Route 53のヘルスチェックやフェイルオーバールールでトラフィックを切り替えます。
導入手順（簡潔）
- 本番と同等のネットワーク、IAM、設定をDRに用意します。2. データを継続的に複製します（RDS/DynamoDB/S3等）。3. アプリケーションをスモールキャパシティで稼働させ、正常性を監視します。4. フェイルオーバー手順を自動化し、DNS切替やインスタンス増強を準備します。
運用とテスト
定期的にフェイルオーバー訓練を実施し、復旧時間やデータ整合性を検証します。CloudWatchで性能とレプリケーション遅延を監視し、手順書を常に最新に保ちます。
メリット・デメリット
メリット：迅速な復旧が可能で、完全なホットサイトより費用を抑えられます。データ損失を小さくできます。
デメリット：パイロットライトよりコストは高く、運用の手間が増えます。設計と定期テストが必須です。
マルチサイト（ホットスタンバイ）戦略
概要
マルチサイト（ホットスタンバイ）は、本番と同等の環境を複数の場所で常時稼働させる方法です。障害が発生しても即時に切り替えられるため、ほぼダウンタイムがありません。最短のRTOとRPOを実現しますが、コストは高くなります。
主な利点
- 即時復旧：トラブル発生時にほぼ継続稼働が可能です。
- データ整合性：リアルタイムでデータを複製するため、データ損失がほとんどありません。
- 負荷分散の余地：平時は負荷分散に利用でき、パフォーマンス向上に役立ちます。
欠点と注意点
- コストが高い：リソースを常時二重に持つため費用がかかります。
- 運用の複雑さ：設定や監視、定期テストが増えます。
- ネットワーク遅延：異なるリージョン間では遅延や帯域に注意が必要です。
設計のポイント（具体例を含む）
- データレプリケーション：データベースは同期または準同期レプリケーションを採用します。例）トランザクションの複製を用いて整合性を保ちます。
- 負荷分散とDNS：ロードバランサーやDNSのヘルスチェックで自動切り替えを準備します。例）健常なサイトへ即座にトラフィックを誘導します。
- 健康監視と自動化：監視ツールで状態を常時確認し、切り替え手順は自動化します。
- 定期テスト：障害を想定した切り替えテストを定期的に行い、手順と時間を検証します。
運用時のポイント
- コスト管理：使用率に合わせたリソース調整や予約インスタンスの活用を検討します。
- セキュリティとアクセス管理：両サイトで同等のセキュリティ設定を維持します。
- ドリルと手順書：担当者が即座に対応できるよう、手順書と役割を明確にします。
どんな場合に向くか
- ミッションクリティカルなサービスでダウンタイムをほぼ許容できない場合に最適です。
