AWSにおける障害復旧（Disaster Recovery: DR）とは
概要
- AWSのDRとは、システム障害やリージョン障害が発生しても、業務を早期に復旧・継続させるための設計戦略
- 目的は「可用性（Availability）と事業継続性（Business Continuity）」を両立すること
DR設計で重要な指標
| 用語 | 説明 | 例 |
|---|---|---|
| RTO（Recovery Time Objective） | システムをどれだけ早く復旧させるか（＝許容できるダウンタイム） | 1時間以内に復旧 |
| RPO（Recovery Point Objective） | どこまでのデータ損失を許容できるか（＝バックアップの間隔） | 15分前までのデータを保持 |
AWSの4つの代表的なDR戦略
AWSでは、コストと復旧速度のバランスに応じて4つのレベルのDR戦略が定義されています。
| 戦略 | 概要 | コスト | 復旧速度（RTO） |
|---|---|---|---|
| ① バックアップ＆リストア | データを定期的にバックアップして、災害時に新環境へ復元 | 低 | 数時間〜数日 |
| ② パイロットライト | 最小限の構成を常に稼働させ、災害時に必要リソースを起動して拡張 | 中 | 数十分〜数時間 |
| ③ ウォームスタンバイ | 本番と同等の環境を縮小スケールで常時稼働、災害時にスケールアップ | 高 | 数分〜数十分 |
| ④ マルチサイト（アクティブ-アクティブ） | 複数リージョンに本番環境を完全複製して同時稼働 | 非常に高 | 秒〜分 |
① バックアップ＆リストア（Backup and Restore）
概要
最も基本的なDR戦略
平常時はコストを最小限にし、S3やGlacierにバックアップを保存しておき、障害発生時に新たな環境を立ち上げて復旧
特徴
- コスト最安
- 復旧まで時間がかかる（RTOが長い）
RTO/RPO目安
- RTO：数時間〜数日
- RPO：バックアップ頻度次第（例：1日）
② パイロットライト（Pilot Light）
概要
本番システムの最小限の重要部分（例：DBやコアアプリ）だけを常時稼働させておき、
災害時に周辺サービス（Webサーバー、ロードバランサーなど）を起動して拡張
特徴
- 最小限コストで迅速な復旧が可能
- 本番と同じ構成を素早く起動できる
- 完全復旧までは追加の起動作業が必要
RTO/RPO目安
- RTO：数十分〜数時間
- RPO：数分〜1時間（DBレプリカによる）
③ ウォームスタンバイ（Warm Standby）
概要
本番と同様の環境を縮小スケールで常時稼働させ、障害発生時にスケールアップして即時切替可能な状態
特徴
- 復旧が速い（RTOが短い）
- 本番と同等の構成を保持
- コストは中〜高
RTO/RPO目安
- RTO：数分〜数十分
- RPO：数分以内（レプリケーション）
④ マルチサイト / アクティブ-アクティブ（Multi-Site / Active-Active）
概要
複数リージョンで本番環境を同時稼働させ、トラフィックを分散
障害発生時はDNSルーティング（Route53）やGlobal Acceleratorで自動的に切り替え
特徴
- 復旧不要（常時稼働）
- 最短RTO/RPO
- コスト最も高い
- ミッションクリティカルなサービスに最適
RTO/RPO目安
- RTO：数秒〜数分
- RPO：ほぼ0
戦略選定の考え方
| 要件 | 最適戦略 |
|---|---|
| コスト重視、ダウンタイム許容 | バックアップ＆リストア |
| 最低限の可用性を確保したい | パイロットライト |
| 迅速な切替が求められる | ウォームスタンバイ |
| 極めて高い可用性が必要 | マルチサイト |
まとめ
| ケース | 方向性 |
|---|---|
| 「コストを最小化しつつ、DRを実現したい」 | バックアップ＆リストア or パイロットライト |
| 「最小限の構成を常時稼働、障害時にスケールアップ」 | パイロットライト |
| 「別リージョンに小規模環境を常時稼働」 | ウォームスタンバイ |
| 「完全なアクティブ-アクティブ」 | マルチサイト |
| 「RTO/RPOを最も短くしたい」 | マルチサイト |
| 「Vault LockやS3クロスリージョンでデータ保護」 | バックアップ＆リストアの一部 |