AWS Elastic Disaster Recovery を災害対策で理解しよう

🤔 AWS Elastic Disaster Recovery って何？

📝 簡単に言うと...

会社のサーバーや大事なデータ を、 AWS に 常時バックアップ しておき、災害が起きた時に すぐに代替システムを起動 できるサービスです

🏠 災害対策の例

本社ビル で火災や地震が発生！
📋 事前に準備 した 避難所 で
すぐに業務を再開したい

👆 普段から準備が必要...
🏭 緊急避難所 を用意しよう！

☁️ AWSの世界

会社のサーバー で障害が発生！
💻 事前にコピー した AWS上のサーバー で
すぐにシステムを復旧したい

👆 普段から準備が必要...
☁️ AWS EDR を使おう！

🏢 災害復旧のシナリオを見てみよう

⚡ 災害発生から復旧までの流れ

🏢

平常時

本社で正常運営
AWS EDRが
常時データを
バックアップ中

📊 毎分データ同期

🔥

災害発生

サーバー停止
本社のシステムが
使えなくなった！

⚠️ 緊急事態発生

🚀

EDR起動

AWS上で復旧開始
バックアップから
システムを起動

⏱️ 数分〜数時間

✅

復旧完了

業務再開
AWS上で
通常通り運営

🎯 目標時間内復旧

💡 災害対策のポイント

常時バックアップ → 災害発生 → ワンクリック復旧 → 業務継続

🏗️ AWS EDRの4つの重要な要素

👨‍💼

レプリケーションエージェント
= 専属コピー係

源データの監視役 です。
書類整理係のように、 本社の重要書類 （データ）を
常時チェック して変更があるたびに
避難所に 最新版をコピー します。

特徴: 24時間365日監視
頻度: リアルタイム同期

🏭

ステージングエリア
= 避難所の準備倉庫

緊急時の準備場所 です。
避難所の倉庫のように、
本社からコピーした書類やデータを
すぐに使える状態 で保管します。

役割: データの一時保管
状態: 即座に起動可能

🏢

リカバリインスタンス
= 緊急時の代替オフィス

実際の業務継続場所 です。
避難所の仮設オフィスのように、
災害時に 実際の業務 を行う
代替システム が動く場所です。

機能: 本格的な業務継続
性能: 本社と同等

📋

コンソール
= 災害対策本部

災害対応の司令塔 です。
災害対策本部のように、
復旧作業の進捗 を監視し、
ワンクリック で復旧を開始します。

操作: 簡単な画面操作
監視: リアルタイム状況確認

🔄 システム構成を図で見てみよう

📊 AWS EDR の全体像

🏢

本社システム

ソースシステム

物理サーバー / VMware
Windows / Linux

→ 📋

常時監視・コピー

👨‍💼

レプリケーション
エージェント

コピー係

変更を即座に検知
最小限のデータ転送

↓ 🌐

インターネット経由でAWSへ

🏭

ステージングエリア

準備倉庫

低コストインスタンス
t3.micro / t3.small

→ 🚀

災害時に変換

🏢

リカバリ
インスタンス

代替オフィス

本格的な性能
m5.large / c5.xlarge

⚡ データの流れ

本社システム → エージェント監視 → 変更分をAWSに送信 → ステージングに保存 → 災害時にリカバリインスタンス起動

⏱️ RTO・RPOって何？復旧目標を理解しよう

🎯 災害復旧の2つの重要な目標

⏰

RTO (Recovery Time Objective)

= 復旧時間目標

🏢 災害対策の例:
「火災から何時間で
代替オフィスで業務再開？」

💻 AWS EDRの場合:
「システム障害から
何分で復旧完了？」

AWS EDRの目標:
⚡ 数分〜数時間

📊

RPO (Recovery Point Objective)

= 復旧ポイント目標

🏢 災害対策の例:
「最大何時間前のデータまで
失ってもOK？」

💻 AWS EDRの場合:
「最大何分前のデータまで
失ってもOK？」

AWS EDRの目標:
📈 数秒〜数分

💡 具体的な例で理解しよう

📋 シナリオ: 朝10:00にサーバー障害発生

⏰ RTO = 2時間の場合:

12:00（正午）までに復旧完了が目標
AWS EDRで実際は10:15には復旧（大幅にクリア！）

📊 RPO = 15分の場合:

9:45以降のデータは復旧できればOK
AWS EDRなら9:59のデータまで復旧可能（余裕でクリア！）

💰 コスト比較 - 従来の災害対策 vs AWS EDR

💸 どのくらいお得？

🏢

従来のDR

物理的な代替サイト

💰 初期費用:

データセンター構築: 数千万円〜
機器購入: 数百万円〜
ネットワーク構築: 数百万円

🔄 運用費用:

月額賃料: 50万円〜
保守費用: 20万円〜/月
人件費: 30万円〜/月

総額: 年間数千万円

☁️

AWS EDR

クラウド型DR

💰 初期費用:

セットアップ: 0円
機器購入: 0円
設定作業: 数日

🔄 運用費用:

ステージング: 3〜10万円/月
データ転送: 1〜5万円/月
復旧時のみ: 本格料金

総額: 年間50〜200万円

❌

災害対策なし

何も備えない場合

💰 平常時費用:

DR関連: 0円
備え: なし

⚠️ 災害時リスク:

業務停止: 数日〜数週間
売上損失: 数千万円〜
信用失墜: プライスレス
復旧作業: 数百万円〜

リスク: 計り知れない損失

       🎯 AWS EDRの圧倒的メリット
      
         💰 コスト面
        
          初期費用:
          
           ほぼ0円
          
          運用費用:
          
           従来の1/10以下
          
          使った分だけ課金
         
         ⚡ 技術面
        
          設定:
          
           数時間〜数日
          
          復旧:
          
           数分〜数時間
          
          管理:
          
           GUI操作のみ

📋 実際の設定手順（超簡単版）

1

避難計画の策定

AWS EDRの初期設定
→ 災害対策本部（AWSコンソール）にアクセス
→ 「何を」「どこに」「どのくらいの頻度で」バックアップするかを決定
→ レプリケーション設定テンプレートを作成

2

コピー係を本社に配置

レプリケーションエージェントをインストール
→ 保護したいサーバーに「コピー係」ソフトウェアをインストール
→ エージェントがAWSとの通信チャネルを確立
→ 初回の完全バックアップを開始（数時間〜1日）

3

避難所の準備

ステージングエリアの自動構築
→ AWS上に「準備倉庫」が自動的に作成される
→ 低コストなインスタンスで常時データを同期
→ 変更差分のみを継続的にレプリケーション

4

避難訓練の実施

復旧テストの実行
→ 「テスト復旧」機能で実際の復旧手順を確認
→ 本番環境に影響なしで復旧時間を測定
→ 問題があれば設定を調整

5

緊急時の対応準備

フェイルオーバー計画の準備
→ 災害発生時の担当者と連絡手順を決定
→ ワンクリック復旧の手順書を作成
→ 社内への通知方法を準備

6

災害対策完了！

24時間365日の保護開始
→ コピー係が常時監視・バックアップを実行
→ 災害発生時はワンクリックで復旧開始
→ 安心して本業に集中できる環境が完成

❓ よくある質問

🤔 どんなシステムが対象になるの？

⚡ 復旧にはどのくらい時間がかかるの？

💰 料金体系はどうなってるの？

🔧 設定は本当に簡単？

🌍 どこのリージョンを選べばいい？

✨ AWS EDRの主要メリット

⚡

圧倒的な高速復旧

従来の数日〜数週間から、数分〜数時間に短縮

💰

大幅なコスト削減

従来の災害対策の1/10以下のコストで本格的なDRを実現

🔧

簡単設定・管理

ウィザード形式の設定と直感的な管理画面

🌐

幅広い対応環境

物理、VMware、他クラウドからの移行が可能

🔄

継続的レプリケーション

リアルタイムに近い同期でデータ損失を最小化

🧪

非破壊テスト

本番に影響なしで復旧手順を定期的にテスト可能

📊

可視化・監視

レプリケーション状況をリアルタイムで監視

🎯

柔軟な復旧オプション

テスト、フェイルオーバー、フェイルバックを自由に選択

🎯 まとめ

👨‍💼 レプリケーションエージェント = 専属コピー係（常時データ監視）

🏭 ステージングエリア = 避難所の準備倉庫（低コストで待機）

🏢 リカバリインスタンス = 緊急時の代替オフィス（本格業務継続）

📋 EDRコンソール = 災害対策本部（ワンクリック復旧）

この4つが連携することで、 数分で業務継続 を実現します！

🎯 AWS EDRで得られるもの：

💰 従来の1/10のコストで本格的な災害対策
⚡ 数分〜数時間での超高速復旧
😌 24時間365日の安心感
🎯 ビジネス継続性の大幅向上

💡 次のステップ: まずは小さなシステムから始めて、徐々に保護範囲を拡大しましょう！

目次