AWS Elastic Disaster Recovery（DRS）完全ガイド v2.0（2026年最新対応）

RTO分・RPO秒のブロックレベルレプリケーション・クラウドDR統合・低コスト実現

目次

• ドキュメントメタデータ
• 概要と課題
• アーキテクチャと設計原則
• コアコンポーネント
• 主要ユースケース
• 設定・操作の具体例
• 類似サービス比較表
• ベストプラクティス
• トラブルシューティング表
• 2025-2026最新動向
• 学習リソース・参考文献
• 実装例・チェックリスト
• まとめ

ドキュメントメタデータ

• 最終更新: 2026-04-26
• バージョン: v2.0
• 対象者: ディザスタリカバリ責任者、Infrastructure Manager、Cloud Architect
• 難易度: 上級
• 旧サービス: CloudEndure Disaster Recovery（2021 年に DRS に統合）
• 関連サービス: AWS Backup、Application Migration Service（MGN）、EC2、S3、EBS

概要と課題

本質

AWS Elastic Disaster Recovery（DRS） は 「オンプレミス・他クラウド・AWS のサーバーをリアルタイムにブロックレベルでレプリケーションし、分単位のフェイルオーバーで AWS にディザスタリカバリ（DR）を実現するマネージドサービス」 である。RTO（目標復旧時間）分単位・RPO（目標復旧ポイント）秒単位の攻撃的な DR 目標を低コストで実現し、従来の物理 DR サイト・ウォームスタンバイの維持コスト（サーバー・ネットワーク・ストレージ）を大幅に削減する。CloudEndure Disaster Recovery の後継サービス。

このサービスを選ぶ理由

なぜ AWS Elastic Disaster Recovery なのか？

1. 従来型 DR の圧倒的なコスト削減

   • 従来 DR 方式（ウォームスタンバイ）：DR サイトに本番同等のサーバーを常時稼働 本番 100 台 × 本番環境と同等の vCPU・メモリ × 24h × 365 日 = 年間数千万円
   • DRS 方式：エージェント + Replication Server（t3.small）+ EBS ストレージのみ 本番 100 台 × $0.028/時間 × 720 時間 + EBS 料金 ≈ 月額 $2,000 + EBS
   • コスト削減率：50～80%

2. 分単位の RTO と秒単位の RPO

   • 従来バックアップ DP（Backup・Restore）：RTO 数時間・RPO 数時間
   • DRS ブロックレベルの継続的レプリケーション：RTO 5～20 分・RPO 秒単位
   • 本番障害 → 数秒で AWS に自動フェイルオーバー可能

3. OS・ハイパーバイザー非依存

   • Replication Agent をインストールするだけで物理・仮想・クラウドのどのサーバーからも AWS にレプリケーション可能
   • 既存 hypervisor（VMware vSphere・Hyper-V・Xen）・OS（Windows・Linux・UNIX）に依存しない汎用的な DR ソリューション

4. DR テストが本番に影響しない

   • DR ドリル実行時に本番のレプリケーションを停止・遅延させない
   • テスト環境として Recovery Instance を起動し、本番環境は並行稼働
   • 定期的な DR 訓練を安全に実施でき、RTO・フェイルオーバー手順を事前検証

5. Reverse Replication（フェイルバック）で柔軟な復旧

   • 本番障害から AWS でフェイルオーバー後、本番環境修復時に逆方向レプリケーション開始
   • AWS → 本番環境への failback で、本番環境に復帰可能
   • 他クラウド（Azure・GCP）からの DR でマルチクラウド戦略実現

このサービスを選ばない理由

• RTO 数時間で十分 → AWS Backup（CCR）で十分
• オンプレミス拠点あり（同一施設内） → 物理バックアップが低コスト
• アプリ依存性複雑 → AWS Application Migration Service（MGN）+カスタマイズ

アーキテクチャと設計原則

全体構成図（Mermaid 1）

graph TB
    subgraph OnPrem["本番環境（オンプレ/他クラウド）"]
        SRV["Source Servers<br/>Windows/Linux<br/>Physical/Virtual"]
        AGENT["Replication Agent<br/>Block-level Change Capture"]
    end
    
    subgraph AWS["AWS（DR サイト）"]
        REP_SRV["Replication Servers<br/>(t3.small EC2)"]
        STAGING["Staging Area<br/>EBS Volume"]
        RECOVERY["Recovery Instances<br/>(フェイルオーバー時)"]
    end
    
    subgraph Network["ネットワーク・セキュリティ"]
        VPN["AWS VPN / Direct Connect<br/>暗号化通信"]
        SG["Security Groups<br/>45-forward only"]
    end
    
    SRV -->|Install Agent| AGENT
    AGENT -->|Block-level<br/>Continuous Replication| VPN
    VPN -->|TLS 1.2+| STAGING
    STAGING -->|Staged| REP_SRV
    REP_SRV -->|ドリル / 障害| RECOVERY
    
    RECOVERY -->|Optional Reverse<br/>Replication| STAGING
    STAGING -->|Copy back| SRV
    
    style AGENT fill:#e8f4f8
    style STAGING fill:#fff3cd
    style RECOVERY fill:#d4edda

ブロックレベルレプリケーションフロー

┌─ Source Server（本番）
│  ├─ Replication Agent インストール
│  ├─ ディスク変更をリアルタイムキャプチャ（block-level）
│  └─ TLS 暗号化で AWS に転送
│
├─ AWS Replication Server（ステージングエリア）
│  ├─ t3.small EC2（低コスト待機）
│  ├─ EBS ボリュームにレプリケーションデータ保管
│  └─ RPO 秒単位で同期維持
│
└─ フェイルオーバー実行時
   ├─ Recovery Instance 起動（EC2 + EBS）
   ├─ ステージング area の最新スナップショットから復元
   ├─ VPC・Subnet・Security Group を自動設定
   └─ 分単位で本番相当環境が AWS 上で起動完了

コアコンポーネント

1. Replication Agent（ソースサーバー側）

定義 本番サーバーにインストールするエージェント、ブロックレベルの変更をキャプチャ・AWS に送信

インストール方式

# Linux 用 Python スクリプト
wget https://aws-elastic-disaster-recovery-{region}.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py
sudo python3 aws-replication-installer-init.py \
  --region ap-northeast-1 \
  --aws-access-key-id AKIA... \
  --aws-secret-access-key ...

# Windows 用 PowerShell
# DownloadAndInstallAgent.ps1 をダウンロード → PowerShell で実行

# インストール後:
# - エージェント自動起動（systemd / Windows Service）
# - ブロックレベルの連続レプリケーション開始
# - DRS Console に "Server is Replicating" 表示

リソース要件

• CPU: 1 vCPU（エージェント CPU 使用率 2-5%）
• RAM: 128 MB 最小（推奨 512 MB）
• ネットワーク: 10 Mbps 最小（推奨 100 Mbps 以上）
• ディスク: 1 GB 最小（ローカルキャッシュ用）

2. Replication Configuration Template

定義 ソースサーバーのレプリケーション動作を制御する設定テンプレート

主要設定項目

- Staging Area Subnet: EBS ボリュームを配置する VPC・Subnet
- Replication Server Instance Type: t3.small（デフォルト・低コスト）/ m5.large など
- Use Dedicated Replication Server: false（共有） / true（専有）
- Bandwidth Throttling: 0（無制限） / 1~1000 Mbps（制限）
- Data Plane Routing: PRIVATE_IP（VPC 内） / PUBLIC_IP（インターネット経由）
- Create Public IP: false / true
- EBS Encryption: true（デフォルト・KMS 暗号化）
- Staging Area Tags: Environment=DR, Cost Center=...

3. Launch Configuration（リカバリー時の起動設定）

定義 フェイルオーバー・ドリル時に Recovery Instance がどう起動するか定義

設定内容

- Launch Disposition: STOPPED（停止したまま） / STARTED（起動状態）
- Target Instance Type Right Sizing: 
  BASIC（ソース同等） / MEDIUM / HIGH（アップサイジング）
- Copy Private IP: false（新規割り当て） / true（ソース IP 継承）
- Copy Tags: true（ソースタグをコピー）
- Licensing: 
  byol: false（AWS ライセンス） / true（ユーザー持ち込みライセンス）

- Post-Launch Actions:
  cloudWatchLogGroupName: /drs/recovery
  s3LogBucket: my-drs-logs
  actions: []  # カスタムスクリプト（Systems Manager Run Command など）

4. Recovery Instance（フェイルオーバー後）

定義 フェイルオーバー実行時に AWS 上で起動される EC2 インスタンス

自動設定項目

- Instance Name: {SourceServerName}-Recovery
- VPC / Subnet: 事前設定
- Security Groups: Launch Config で指定
- EBS Volumes: ステージングエリアから復元
- IAM Instance Profile: ユーザー指定
- CloudWatch Monitoring: 自動有効化

5. Recovery Plan（復旧計画・API Only）

定義 複数のソースサーバーをグループ化し、フェイルオーバー順序・Wave（段階）を定義 （Console UI は Wave 1 のみ、複数 Wave は API で定義）

例

{
  "recoveryPlanName": "prod-app-recovery",
  "sourceServerIDs": ["s-xxx", "s-yyy", "s-zzz"],
  "waves": [
    {
      "waveID": 1,
      "waveDelay": 0,
      "sourceServerIDs": ["s-xxx"]  // DB サーバーを最初に起動
    },
    {
      "waveID": 2,
      "waveDelay": 300,  // 5 分待機
      "sourceServerIDs": ["s-yyy", "s-zzz"]  // APP サーバーを次に起動
    }
  ]
}

主要ユースケース

1. オンプレミス基幹システムの分単位 DR（最一般的）

シナリオ データセンター障害 → RTO 15 分で AWS にフェイルオーバー → 本番業務継続

本番環境（オンプレ）:
  - Oracle Database 12c（ライセンス持ち込み）
  - 3 台の UNIX アプリサーバー
  - NAS ストレージ 2 TB

DR 要件: RTO 15 分・RPO 5 秒

DRS 構成:
  1. Oracle DB サーバーに Replication Agent インストール
  2. 3 台の APP サーバーに Replication Agent インストール
  3. 本番障害検知 → DRS Console で "Initiate Failover" クリック
  4. Recovery Instances 起動・EBS 復元（5 分）
  5. Network 切り替え・DNS 更新（5 分）
  6. 本番相当環境が AWS で稼働（15 分で完了）

2. データセンター段階的クラウド移行

シナリオ 本番環境のまま AWS レプリケーション開始 → テストして確認 → 本番環境を段階的に AWS に移行

Phase 1: テスト環境レプリケーション（ドリル）
  - DRS ドリル実行
  - Recovery Instance でアプリケーション動作確認
  - ドリル終了 → Recovery Instance 削除・本番は継続

Phase 2: Planned Failover（計画的フェイルオーバー）
  - 本番環境でのメンテナンスウィンドウ中に実施
  - DRS Failover 実行
  - データロス なし（RPO = 秒単位）

Phase 3: Cutover（本番切り替え）
  - AWS 上の Recovery Instance を本番環境に昇格
  - Reverse Replication で定期バックアップ継続

Phase 4: Failback（本番環境復帰・オプション）
  - AWS から オンプレ / 他クラウド に戻すことも可能

3. マルチクラウド DR（Azure / GCP から AWS へ）

シナリオ Azure に本番環境あり → AWS に DR 環境構築

Azure VM:
  - Windows Server 2019
  - SQL Server 2019
  - アプリケーション

AWS DRS:
  1. Azure VM に Replication Agent インストール
  2. AWS 側で Replication Configuration 設定（VPN または Direct Connect で接続）
  3. リアルタイムレプリケーション開始
  4. Azure リージョン障害 → AWS にフェイルオーバー

メリット:
  - Azure ライセンスの Windows / SQL Server をそのまま AWS で使用（BYOL）
  - Azure の本番環境ダウンタイムなし（パラレル稼働）

4-12. （その他 9 ユースケース省略）

設定・操作の具体例

CLI 操作（5 パターン）

1. DRS 初期化・Replication Configuration テンプレート作成

# DRS の初期化（リージョン ごと 1 回）
aws drs initialize-service \
  --region ap-northeast-1

# Replication Configuration Template を取得（デフォルトを確認）
aws drs describe-replication-configuration-templates \
  --region ap-northeast-1

# テンプレートを更新
TEMPLATE_ID=$(aws drs describe-replication-configuration-templates \
  --region ap-northeast-1 \
  --query 'items[0].replicationConfigurationTemplateID' \
  --output text)

aws drs update-replication-configuration-template \
  --replication-configuration-template-id $TEMPLATE_ID \
  --staging-area-subnet-id subnet-12345678 \
  --staging-area-tags Key=Environment,Value=DR-Staging \
  --replication-server-instance-type t3.small \
  --use-dedicated-replication-server false \
  --bandwidth-throttling 0 \
  --create-public-ip false \
  --data-plane-routing PRIVATE_IP \
  --ebs-encryption true \
  --region ap-northeast-1

2. Replication Agent インストール・監視（Linux）

# Step 1: インストーラースクリプトをダウンロード
wget -O /tmp/aws-replication-installer-init.py \
  https://aws-elastic-disaster-recovery-ap-northeast-1.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py

# Step 2: インストール実行（IAM credential が必要）
sudo python3 /tmp/aws-replication-installer-init.py \
  --region ap-northeast-1 \
  --aws-access-key-id AKIAIOSFODNN7EXAMPLE \
  --aws-secret-access-key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY \
  --no-prompt

# Step 3: インストール確認
sudo systemctl status aws-replication-agent

# Step 4: DRS Console で Source Server 確認（1～2 分）
aws drs describe-source-servers \
  --filters sourceServerIDs={} \
  --region ap-northeast-1

3. ドリル（テストフェイルオーバー）実行

# Source Server ID を取得
SERVER_ID=$(aws drs describe-source-servers \
  --query 'items[0].sourceServerID' \
  --output text \
  --region ap-northeast-1)

echo "Source Server ID: $SERVER_ID"

# Drill 開始（本番に影響なし）
aws drs start-recovery \
  --source-servers '{"sourceServerIDs": ["'$SERVER_ID'"]}' \
  --is-drill true \
  --tags Key=DrillDate,Value=$(date +%Y-%m-%d) \
  --region ap-northeast-1

# → Recovery Instances が起動開始（5～10 分）

# Status 確認
aws drs describe-recovery-instances \
  --filters sourceServerIDs={$SERVER_ID} \
  --query 'items[0].[recoveryInstanceID,status,launchStatus]' \
  --output table \
  --region ap-northeast-1

# Drill 終了（Recovery Instance 削除）
RECOVERY_ID=$(aws drs describe-recovery-instances \
  --filters sourceServerIDs={$SERVER_ID} \
  --query 'items[0].recoveryInstanceID' \
  --output text)

aws drs terminate-recovery-instances \
  --recovery-instance-ids $RECOVERY_ID \
  --region ap-northeast-1

4. 本番フェイルオーバー実行

# ⚠️ 本番障害発生時のみ実行

SERVER_ID="s-xxx"

# Failover 開始（is-drill: false）
aws drs start-recovery \
  --source-servers '{"sourceServerIDs": ["'$SERVER_ID'"]}' \
  --is-drill false \
  --region ap-northeast-1

# → Recovery Instance が本番環境として起動

# Status 監視
while true; do
  STATUS=$(aws drs describe-recovery-instances \
    --filters sourceServerIDs={$SERVER_ID} \
    --query 'items[0].launchStatus.status' \
    --output text \
    --region ap-northeast-1)
  
  echo "Status: $STATUS"
  
  if [ "$STATUS" = "LAUNCHED" ]; then
    echo "Recovery Instance ready!"
    break
  fi
  
  sleep 30
done

5. Failback（本番環境復帰）

# 本番環境修復後、AWS から本番環境に戻す

RECOVERY_ID="r-xxx"

# Failback Launch 開始
aws drs start-failback-launch \
  --recovery-instance-ids $RECOVERY_ID \
  --region ap-northeast-1

# Failback 完了後、Recovery Instance を削除
aws drs terminate-recovery-instances \
  --recovery-instance-ids $RECOVERY_ID \
  --region ap-northeast-1

# 本番環境のレプリケーション再開（AWS → オンプレ）
# 以降、AWS がセカンダリ DR サイトとして機能

SDK / Infrastructure as Code（5 パターン）

1. CloudFormation での DRS IAM Role 設定

AWSTemplateFormatVersion: '2010-09-09'

Resources:
  DRSServiceRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: drs.amazonaws.com
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSElasticDisasterRecoveryServiceRole

  DRSUserRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              AWS: !Sub 'arn:aws:iam::${AWS::AccountId}:root'
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AWSElasticDisasterRecoveryFullAccess

2. Terraform での DRS Setup

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "ap-northeast-1"
}

resource "aws_drs_replication_configuration_template" "example" {
  staging_area_subnet_id              = aws_subnet.staging.id
  replication_server_instance_type    = "t3.small"
  use_dedicated_replication_server    = false
  bandwidth_throttling                = 0
  create_public_ip                    = false
  data_plane_routing                  = "PRIVATE_IP"
  ebs_encryption                      = "DEFAULT"

  tags = {
    Name        = "drs-config"
    Environment = "Production"
  }
}

resource "aws_ec2_security_group" "drs_staging" {
  name        = "drs-staging-sg"
  description = "DRS Staging Area Security Group"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = [aws_vpc.main.cidr_block]
  }

  ingress {
    from_port   = 1500
    to_port     = 1500
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]  # Source servers からのレプリケーション
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "drs-staging"
  }
}

3. Python SDK（Boto3）での自動フェイルオーバー・復旧

import boto3
import time
from datetime import datetime

def initiate_drs_failover(source_server_id: str, is_drill: bool = False):
    """
    DRS Failover を開始（ドリル / 本番）
    """
    drs = boto3.client('drs')
    
    failover_type = "DRILL" if is_drill else "PRODUCTION"
    print(f"Initiating {failover_type} failover for server: {source_server_id}")
    
    try:
        response = drs.start_recovery(
            sourceServers=[{'sourceServerID': source_server_id}],
            isDrill=is_drill,
            tags={'FailoverType': failover_type, 'InitiatedAt': datetime.now().isoformat()}
        )
        
        print(f"Failover initiated: {response}")
        return response
    except Exception as e:
        print(f"Error initiating failover: {str(e)}")
        return None

def monitor_recovery_instance(source_server_id: str, max_wait_minutes: int = 30):
    """
    Recovery Instance の起動を監視
    """
    drs = boto3.client('drs')
    start_time = time.time()
    max_wait_seconds = max_wait_minutes * 60
    
    while True:
        try:
            response = drs.describe_recovery_instances(
                filters={'sourceServerIDs': [source_server_id]}
            )
            
            if not response['items']:
                print("No recovery instances found yet...")
                time.sleep(10)
                continue
            
            recovery_instance = response['items'][0]
            status = recovery_instance.get('launchStatus', {}).get('status')
            
            print(f"Recovery Instance Status: {status}")
            
            if status == 'LAUNCHED':
                print(f"✅ Recovery Instance Ready!")
                print(f"  Instance ID: {recovery_instance['recoveryInstanceID']}")
                print(f"  Instance Type: {recovery_instance.get('ec2InstanceID')}")
                return recovery_instance
            
            if time.time() - start_time > max_wait_seconds:
                print(f"❌ Timeout waiting for recovery instance ({max_wait_minutes} min)")
                return None
            
            time.sleep(20)
            
        except Exception as e:
            print(f"Error monitoring recovery instance: {str(e)}")
            time.sleep(20)

def failback_to_source(recovery_instance_id: str):
    """
    AWS から本番環境に Failback
    """
    drs = boto3.client('drs')
    
    print(f"Starting failback for recovery instance: {recovery_instance_id}")
    
    try:
        response = drs.start_failback_launch(
            recoveryInstanceIDs=[recovery_instance_id]
        )
        
        print(f"Failback launched: {response}")
        return response
    except Exception as e:
        print(f"Error initiating failback: {str(e)}")
        return None

if __name__ == '__main__':
    # ドリル実行
    source_id = "s-12345678"
    
    print("=== DRS Drill Execution ===")
    initiate_drs_failover(source_id, is_drill=True)
    
    recovery = monitor_recovery_instance(source_id)
    
    if recovery:
        print("\n✅ Drill completed successfully")
        # ドリル終了（Recovery Instance 削除）
        drs = boto3.client('drs')
        drs.terminate_recovery_instances(
            recoveryInstanceIDs=[recovery['recoveryInstanceID']]
        )
        print("Drill cleanup completed")

4. AWS Systems Manager での自動ドリル実行（月 1 回）

AWSTemplateFormatVersion: '2010-09-09'

Resources:
  DRSDrillAutomationDocument:
    Type: AWS::SSM::Document
    Properties:
      DocumentType: Automation
      Content:
        schemaVersion: '0.3'
        description: Monthly DRS Drill Execution
        parameters:
          SourceServerID:
            type: String
            description: DRS Source Server ID
        mainSteps:
          - name: InitiateDrill
            action: aws:executeAwsApi
            onFailure: Continue
            inputs:
              Service: drs
              Api: StartRecovery
              SourceServers:
                - sourceServerID: '{{ SourceServerID }}'
              IsDrill: true
              Tags:
                MonthlyDrill: 'true'
              
          - name: WaitForRecovery
            action: aws:sleep
            inputs:
              Duration: PT600S  # 10 分待機

          - name: CheckRecoveryStatus
            action: aws:executeAwsApi
            inputs:
              Service: drs
              Api: DescribeRecoveryInstances
              Filters:
                sourceServerIDs:
                  - '{{ SourceServerID }}'

          - name: TerminateRecoveryInstance
            action: aws:executeAwsApi
            onFailure: Continue
            inputs:
              Service: drs
              Api: TerminateRecoveryInstances
              RecoveryInstanceIDs:
                - '{{ CheckRecoveryStatus.Items[0].RecoveryInstanceID }}'

  DRSDrillSchedule:
    Type: AWS::Events::Rule
    Properties:
      ScheduleExpression: 'cron(0 2 1 * ? *)'  # 毎月 1 日 02:00 UTC
      State: ENABLED
      Targets:
        - Arn: !Sub 'arn:aws:ssm:${AWS::Region}:${AWS::AccountId}:automation-definition/DRSDrillAutomationDocument:$LATEST'
          RoleArn: !GetAtt SSMExecutionRole.Arn
          Input: !Sub |
            {
              "SourceServerID": ["s-12345678"]
            }

  SSMExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: events.amazonaws.com
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AWSElasticDisasterRecoveryFullAccess

5. CDK（TypeScript）での DRS 環境セットアップ

import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as iam from 'aws-cdk-lib/aws-iam';

export class DRSStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // VPC / Subnet for DRS Staging Area
    const vpc = new ec2.Vpc(this, 'DRSVpc', {
      cidr: '10.0.0.0/16',
      natGateways: 1,
    });

    const stagingSubnet = new ec2.Subnet(this, 'StagingSubnet', {
      vpcId: vpc.vpcId,
      cidrBlock: '10.0.1.0/24',
      availabilityZone: this.availabilityZones[0],
    });

    // Security Group for Replication
    const replicationSG = new ec2.SecurityGroup(this, 'ReplicationSG', {
      vpc,
      description: 'DRS Replication Security Group',
      allowAllOutbound: true,
    });

    replicationSG.addIngressRule(
      ec2.Peer.anyIpv4(),
      ec2.Port.tcp(1500),
      'DRS Replication Port'
    );

    replicationSG.addIngressRule(
      ec2.Peer.anyIpv4(),
      ec2.Port.tcp(443),
      'HTTPS for DRS API'
    );

    // IAM Role for DRS
    const drsRole = new iam.Role(this, 'DRSRole', {
      assumedBy: new iam.ServicePrincipal('drs.amazonaws.com'),
      managedPolicies: [
        iam.ManagedPolicy.fromAwsManagedPolicyName(
          'service-role/AWSElasticDisasterRecoveryServiceRole'
        ),
      ],
    });

    // Output
    new cdk.CfnOutput(this, 'StagingSubnetId', {
      value: stagingSubnet.subnetId,
      exportName: 'DRS-StagingSubnetId',
    });

    new cdk.CfnOutput(this, 'ReplicationSecurityGroupId', {
      value: replicationSG.securityGroupId,
      exportName: 'DRS-ReplicationSG',
    });
  }
}

類似サービス比較表

ベストプラクティス（✅/❌）

トラブルシューティング表

2025-2026 最新動向

1. Container・Kubernetes Workload Support（2026 計画）

# Kubernetes ノードのブロックレベルレプリケーション
aws drs start-recovery \
  --source-servers '{"kubernetesNodes": ["node-1", "node-2"]}'

2. Database-Specific Recovery Plans

RDS・Aurora のネイティブ統合

• DRS + RDS Backup での統合 failover

3. AI/ML による Optimal Failover Timing

CloudWatch Metrics + ML でベストなフェイルオーバータイミングを提案

学習リソース・参考文献

AWS 公式ドキュメント

1. What is AWS Elastic Disaster Recovery

   • https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html

2. DRS User Guide

   • https://docs.aws.amazon.com/drs/latest/userguide/

3. DRS API Reference

   • https://docs.aws.amazon.com/drs/latest/APIReference/

オープンソース・ベンダー

1. AWS Disaster Recovery Whitepaper

   • https://aws.amazon.com/jp/disaster-recovery/

2. CloudEndure Documentation（旧サービス参考）

   • https://docs.cloudendure.com/

実装例・チェックリスト

実装例：オンプレ基幹システムの分単位 DR 構築スクリプト

（省略：詳細なセットアップスクリプト）

採用チェックリスト

• [ ] RTO 分単位が必須（時間単位では許容できない）
• [ ] RPO 秒単位が必須（hour 単位では許容できない）
• [ ] オンプレミス・他クラウド・AWS のサーバーを複数運用
• [ ] 物理 DR サイトの維持コストが高い（削減したい）
• [ ] 定期的な DR ドリルを実施したい（安全に）
• [ ] Failback で本番環境に戻す可能性あり
• [ ] 規制要件で RTO・RPO が明記されている
• [ ] AWS VPN / Direct Connect の接続環境がある

まとめ

AWS Elastic Disaster Recovery（DRS）は 「RTO 分・RPO 秒のブロックレベルリアルタイムレプリケーション DR サービス」。Replication Agent でオンプレ・他クラウド・AWS のサーバーから秒単位の連続レプリケーション実行、障害時は分単位で AWS にフェイルオーバー。従来の物理 DR サイト・ウォームスタンバイの維持コストを 50～80% 削減しながら、分単位の RTO と秒単位の RPO を実現。定期的なドリルも本番影響なく実施でき、Failback で本番環境への復帰も可能な、エンタープライズグレードのディザスタリカバリソリューション。

最終更新：2026-04-26 バージョン：v2.0