AWS Elastic Disaster Recovery (DRS) は、EC2 / オンプレミスサーバーを別リージョンに低コストで継続レプリケート する DR サービスです。従来の CloudEndure DR を統合し、AWS ネイティブの操作性を提供します。本記事では DRS の仕組みと設計を SAA / SAP 両面から整理します。

SAA レベル：基礎概念

DRS とは何か

DRS は ブロックレベルの継続レプリケーション で、サーバーのディスク全体を別リージョンに複製します。

対象: EC2 インスタンス、オンプレミスサーバー（物理/仮想）
方式: ブロックレベルの非同期レプリケーション
RPO: 数秒〜数分
RTO: 数分（復旧インスタンスの起動）
コスト: 復旧料金 + リソース料金（常時稼働不要）

SAA レベル：基礎概念

DRS の核心は 「ブロックレベルで継続レプリケートし、障害時に素早く別リージョンで復旧」 です。アプリ全体を丸ごと複製するため、アプリ構成が複雑でも対応可能。 SAA では「EC2/オンプレの低成本 DR」として押さえます。

DRS のアーキテクチャ

[ソース (プライマリ)]
  EC2 / オンプレサーバー
    │
    │ DRS エージェント (ブロックレベル複製)
    ▼
[DR リージョン (スタンバイ)]
  EBS スナップショット (継続更新)
  + リカバリインスタンス (停止状態で保持)

# 障害時
[DR リージョン] でリカバリインスタンスを起動 → サービス再開

構成要素	説明
DRS エージェント	ソースサーバーにインストール、ブロック変更を転送
リカバリポイント	レプリケートされた復旧可能な時点
リカバリインスタンス	DR リージョンに保持される復旧用 EC2
ソースサーバー	レプリケート元の EC2 / オンプレ

復旧ポイントと RPO

DRS は 定期的に復旧ポイント (Recovery Point) を作成します。

連続レプリケート: ブロック変更を継続転送
復旧ポイント: 数分ごとに作成される復旧可能な時点
RPO: 最後の復旧ポイントから障害時点までの時間
ポイントインタイム復旧: 過去の任意の復旧ポイントに復元可能

SAA 試験のポイント

DRS は 「連続レプリケーション + 定期復旧ポイント」 で RPO を数秒〜分に短縮します。「過去の特定時点に復元したい」場合は、復旧ポイントを選んで復元。 SAA では「RPO 数秒〜分、RTO 数分」が DRS の代表性能値として問われます。

SAP レベル：高度な設計シナリオ

DRS の適用判断

SAP では DRS と他の DR 手法の使い分け が論点です。

SAP レベル：高度な設計シナリオ

SAP の DRS 適用判断は 「アプリを変更せずに EC2/オンプレを DR したい」 場合に選びます。

DRS: EC2 / オンプレのブロックレベル複製（アプリ変更不要）
Aurora Global DB: Aurora ベースの DB のみ DR
DynamoDB Global Tables: DynamoDB ベースのマルチサイトこれらを使い分ける能力が SAP の核心です。

シナリオ	推奨 DR 手法	理由
既存 EC2 アプリの低成本 DR	DRS	アプリ変更不要
Aurora ベースアプリの DR	Aurora Global DB	ネイティブ機能が最適
DynamoDB アプリのマルチサイト	DynamoDB Global Tables	双方向レプリケーション
オンプレミスの AWS への DR	DRS	エージェントで実現

オンプレミスから AWS への DR

DRS は オンプレミスサーバーを AWS に DR する用途でも強力です。

エージェントインストール: 物理サーバー / VMware / Hyper-V に対応
AWS へのレプリケート: ブロック変更を継続 AWS 転送
復旧時の変換: オンプレのディスク構成を AWS の EBS / EC2 に変換
フェイルバック: AWS からオンプレへの復帰もサポート

オンプレ DR の利点

DRS は 「オンプレのアプリを変更せずに AWS に DR」 できます。従来の「オンプレ専用 DR 拠点」を構築するより大幅にコスト削減。 SAP では「オンプレ → AWS DR 移行」のシナリオで DRS が頻出します。

復旧ポイントの管理

DRS の復旧ポイントは 保持期間 で管理します。

設定	説明	設計論点
保持期間	復旧ポイントの保管期間	コスト vs 復旧可能性
作成頻度	復旧ポイントの作成間隔	RPO に直結
ポイントインタイム	過去任意時点への復元	ランサムウェア対応

ランサムウェア対策の論点

DRS の復旧ポイントは ランサムウェア対策 にも有効です。「現行データが暗号化されたら、過去の復旧ポイントに戻す」で復旧可能。 SAP では「復旧ポイント保持期間を長め（30 日程度）」にするのがランサムウェア対策の定石です。

フェイルオーバーとフェイルバック

DRS は フェイルオーバー (本番→DR) とフェイルバック (DR→本番) の両方をサポートします。

# フェイルオーバー
[プライマリリージョン] ──(障害)── [DR リージョン]
                                    リカバリインスタンス起動
                                    → サービス再開

# フェイルバック
[DR リージョン] ──(プライマリ復旧)── [プライマリリージョン]
                                    逆レプリケーション
                                    → 切戻し

フェイルバックの設計

フェイルバックは DR 側の変更をプライマリに逆レプリケート するため、フェイルオーバー中のデータ更新も取り逃がしません。ただし 逆レプリケーションには時間がかかる ため、計画的な切戻しが前提。SAP の論点です。

DR 訓練とドライラン

DRS は ドライラン (Dry Run) で本番影響なしに復旧テストが可能です。

リカバリインスタンス起動: 実際に DR リージョンでインスタンス起動
本番影響なし: レプリケーション継続、本番は稼働したまま
復旧確認: 起動したインスタンスでアプリ動作確認
訓練後破棄: テスト完了でインスタンス削除

SAP レベル：高度な設計シナリオ

SAP の DR 訓練定石は 「DRS ドライランを定期実行」 です。「DR 手順が本当に動くか」を本番影響なしに確認できるため、半年に 1 回程度の定期訓練に最適。「訓練していない DR は DR ではない」が SAP の鉄則です。

コスト最適化設計

DRS のコスト構造と最適化：

コスト要素	説明	最適化
復旧料金	ソースサーバーごとの月額	対象サーバーの精査
EBS スナップショット	復旧ポイント保管	保持期間の適正化
リカバリインスタンス	復旧時のみ課金	常時起動しない
データ転送	レプリケーション通信	変更ブロックのみ転送で最小化

コスト最適化の要点

DRS は 「常時は復旧料金 + スナップショット保管のみ、復旧時にインスタンス起動料金」 の構造。マネージドサービス (Aurora/RDS) を使える場合はそちらの方が安い場合も。 SAP では「DRS vs マネージドサービス DR」のコスト比較が論点です。

ネットワーク設計

DRS の復旧時のネットワーク設計も重要です。

DR リージョンの VPC: 事前に構築しておく
ENI 設定: 復旧インスタンスに適切な ENI を割当
DNS 切替: Route 53 で DR リージョンへ切替
セキュリティグループ: DR 側の SG を事前準備

ネットワーク設計の落とし穴

「DR リージョンの VPC / SG / DNS 設定が未準備」 だと、復旧時に手間取る。 DRS はインスタンス復旧までだが、ネットワーク周りは別途設計が必要。 SAP では「DRS + ネットワーク IaC」のセット準備が定石です。

制約と考慮事項

項目	制約 / 注意
対象	EC2 / オンプレ (物理 / 仮想)
コンテナ	直接非対応（ECS/EKS は別途設計）
RPO	数秒〜分
RTO	数分
フェイルバック	逆レプリケーションで対応
対象 OS	Linux / Windows

まとめ

SAA: DRS はブロックレベルの継続レプリケーションで RPO 数秒〜分、RTO 数分、 EC2 / オンプレ対応、という基本を理解する。
SAP: DRS と他 DR 手法の使い分け、オンプレ→AWS DR、復旧ポイント管理、フェイルバック、定期 DR 訓練が求められる。

次は RTO と RPO で、DR 戦略の核心指標を深掘りします。