AWS Application Migration Service (MGN) 完全ガイド v2.0（2026年最新対応）

最小ダウンタイムリフト&シフト・ブロックレベルレプリケーション・テストカットオーバー・CloudEndure後継

AWS Application Migration Service（MGN） は、「オンプレミス・仮想マシン・他クラウドのサーバーをブロックレベルの継続的レプリケーションで AWS EC2 に自動移行し、最小ダウンタイムで本番環境への影響を最小化するマネージドサービス」 である。CloudEndure Migration の後継で、テストカットオーバー・段階的ウェーブ実行・Post-launch 自動化を提供する。

目次

1. ドキュメントメタデータ
2. 概要と課題
3. このサービスを選ぶ理由
4. アーキテクチャと設計原則
5. コアコンポーネント
6. 主要ユースケース
7. 設定・操作の具体例
8. 類似サービス比較表
9. ベストプラクティス
10. トラブルシューティング表
11. 2025-2026 最新動向
12. 学習リソース・参考文献
13. 実装例・チェックリスト
14. まとめ

ドキュメントメタデータ

• 最終更新: 2026-04-27
• バージョン: v2.0
• 対象者: Infrastructure Manager、Migration Engineer、Cloud Operations Lead
• 難易度: 中級
• 関連サービス: EC2、EBS、Elastic Disaster Recovery（DRS）、Migration Hub、DataSync
• 後継サービス: CloudEndure Migration（2026 年 3 月廃止予定）

概要と課題

本質

AWS Application Migration Service（MGN）は 「物理・仮想・クラウド上のサーバーをリアルタイムにブロックレベルでレプリケーションし、ダウンタイムを最小化（数分）して AWS EC2 に移行するマネージドサービス」 である。

従来のバックアップ・リストア方式（数時間のダウンタイム）と異なり、移行中も本番サーバーを稼働させながら AWS 側で常時最新状態を保ち、カットオーバー時間を最小化する。

従来の課題

MGN が提供する解決策

✅ 最小ダウンタイム：ブロックレベル continuous sync で RPO 秒単位、RTO 数分
✅ テストカットオーバー：本番に影響なく AWS で test instance 起動・検証後に削除
✅ 自動化：OS・application 変更不要。physical/virtual/cloud 全対応
✅ 段階的移行：複数 server を application/wave 単位でグループ化・sequential 実行
✅ Post-launch 自動化：CloudWatch agent 導入・SystemsManager registration を自動実施
✅ 低コスト：最初 90 日無料。以降も $0.042/時間/server（EC2 ステージング費用のみ）

このサービスを選ぶ理由

なぜ AWS Application Migration Service なのか？

1. ダウンタイム最小化（数日 → 数分）

   • 従来：全 server backup（16 時間）→ AWS transfer（4 時間）→ restore（4 時間） = 24 時間downtime
   • MGN：continuous replication（background） → test cutover（1 日） → final cutover（5 分） = 5 分 downtime

2. OS・アプリケーション変更不要

   • Windows Server 2003・Java 6・Legacy DB 等も一切変更せず EC2 で稼働
   • Code change リスクゼロ（re-architect は別フェーズ）

3. テストカットオーバーで本番移行前に検証

   • 本番に影響なく AWS で test instance 起動
   • Full functional test 実施（DNS・application login・DB 接続など）
   • 問題なければ本番 cutover、issue あれば source server で継続・修正後に再移行

4. 複数 source platform の統一サービス

   • VMware vSphere、Microsoft Hyper-V、AWS EC2、Azure VMs、GCP Compute、物理サーバー
   • 全て同一のツールセット・workflow で管理

5. 大規模移行の wave/application 管理

   • 500+ server → application/wave で logical grouping
   • Wave 1 cutover → Wave 2 approval → Wave 3 execution という段階制御

6. 初期 90 日無料（ほぼ全移行プロジェクト含まれる）

   • 典型的移行期間：4-6 週間（90 日以内）→ 無料
   • 90 日超過時のみ $0.042/時間 × server 数で追加料金

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

• クラウドネイティブ化が目的：Replatform / Refactor の方が価値（Rehost は中間ステップ）
• Server < 5 台：自動化の恩恵が限定的（手動 migration で十分）
• Disaster Recovery のみ：AWS Elastic Disaster Recovery（DRS）を使用
• クラウド間の VM migration：VM Import/Export でシンプル

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

全体構成図（Mermaid 1）

graph TB
    subgraph OnPrem["Source Environment"]
        SRV["Physical / Virtual Servers<br/>(Windows / Linux)"]
        AGENT["MGN Replication Agent<br/>(Continuous Block Sync)"]
    end
    
    subgraph AWS["AWS (Target Environment)"]
        REP_SRV["Replication Servers<br/>(t3.small staging)"]
        STAGING["Staging Area<br/>(EBS Volumes)"]
        TEST["Test Instances<br/>(for validation)"]
        PROD["Production Instances<br/>(post-cutover)"]
    end
    
    subgraph Network["Network & Security"]
        VPN["AWS VPN / Direct Connect<br/>(Encrypted TLS)"]
        SG["Security Groups<br/>(port 45-forward only)"]
    end
    
    subgraph Orchestration["Orchestration & Management"]
        MGNH["Migration Hub<br/>(Progress tracking)"]
        APPS["Application Groups<br/>(Logical grouping)"]
        WAVES["Wave Management<br/>(Sequential execution)"]
    end
    
    SRV -->|Install Agent| AGENT
    AGENT -->|Continuous sync<br/>Block-level| VPN
    VPN -->|Encrypted| REP_SRV
    REP_SRV -->|Replicate| STAGING
    STAGING -->|Test Instance| TEST
    STAGING -->|Finalize| PROD
    
    AGENT -->|Report status| MGNH
    MGNH -->|Organize| APPS
    APPS -->|Sequential| WAVES

Migration Flow（3段階）

Phase 1: Initial Sync（初期同期）
┌─────────────────────────────────────────┐
│ Source Server（On-Premises）            │
│ └─ Replication Agent: all blocks copy  │
│    (~50MB/s 帯域幅で 1TB なら 6 時間)  │
└──────────────┬──────────────────────────┘
               │ (Network: VPN / Direct Connect)
┌──────────────▼──────────────────────────┐
│ AWS Replication Server（Staging）       │
│ └─ EBS Volume: all blocks stored        │
│    RPO: 秒単位で最新状態を maintain     │
└─────────────────────────────────────────┘

Phase 2: Test Cutover（テスト段階）
┌─────────────────────────────────────────┐
│ AWS Test Instance                       │
│ └─ Staging EBS から test instance 起動 │
│ └─ Full functional test（1-8 時間）    │
│ └─ テスト後に instance terminate       │
│    (本番に影響なし)                     │
└─────────────────────────────────────────┘

Phase 3: Production Cutover（本番移行）
1. App / DB shutdown（maintenance window）
   └─ 本番トラフィックを停止（数分）
   
2. Final Sync（最後の差分 sync）
   └─ Agent が最新ブロック transfer
   
3. Instance Launch（EC2 起動）
   └─ Staging EBS → production EBS に promote
   └─ EC2 instance 起動（~1 分）
   
4. Network Switchover（DNS / 負荷分散）
   └─ Route 53 / ELB を新 EC2 に向ける（秒単位）
   
5. Post-launch Action（自動化ステップ）
   └─ CloudWatch agent 導入
   └─ Systems Manager parameter store 設定
   └─ Backup policy 自動設定
   
Total Downtime: 5-15 分（traditional 24 時間から 95% 短縮）

コアコンポーネント

1. Replication Agent（レプリケーションエージェント）

役割：Source server にインストールし、ブロックレベルの変更を AWS に送信

# 推奨スペック：
├─ CPU: 1 vCPU 最小（dedicated 推奨）
├─ Memory: 512MB 最小（1GB+ 推奨）
├─ Disk: 100MB（agent 本体）+ temp storage
└─ Network: 10Mbps 以上（dedicated 推奨）

# インストール対応 OS：
├─ Windows Server 2003 / 2008 / 2012 / 2016 / 2019 / 2022
├─ RHEL 5 / 6 / 7 / 8 / 9
├─ CentOS 5 / 6 / 7 / 8
├─ Ubuntu 12.04 / 14.04 / 16.04 / 18.04 / 20.04 / 22.04
├─ Debian 7 / 8 / 9 / 10 / 11
└─ Oracle Linux 6 / 7 / 8

# インストール方法：
├─ Windows: .exe installer（GUI / silent）
├─ Linux: .tar.gz or RPM（yum / apt）
└─ Management: AWS Systems Manager Session Manager for remote install

2. Replication Server（レプリケーションサーバー）

役割：AWS 上で staging area を管理。Agent からのデータを受信・EBS に書き込み

# 推奨設定：
├─ Instance Type: t3.small（default, sufficient for most）
├─ Network: Staging area VPC（通常は production VPC と別）
├─ EBS: Source server のディスク容量と同じサイズ確保
├─ Availability Zone: multi-AZ for redundancy

# Cost:
├─ Instance: $0.0208/hour（t3.small）
├─ EBS Storage: $0.10/GB/month（typical 500GB = $50/month）
└─ 90 日移行の典型コスト：$0.0208 × 24h × 90d = $45/server

3. Launch Configuration Template（起動テンプレート設定）

役割：Cutover 時に AWS EC2 instance を起動する際の設定

# Instance Type Selection：
├─ Automatic（AWS recommends based on source）
├─ User-defined（manual selection）
└─ Right-sizing（cost optimization）

# EC2 Configuration：
├─ AMI: Replicated source disk → EBS volume → custom AMI
├─ Instance Type: t3.medium / m5.large など
├─ EBS Volume: gp3 / io1（IOPS requirement による）
├─ Network: VPC / Subnet / Security Group
├─ IAM Role: EC2 → CloudWatch / SSM 統合用
├─ Monitoring: CloudWatch detailed monitoring enable

# Tags：
├─ Name: production-web-01
├─ Application: EcommerceApp
├─ Environment: Production
├─ CostCenter: Engineering
└─ MigrationID: mgn-wave1-app001

# Post-launch Actions（cutover 直後の自動実行）：
├─ Install CloudWatch agent（monitoring enable）
├─ Register to Systems Manager（patch management）
├─ Configure backup policy（EBS snapshots）
├─ Update DNS resolver settings
└─ Custom scripts（application-specific setup）

4. Application & Wave Management

Application：複数サーバーを logical group 化

# Application 定義：
aws mgn create-application \
  --name "E-commerce Platform" \
  --description "Web + API + Database servers"

# サーバーを application に関連付け：
aws mgn associate-source-servers \
  --application-id app-ecommerce \
  --source-server-ids '[s-web-01, s-web-02, s-api-01, s-db-01]'

# Result: Application ダッシュボードで 4 サーバーの progress 一括表示

Wave：複数 application の migration batch

# Wave 定義：
aws mgn create-wave \
  --name "Wave 1 - Non-Production"
  --description "Dev + Staging environments"

# Application を wave に割り当て：
aws mgn associate-applications \
  --wave-id wave-1 \
  --application-ids '[app-dev, app-staging]'

# Wave execution control：
├─ Wave 1 cutover → Wave 1 確認 → Wave 2 approval → Wave 2 cutover
└─ 日程・承認・dependency tracking が自動

5. Test Cutover（テストカットオーバー）

用途：本番移行前に AWS で動作検証

# Test cutover 実行：
aws mgn start-test \
  --source-server-ids '[s-web-01, s-web-02]'

# Result:
├─ Staging EBS から test EC2 instances 起動（通常 t3.medium × 2）
├─ Public IP 割り当て（SSH / RDP アクセス可能）
├─ Route 53 weighted routing で 10% traffic routing（production 負荷テスト可）
├─ Full testing window: 1-8 hours
└─ Cleanup: Test instances terminate（リソース削除）

# Test 検証項目：
├─ OS level checks（hostname、IP、DNS resolver）
├─ Application startup（service status、process list）
├─ Database connectivity（connection string、query test）
├─ Network connectivity（external API call、DNS resolution）
├─ Performance baseline（latency、throughput）
└─ Application functional test（UI / API endpoints）

主要ユースケース

1. データセンター全面移行（500+ サーバー）

シナリオ：オンプレ datacenter 廃止。AWS に全サーバー移行（18 ヶ月）

Wave 計画：

Wave 1 (Month 1-2): Non-Production（50 servers）
├─ Dev Environments（10 servers）
├─ Staging Environments（15 servers）
├─ Test Environments（25 servers）
├─ Risk: Low、Business Impact: None（非本番）
└─ Duration: 2 weeks、Downtime: 0 impact

Wave 2 (Month 3-4): Database & Core Systems（80 servers）
├─ Primary Database cluster（Oracle + standby）
├─ Data Warehouse（Teradata → Redshift migration）
├─ Reporting servers（ETL + BI tool）
├─ Risk: Medium、Business Impact: Reports 2-4 hour delay acceptable
└─ Duration: 3 weeks（DB cutover timing critical）

Wave 3 (Month 5-7): Production Web Tier（120 servers）
├─ Web servers（Apache + PHP / Java）
├─ API servers（microservices）
├─ Cache layer（Redis / Memcached）
├─ Risk: High、Business Impact: E-commerce downtime unacceptable
└─ Duration: 4 weeks（phased migration with blue-green deployment）

Wave 4 (Month 8-10): Production App Tier（150 servers）
├─ Business logic servers（ERP / CRM）
├─ Integration layer（ESB / Message queue）
├─ Batch processing（scheduled jobs）
├─ Risk: High、Dependency: Wave 3 DB migration 必須
└─ Duration: 4 weeks

Wave 5 (Month 11-12): Specialized Systems（100 servers）
├─ Legacy systems（COBOL / PowerBuilder）
├─ Custom applications
├─ Backup / Archive systems
└─ Duration: 2 weeks

Wave 6 (Month 13-18): Final Cleanup & Optimization（wait state）
├─ 30-day post-cutover validation on AWS
├─ Performance tuning（Right-sizing）
├─ Decommissioning on-premises（tape destruction等）
└─ Cost optimization（Reserved Instances purchase）

2. CloudEndure → MGN Migration（既存顧客の upgrade）

シナリオ：CloudEndure ユーザーが 2026 年 3 月廃止前に MGN に upgrade

既存環境：CloudEndure で 100 server ongoing replication
アクション：
├─ 1. CloudEndure → MGN agent 入れ替え（downtime 5 分）
├─ 2. MGN で new replication start（staging area fresh）
├─ 3. Test cutover で検証
└─ 4. MGN で finalize cutover（本番）

Benefits：
├─ MGN の latest features 利用（Post-launch automation など）
├─ 費用削減（CloudEndure license 廃止）
└─ AWS first-party support（CloudEndure は partner）

3. Multi-Cloud Consolidation（Azure / GCP → AWS）

シナリオ：複数クラウドから AWS へ統一

Source：
├─ On-premises: 150 servers
├─ Azure VMs: 80 servers
├─ GCP Compute: 60 servers
├─ AWS Legacy: 50 servers（new region に consolidate）

Target：
└─ AWS Unified（all regions）

Benefits：
├─ Single cloud vendor（license negotiation・support）
├─ Cost optimization（consolidation discount）
└─ Operational simplification（single management plane）

設定・操作の具体例

CLI ベースの操作

1. MGN Service 初期化

# MGN を初期化（初回のみ、アカウント・リージョン ごと）
aws mgn initialize-service --region ap-northeast-1

# 出力：
# {
#   "serviceDescription": {
#     "supportedRegions": ["ap-northeast-1", "us-east-1", "eu-west-1"],
#     "status": "INITIALIZED"
#   }
# }

# Staging area subnet / security group 確認
aws mgn describe-replication-configuration-templates \
  --region ap-northeast-1

2. Replication Configuration Template 設定

# Replication 設定の作成 / 更新
aws mgn update-replication-configuration-template \
  --replication-configuration-template-id rct-abc123 \
  --staging-area-subnet-id subnet-staging-01 \
  --replication-server-instance-type t3.small \
  --use-dedicated-replication-server false \
  --bandwidth-throttling 100 \
  --create-public-ip false \
  --data-plane-routing PRIVATE_IP \
  --staging-area-tags Key=Name,Value=MGN-Staging Key=Environment,Value=NonProd \
  --region ap-northeast-1

# 出力：
# {
#   "replicationConfigurationTemplate": {
#     "replicationConfigurationTemplateId": "rct-abc123",
#     "stagingAreaSubnetId": "subnet-staging-01",
#     "replicationServerInstanceType": "t3.small",
#     "dataPlaneRouting": "PRIVATE_IP"
#   }
# }

3. Source Server Agent インストール

# Linux agent install (example)
# 1. Download installer
wget -O /tmp/aws-replication-installer-init.py \
  https://aws-application-migration-service-ap-northeast-1.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py

# 2. Run installer (requires root)
sudo python3 /tmp/aws-replication-installer-init.py \
  --region ap-northeast-1 \
  --aws-access-key-id AKIAIOSFODNN7EXAMPLE \
  --aws-secret-access-key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

# 3. Verify replication started
aws mgn describe-source-servers \
  --filters '{"lifeCycleStates": ["DISCOVERED"]}' \
  --region ap-northeast-1

4. Source Server の状態監視

# 全 source servers 一覧
aws mgn describe-source-servers --region ap-northeast-1

# 出力例：
# {
#   "items": [
#     {
#       "sourceServerId": "s-0abc1234",
#       "sourceProperties": {
#         "cpus": 4,
#         "disks": [{"bytes": 107374182400}],
#         "ram": 17179869184,
#         "recommendedInstanceType": "t3.large",
#         "os": "LINUX"
#       },
#       "lifeCycle": {
#         "state": "READY_FOR_TEST",
#         "lastSeenByServiceDateTime": "2026-04-27T14:30:00Z"
#       }
#     }
#   ]
# }

# Specific server detail
aws mgn get-source-server \
  --source-server-id s-0abc1234 \
  --region ap-northeast-1

5. Application Group 作成

aws mgn create-application \
  --name "E-commerce Platform" \
  --description "Web + API + Database tier servers" \
  --region ap-northeast-1

# 出力：
# {
#   "application": {
#     "applicationID": "app-ecommerce",
#     "arn": "arn:aws:mgn:ap-northeast-1:123456789012:application/app-ecommerce",
#     "name": "E-commerce Platform"
#   }
# }

# Servers を application に関連付け
aws mgn associate-source-servers \
  --application-id app-ecommerce \
  --source-server-ids '[s-web-01, s-web-02, s-api-01, s-db-01]' \
  --region ap-northeast-1

6. Test Cutover 実行

# Test cutover 開始
aws mgn start-test \
  --source-server-ids '[s-web-01, s-web-02]' \
  --region ap-northeast-1

# 出力：
# {
#   "job": {
#     "jobID": "job-test-001",
#     "type": "TEST",
#     "status": "STARTED",
#     "sourceServerIDs": ["s-web-01", "s-web-02"]
#   }
# }

# Test job 進捗確認
aws mgn describe-jobs \
  --filters '{"jobIDs": ["job-test-001"]}' \
  --region ap-northeast-1

# Test 検証後に cleanup
aws mgn finish-test \
  --source-server-ids '[s-web-01, s-web-02]' \
  --region ap-northeast-1

7. Production Cutover 実行

# Production cutover 開始
aws mgn start-cutover \
  --source-server-ids '[s-web-01, s-web-02]' \
  --region ap-northeast-1

# 出力：
# {
#   "job": {
#     "jobID": "job-cutover-001",
#     "type": "CUTOVER",
#     "status": "STARTED"
#   }
# }

# Cutover 完了を待機（~5 分）
aws mgn describe-jobs \
  --filters '{"jobIDs": ["job-cutover-001"]}' \
  --region ap-northeast-1

# EC2 instance 確認（新規インスタンス起動済み）
aws ec2 describe-instances \
  --filters 'Name=tag:aws-mgn-launch-template-id,Values=*' \
  --region ap-northeast-1

類似サービス比較表

ベストプラクティス

1. Agent インストール戦略

✅ 推奨：

• AWS Systems Manager Session Manager or EC2 Instance Connect で remote install
• Windows: msiexec.exe (silent install) で自動化
• Linux: ansible / puppet で大規模デプロイ

❌ アンチパターン：

• Manual login + GUI installer（エラーリスク・スケール不可）

2. Test Cutover の活用

✅ 推奨：

• Wave 1 cutover の 1-2 日前に test cutover 実施
• Full functional testing + performance baseline
• Issue 発見時に source server で修正 → test cutover 再実行

❌ アンチパターン：

• Test cutover をスキップ（本番初実行で問題発覚 → ロールバック）

3. Replication Lag Monitoring

✅ 推奨：

# CloudWatch metrics を監視
aws cloudwatch get-metric-statistics \
  --namespace AWS/ApplicationMigrationService \
  --metric-name ReplicationLatency \
  --statistics Average \
  --start-time 2026-04-27T00:00:00Z \
  --end-time 2026-04-27T23:59:59Z \
  --period 300 \
  --region ap-northeast-1

# Alert: Replication lag > 1 minute → investigate
# (normal: < 30 seconds)

❌ アンチパターン：

• Replication lag を監視しない（本番 cutover 時に遅延発見）

4. Post-launch Action 活用

✅ 推奨：

• CloudWatch agent install を post-launch script で自動化
• Systems Manager parameter store から config fetch
• Backup policy、update schedule を自動適用

❌ アンチパターン：

• Manual post-cutover configuration（時間かかる・ミス多発）

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

2025-2026 最新動向

1. CloudEndure Migration 廃止（2026 年 3 月 31 日予定）

Action item：

• 既存 CloudEndure ユーザーは 2026 年 2 月までに MGN に migration
• Free migration path provided by AWS

2. MGN Serverless Option（検討段階）

将来像（2026 年下半期検討）：

• Migration の automation が更に高度化
• Lambda-based orchestration for complex workflows

3. AI-based Right-sizing（2025 年予定）

計画：

• Replication 期間中の workload profile 分析
• Instance type recommendation の自動調整（t3.small が insufficient なら medium に変更提案）

学習リソース・参考文献

公式ドキュメント

AWS Training

実装例・チェックリスト

Migration Checklist

Pre-Migration（1-2 週間前）

• [ ] MGN service 初期化（AWS account・region）
• [ ] Replication configuration template 設定（subnet・security group）
• [ ] Staging area network setup（VPC peering if needed）
• [ ] Source servers inventory 準備（hostname list）
• [ ] Agent download URL 確認（region-specific）

Agent Installation（Migration week 1）

• [ ] Agent install script 準備（windows .exe, linux .sh）
• [ ] Test server 2-3 台に manual install 検証
• [ ] Automated deployment 実装（Systems Manager / Ansible）
• [ ] Replication status 監視開始（CloudWatch dashboard）

Replication Phase（Week 1-2）

• [ ] Replication lag < 30 seconds 確認
• [ ] Source & destination disk size 一致確認
• [ ] Application Discovery Service with MGN integration

Test Cutover（Week 2）

• [ ] Test instance 起動
• [ ] OS level checks（hostname、IP、DNS）
• [ ] Application startup & connectivity tests
• [ ] Performance baseline measurement
• [ ] Test instance cleanup

Production Cutover（Week 3）

• [ ] Maintenance window scheduled & communicated
• [ ] Rollback plan documented
• [ ] start-cutover 実行
• [ ] EC2 instance 起動・public IP assignment
• [ ] DNS / load balancer switchover
• [ ] Business validation（1-2 hours）
• [ ] Post-launch action verification

Post-Cutover（Week 4）

• [ ] 30-day monitoring period
• [ ] Cost optimization（right-sizing）
• [ ] Source server decommissioning（data deletion）
• [ ] Lessons learned documentation

まとめ

AWS Application Migration Service（MGN） は 「最小ダウンタイムのリフト&シフト移行サービス」 である。

主な価値

1. ダウンタイム最小化：従来 24 時間 → 数分
2. テストカットオーバー：本番移行前に AWS で full validation
3. 自動化：OS・application 変更不要
4. 大規模対応：500+ server・複数 wave を application group で統制
5. 低コスト：初期 90 日無料（ほぼ全移行プロジェクト含まれる）

注意点

• CloudEndure 廃止（2026 年 3 月）：既存ユーザーは MGN への upgrade 必須
• Replication lag 監視：network bottleneck ないか常時確認
• Test cutover 必須：本番 cutover 前に full validation

次ステップ

• MGN で physical/virtual servers を EC2 に migrate
• 移行後は Refactor / Replatform で modernization（別フェーズ）
• DRS（Elastic Disaster Recovery）で ongoing DR protection

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