AWS Migration Hub 完全ガイド v2.0（2026年最新対応）

複数移行ツール統合・ポートフォリオ可視化・進捗管理の一元化

AWS Migration Hub は、「複数の AWS 移行ツール（MGN・DMS・SAP on AWS など）と認定パートナーツール（CloudEndure・Carbonite など）の移行進捗を一元管理するダッシュボード・サービス」 である。オンプレミスのサーバー・アプリケーション・データベースの移行状態を アプリケーション単位・サーバー単位 で可視化し、PMO・ステークホルダーへの進捗報告を自動化する。2026 年現在、AWS Transform への統合検討により新規ユーザー受け入れを段階的に終了しているが、既存ユーザーは継続利用可能。

目次

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

ドキュメントメタデータ

• 最終更新: 2026-04-27
• バージョン: v2.0
• 対象者: Migration PMO Manager、Enterprise Architect、Cloud Infrastructure Manager、IT Portfolio Manager
• 難易度: 初級～中級
• 関連サービス: MGN、DMS、Application Discovery Service、Strategy Recommendations、Orchestrator、Refactor Spaces
• 廃止・変更予定: AWS Migration Hub は 2025 年 11 月 7 日をもって新規顧客の受け入れを終了。既存顧客は継続利用可能。長期的には AWS Transform への統合を検討

概要と課題

本質

AWS Migration Hub は 「エンタープライズ移行プロジェクトの統制・進捗可視化・ステークホルダー報告を一元化するダッシュボード」 である。複数の AWS 移行ツール（MGN・DMS・SAP on AWS・Refactor Spaces）と認定パートナーツール（CloudEndure・Carbonite・RiverMeadow など）の移行進捗を自動集約し、以下を実現する：

• 複数ツール・複数移行方法の統合ビュー：Rehost（リフト&シフト）・Replatform（リプラットフォーム）・Refactor（クラウドネイティブ化）が混在するポートフォリオを一画面で管理
• アプリケーション単位の進捗追跡：サーバーレベルの粒度ではなく、ビジネスアプリケーション（例：「顧客管理システム」「注文処理系」）単位での依存関係と完了率を可視化
• 移行ホームリージョン：グローバルデータセンターを複数リージョンにまたがる場合、1 つのホームリージョンをハブにして全リージョンの移行進捗を統合
• 自動タグ付け・コスト配分：移行リソースに自動タグ付けし、Cost Explorer で移行別のコスト追跡を実現

従来の課題

AWS Migration Hub が提供する解決策

✅ 複数移行ツールの統合ダッシュボード：MGN・DMS・SAP on AWS・Refactor Spaces の進捗を 1 つの画面で可視化
✅ アプリケーション単位の進捗管理：サーバー / DB / マイクロサービスをビジネスアプリケーションにグループ化
✅ 自動ポートフォリオ分析：Application Discovery Service のデータを取り込み、ウェーブ設計を自動提案
✅ ステークホルダーダッシュボード：読み取り専用権限で移行進捗をリアルタイム共有
✅ コスト追跡：移行リソースへの自動タグ付けで Cost Explorer による移行別コスト分析
✅ パートナーツール統合：notify-migration-task-state API で CloudEndure・Carbonite 等の進捗を統合

このサービスを選ぶ理由

なぜ AWS Migration Hub なのか？

1. 複数ツール・複数ウェーブの一元管理

   • データセンター閉鎖プロジェクト（500 台以上のサーバー）では、MGN（物理・仮想サーバー）・DMS（DB）・SAP on AWS（ERP）が並行実行される
   • Migration Hub は “Wave 1”（非本番環境）→ “Wave 2”（本番前）→ “Wave 3”（本番）の進捗を統一ダッシュボードで管理
   • 従来：各ツールのコンソール × 3～4 個を定期確認 → 1 つの Dashboard で完結

2. アプリケーション依存関係の自動反映

   • Application Discovery Service でスキャンした依存関係（「Webサーバーは DBサーバーに依存」など）が自動的に Migration Hub に反映
   • ウェーブ設計時に依存関係の漏れによる移行失敗を事前防止
   • 例：DB 移行完了前に APP サーバーのカットオーバーを実行すると警告・ブロック

3. PMO・ステークホルダーへのセルフサービスレポーティング

   • 移行プロジェクトの経営陣・PMO が読み取り専用の Migration Hub ダッシュボードにアクセス
   • 進捗率（30% 完了、全体 100 台中 30 台）がリアルタイムで表示される
   • 週次・月次レポート作成の手作業が不要

4. 複数 AWS リージョン・複数アカウントの統合管理

   • グローバル企業で複数リージョンに移行する場合、ホームリージョンから全リージョンのサーバー進捗を一元追跡
   • スポークアカウント（各リージョン）での移行がハブリージョンで自動集約される
   • 従来：各リージョン × 各アカウントのコンソール確認が必要 → 1 つのハブで完結

5. パートナーツール連携

   • AWS 認定パートナー（Cloudability・RiverMeadow・Turbonomic など）の移行進捗も notify-migration-task-state API で統合
   • ハイブリッド移行ツール環境での統一管理

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

• 小規模移行（サーバー < 10 台）：個別ツール（MGN・DMS）で十分
• 単一ツール用途：MGN のみ使用する場合、Migration Hub の価値は限定的
• AWS 以外のクラウド移行（主に Azure・GCP）：Azure Migrate・Google Cloud Migrate の方が適切

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

全体構成図（Mermaid 1）

graph TB
    subgraph OnPrem["On-Premises / Multi-Cloud"]
        SRV["Source Servers<br/>(Physical/Virtual)<br/>Windows / Linux"]
        DB["Source Databases<br/>(Oracle / SQL Server<br/>MySQL / PostgreSQL)"]
        APP["Applications<br/>(Monolith / Distributed)"]
    end
    
    subgraph DiscoveryLayer["Discovery & Analysis Layer"]
        ADS["Application Discovery Service<br/>(Agent / Agentless Scan)<br/>Dependency Mapping"]
        SR["Strategy Recommendations<br/>(7R Analysis)<br/>Rehost/Replatform/Refactor"]
    end
    
    subgraph MigrationTools["Migration Tools Layer"]
        MGN["Application Migration Service<br/>(Replication Agent)<br/>Lift & Shift"]
        DMS["Database Migration Service<br/>(Full Load + CDC)<br/>Schema Conversion"]
        SAP["SAP on AWS<br/>(HANA Migration)<br/>Homogeneous System Copy"]
        RS["Refactor Spaces<br/>(Strangler Fig Pattern)<br/>Microservices Extraction"]
    end
    
    subgraph MigrationHub["Migration Hub (Central Dashboard)"]
        HUB["Migration Hub Console<br/>(Home Region)"]
        APP_GRP["Application Groups<br/>(Logical Grouping)"]
        WAVE["Wave Management<br/>(Batch Sequencing)"]
        STATUS["Progress Tracking<br/>(NOT_STARTED→IN_PROGRESS→COMPLETED)"]
        TAGS["Auto-Tagging<br/>(Cost Allocation)"]
    end
    
    subgraph AWS["AWS Target Infrastructure"]
        EC2["EC2 Instances<br/>(Migrated Servers)"]
        RDS["RDS / Aurora<br/>(Migrated Databases)"]
        ECS["ECS / Fargate<br/>(Containerized Apps)"]
        S3["S3 / DataSync<br/>(Data Storage)"]
    end
    
    subgraph Monitoring["Monitoring & Reporting"]
        CW["CloudWatch Metrics<br/>(Migration Progress)"]
        CE["Cost Explorer<br/>(Cost per Application)"]
        REPORTS["Custom Reports<br/>(PMO Dashboard)"]
    end
    
    ADS -->|Sends Dependencies| HUB
    SR -->|Sends Recommendations| HUB
    MGN -->|Reports Progress| HUB
    DMS -->|Reports Progress| HUB
    SAP -->|Reports Progress| HUB
    RS -->|Reports Progress| HUB
    
    HUB -->|Manages| APP_GRP
    HUB -->|Orchestrates| WAVE
    HUB -->|Tracks| STATUS
    HUB -->|Applies| TAGS
    
    TAGS -->|Integration| CE
    STATUS -->|Metrics| CW
    HUB -->|Data for| REPORTS
    
    MGN -->|Deploys| EC2
    DMS -->|Deploys| RDS
    SAP -->|Deploys| RDS
    RS -->|Deploys| ECS

Migration Hub ホームリージョンの意義

Migration Hub Home Region（ハブ）
    │
    ├─ Global Application Configuration
    │  └─ Server Inventory（Cross-Region）
    │  └─ Application Groups（グローバル定義）
    │  └─ Wave Planning（クロスリージョン）
    │
    ├─ Regional Spoke 1（ap-northeast-1）
    │  ├─ MGN Replication Server
    │  ├─ Migrated EC2 Instances
    │  └─ Status Reports to Hub
    │
    ├─ Regional Spoke 2（us-east-1）
    │  ├─ DMS Replication Instance
    │  ├─ RDS Target Database
    │  └─ Status Reports to Hub
    │
    └─ Regional Spoke 3（eu-west-1）
       ├─ SAP HANA Target System
       ├─ Refactor Spaces Environment
       └─ Status Reports to Hub

コアコンポーネント

1. Migration Hub ホーム（グローバルダッシュボード）

役割：複数リージョン・複数ツールの移行進捗を一元集約

2. Server Tracking（サーバー追跡）

役割：オンプレミスサーバーの移行状態をリアルタイム監視

# 追跡対象：
- Physical Servers（オンプレミス物理）
- VMware VMs / Hyper-V VMs（仮想マシン）
- GCP / Azure Compute Instances（他クラウド）
- AWS Cross-Region EC2（AWS 内マイグレーション）

3. Application Grouping（アプリケーショングループ化）

役割：複数サーバー・複数 DB を1つのビジネスアプリケーションに統合管理

例：E-commerce Application
├─ Web Servers（3台）：ap-northeast-1 で EC2 に移行（MGN）
├─ API Servers（2台）：ap-northeast-1 で ECS に移行（Refactor Spaces）
├─ Database（Oracle 100GB）：ap-northeast-1 で RDS に移行（DMS）
└─ Shared Storage（NAS 500GB）：ap-northeast-1 で EFS に移行（DataSync）

進捗：5/7 リソース完了（約 71%）

4. Wave Planning & Execution（ウェーブ計画・実行）

役割：依存関係を考慮した段階的移行スケジュール

Wave 1（Week 1-2）- Non-Production Validation
├─ Dev Environment（5 台）
├─ Staging Database（Oracle Test 5GB）
└─ Dependency: なし（独立）

Wave 2（Week 3-4）- Production Pre-Migration
├─ Production Database（Oracle 100GB）- DMS CDC 開始
├─ Database Server（1 台）
└─ Dependency: Wave 1 検証完了待ち

Wave 3（Week 5-6）- Production Cutover
├─ Web Servers（5 台）- MGN
├─ API Servers（3 台）- MGN
└─ Dependency: Wave 2 DB 移行完了待ち

5. Discovery Integration（発見機能統合）

役割：Application Discovery Service からのインベントリ・依存関係を取り込み

• Server Inventory：IP・OS・ハードウェアスペック・ネットワーク接続
• Application Dependencies：「App A は DB B に接続」「Service C は Message Queue D を使用」などの依存関係
• Network Flows：サーバー間の通信ポート・プロトコル

6. Auto-Tagging & Cost Allocation（自動タグ付け・コスト配分）

役割：移行リソースに自動タグを付与し、Cost Explorer で application 別コスト追跡

# 自動適用タグ例：
aws-application: "E-commerce"
aws-migration-id: "mh-app-12345"
aws-source-server-id: "ds-0abc1234"  # Application Discovery Service
aws-migration-tool: "mgn"  # mgn / dms / sap-on-aws
aws-wave: "Wave1"

主要ユースケース

1. エンタープライズデータセンター閉鎖プロジェクト

シナリオ：オンプレミスデータセンター（500 台サーバー、100+ アプリケーション）を 18 か月で AWS に全面移行

Migration Hub の活用：

1. 初期計画フェーズ
   → Application Discovery Service スキャン（500 台）
   → Migration Hub Strategy Recommendations（7R 分析）
   → 400 台 Rehost / 50 台 Replatform / 50 台 Retain 自動分類

2. ウェーブ設計フェーズ
   → Migration Hub の Dependency Mapping で 6 ウェーブに自動分割
   → Wave 1: Non-Prod（4 か月）→ Wave 2: Pre-Prod（6 か月）→ Wave 3-6: Production（12 か月）
   → 依存関係チェック：Wave 1 完了 → Wave 2 実行権限自動付与

3. 進捗追跡フェーズ
   → 週次 PMO meeting で Migration Hub ダッシュボード共有
   → 全 500 台のうち 250 台完了（50%）などリアルタイム表示
   → 遅延アプリ自動検出：「Orders System」Wave 2 予定が 2 週間遅延

4. コスト追跡フェーズ
   → Cost Explorer で Application 別の月間コスト表示
   → 例：「E-commerce App」→ $15,000/月（EC2・RDS・EBS 合算）

2. マルチクラウド移行（Azure → AWS）

シナリオ：Microsoft Azure から AWS への移行（200 台 VM、50 個アプリケーション）

Migration Hub の活用：

1. ホームリージョン設定
   → ap-northeast-1 をハブに設定
   → Azure VM のインベントリを手動 / API 経由で登録

2. ツール統合
   → MGN：Azure VM → EC2（Replication Agent インストール）
   → DMS：SQL Server RDS → Aurora PostgreSQL
   → Refactor Spaces：レガシー .NET → ECS on Fargate
   
3. 進捗統合
   → MGN コンソール → Migration Hub（自動報告）
   → DMS タスク → Migration Hub（自動報告）
   → Refactor Spaces → Migration Hub（自動報告）
   → 1 つのダッシュボードで 3 ツールの進捗を表示

3. SAP システム移行プロジェクト

シナリオ：オンプレミス SAP ERP（HANA DB 500GB、App Servers 20 台）を AWS に移行

Migration Hub の活用：

1. Application Grouping
   → "SAP Production System" グループ
   └─ HANA Database（500GB）
   └─ App Servers（20 台）
   └─ Dialog Instances（10 台）

2. Strategy & Planning
   → Migration Hub Strategy：SAP on AWS テンプレート推奨
   → Orchestrator：HANA 移行→ App Server デプロイ→テスト→カットオーバー

3. Wave Management
   → Wave 1: SAP Test System（DB 50GB + App 2 台）
   → Wave 2: SAP QA System（DB 100GB + App 4 台）
   → Wave 3: SAP Production（DB 500GB + App 20 台） ← 最大ダウンタイム制約あり

4. Progress Tracking
   → HANA Migration Status（Full Backup → Replication → Apply redo logs）
   → App Server Migration Status（MGN で 20 台の進捗）
   → テスト検証ゲート（Wave 1・2 完了後にのみ Wave 3 実行許可）

4. Refactor Spaces でのモノリス分解

シナリオ：Java モノリシックアプリケーションを段階的にマイクロサービスに分解

Migration Hub の活用：

1. アプリケーショングループ
   → "E-commerce Modernization" グループ
   └─ Monolith（Java EAR 1GB、Tomcat 8.0）
   └─ Orders Microservice（Lambda + DynamoDB）
   └─ Inventory Microservice（ECS + Aurora）
   └─ Payments Microservice（Lambda + RDS）

2. リファクタリングウェーブ
   → Wave 1: Payments Microservice 抽出（2 週間）
   → Wave 2: Orders Microservice 抽出（3 週間）
   → Wave 3: Inventory Microservice 抽出（2 週間）
   → Monolith は最終的に削除

3. Strangler Fig Pattern 進捗
   → Refactor Spaces が API Gateway ルーティング管理
   → Migration Hub が抽出ウェーブの進捗追跡
   → Week 8 完了時点で "Monolith 30%" → "Microservices 70%"

5. DR（Disaster Recovery）統合

シナリオ：Elastic Disaster Recovery（DRS）で DR を構築しつつ、移行も同時実施

Migration Hub の活用：

1. 二層管理
   → MGN：本番移行ツール
   → DRS：本番移行中の DR レプリケーション
   → 両者の進捗を Migration Hub で統合表示

2. ウェーブシーケンス
   → DRS Replication：全サーバー継続的にレプリケーション（本番 24h）
   → MGN Replication：各ウェーブのサーバーのみ別途レプリケーション
   → 移行完了後 DRS は廃止

3. リスク管理
   → Migration Hub が "DRS Active" / "MGN Ready" 状態を並行表示
   → ウェーブ実行中に DRS で RPO 秒単位の保護を確認

6. クロスアカウント移行管理

シナリオ：複数 AWS アカウント（Hub Account + 5 Spoke Accounts）でのエンタープライズ移行

Migration Hub の活用：

1. アカウント構成
   ├─ Hub Account (ap-northeast-1) → Migration Hub ホーム配置
   ├─ Spoke 1 (ap-northeast-1) → Prod Apps
   ├─ Spoke 2 (ap-northeast-1) → Non-Prod Apps
   ├─ Spoke 3 (us-east-1) → Global Apps
   ├─ Spoke 4 (eu-west-1) → European Prod
   └─ Spoke 5 (ap-southeast-1) → APAC Apps

2. ホームリージョンから統一管理
   → 5 つのスポークの全移行進捗を 1 つのダッシュボードで表示
   → Application Groups（全リージョン統合）
   → Wave Planning（クロスアカウント依存関係）

3. IAM 統制
   → Hub Account：Migration Hub Admin 権限
   → Spoke Accounts：読み取り専用（Auto-Tagging で自動コスト追跡）
   → Federation：各アカウントの所有者が自分の移行進捗を確認

7. ハイブリッド移行ツール環境

シナリオ：AWS 内ツール（MGN・DMS）+ パートナーツール（Carbonite・RiverMeadow）を併用

Migration Hub の活用：

1. ツール統合
   → MGN API：AWS Application Migration Service（自動統合）
   → DMS API：AWS Database Migration Service（自動統合）
   → notify-migration-task-state API：Carbonite・RiverMeadow（手動統合）

2. API 呼び出し例（Carbonite の進捗報告）
   aws migrationhub notify-migration-task-state \
     --progress-update-stream '{"ProgressUpdateStreamName":"Carbonite-Stream"}' \
     --migration-task-name "server-windows-prod-01" \
     --task '{
       "Status":"IN_PROGRESS",
       "ProgressPercent":65,
       "StatusDetail":"Initial Sync: 65% Complete. Replication ongoing..."
     }'

3. ダッシュボード表示
   → 「Orders Application」
     ├─ MGN サーバー：5 台 / 10 台完了（50%）
     ├─ DMS DB：1 台 / 1 台完了（100%）
     ├─ Carbonite サーバー：3 台 / 5 台完了（60%）
     └─ 全体進捗：9 台 / 16 台（56%）

設定・操作の具体例

CLI ベースの操作

1. ホームリージョンの設定（必須・最初の 1 回）

# ホームリージョン設定（ap-northeast-1）
aws migrationhub-config create-home-region-control \
  --home-region ap-northeast-1 \
  --target '{
    "Type": "ACCOUNT",
    "Id": "123456789012"
  }' \
  --region us-east-1  # API は常に us-east-1 で呼び出す

# 出力例：
# {
#   "HomeRegionControl": {
#     "ControlId": "mhc-12345678",
#     "HomeRegion": "ap-northeast-1",
#     "Target": {
#       "Type": "ACCOUNT",
#       "Id": "123456789012"
#     },
#     "RequestedTime": "2026-04-27T10:00:00Z",
#     "HomeRegionSetTime": "2026-04-27T10:05:00Z"
#   }
# }

# 確認
aws migrationhub-config describe-home-region-control \
  --region us-east-1

2. Application Discovery Service との統合

# Application Discovery Service でサーバーを発見（事前実行が必要）
# ここでは発見済みを前提

# Discover されたサーバーを取得
aws discovery describe-servers \
  --region ap-northeast-1

# 出力例：
# {
#   "serversSnapshot": [
#     {
#       "serverId": "ds-0abc1234",
#       "hostName": "prod-web-01",
#       "ipAddress": "192.168.1.100",
#       "osName": "Amazon Linux 2",
#       "cpuCount": 4,
#       "totalMemoryInGB": 16
#     },
#     ...
#   ]
# }

3. Application Group の作成（ビジネスアプリケーション）

# Discovery Service API（同じコンソールから）
aws discovery create-application \
  --name "E-commerce Platform v2.0" \
  --description "Web + API + Database servers group for e-commerce" \
  --region ap-northeast-1

# 出力例：
# {
#   "applicationId": "app-12345678"
# }

# サーバーをアプリケーションに関連付け
aws discovery associate-configuration-items-to-application \
  --application-configuration-id app-12345678 \
  --configuration-ids ds-0abc1234 ds-0def5678 ds-0ghi9012 \
  --region ap-northeast-1

# アプリケーション内容確認
aws discovery describe-applications \
  --application-configuration-id-list app-12345678 \
  --region ap-northeast-1

4. パートナーツールの進捗報告（notify API）

# Carbonite、RiverMeadow などのサードパーティ移行ツールが使用
# ツール側から定期的に呼び出して進捗を報告

aws migrationhub notify-migration-task-state \
  --progress-update-stream '{
    "ProgressUpdateStreamName": "Carbonite-Migration-Stream"
  }' \
  --migration-task-name "server-windows-prod-db-01" \
  --task '{
    "Status": "IN_PROGRESS",
    "ProgressPercent": 45,
    "StatusDetail": "Initial replication: 45% complete. Estimate 3 hours to completion"
  }' \
  --region ap-northeast-1

# タスク状態確認
aws migrationhub list-migration-tasks \
  --resource-identifier-hint "server-windows-prod-db-01" \
  --region ap-northeast-1

# 出力例：
# {
#   "MigrationTaskSummaryList": [
#     {
#       "ProgressPercent": 45,
#       "Status": "IN_PROGRESS",
#       "MigrationTaskName": "server-windows-prod-db-01",
#       "ProgressUpdateStream": "Carbonite-Migration-Stream",
#       "UpdateDateTime": "2026-04-27T14:30:00Z"
#     }
#   ]
# }

5. ウェーブ管理（MGN Integration）

# ウェーブ作成（MGN ツール側で実行）
aws mgn create-wave \
  --name "Wave 1 - Non-Production" \
  --description "Development and Staging servers" \
  --region ap-northeast-1

# 出力例：
# {
#   "wave": {
#     "waveID": "wave-12345678",
#     "waveName": "Wave 1 - Non-Production",
#     "description": "Development and Staging servers",
#     "creationDateTime": "2026-04-27T10:00:00Z"
#   }
# }

# Migration Hub でこのウェーブの進捗を追跡
# （MGN が自動的に進捗報告するため手動操作は不要）

SDK ベースの操作（Python）

1. Application Discovery & Migration Hub 統合

import boto3
from datetime import datetime

# クライアント初期化
discovery_client = boto3.client('discovery', region_name='ap-northeast-1')
migrationhub_client = boto3.client('migrationhub', region_name='ap-northeast-1')

# Step 1: Discovered servers 取得
def get_discovered_servers():
    response = discovery_client.describe_servers()
    servers = response['serversSnapshot']
    print(f"Found {len(servers)} servers")
    return servers

# Step 2: Application group 作成
def create_application_group(app_name, app_description):
    response = discovery_client.create_application(
        name=app_name,
        description=app_description
    )
    app_id = response['applicationId']
    print(f"Created application: {app_id}")
    return app_id

# Step 3: サーバーをアプリケーションに関連付け
def associate_servers_to_app(app_id, server_ids):
    response = discovery_client.associate_configuration_items_to_application(
        applicationConfigurationId=app_id,
        configurationIds=server_ids
    )
    print(f"Associated {len(server_ids)} servers to {app_id}")
    return response

# Step 4: Migration task state を報告
def report_migration_progress(task_name, progress_percent, status):
    response = migrationhub_client.notify_migration_task_state(
        ProgressUpdateStream={'ProgressUpdateStreamName': 'Python-SDK-Stream'},
        MigrationTaskName=task_name,
        Task={
            'Status': status,  # IN_PROGRESS, COMPLETED, FAILED
            'ProgressPercent': progress_percent,
            'StatusDetail': f'Progress update: {datetime.now().isoformat()}'
        }
    )
    print(f"Reported {task_name}: {progress_percent}% {status}")
    return response

# 実行例
if __name__ == "__main__":
    # サーバー取得
    servers = get_discovered_servers()
    server_ids = [s['serverId'] for s in servers[:3]]  # 最初の 3 台
    
    # アプリケーショングループ作成
    app_id = create_application_group(
        app_name="Production E-commerce",
        app_description="Web + API servers"
    )
    
    # サーバー関連付け
    associate_servers_to_app(app_id, server_ids)
    
    # 進捗報告
    report_migration_progress(
        task_name="ecommerce-migration-wave1",
        progress_percent=30,
        status="IN_PROGRESS"
    )

IaC ベースの操作（CloudFormation）

Discovery & Application Group（CloudFormation/CDK）

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Application Discovery Service + Migration Hub Integration'

Resources:
  # Application Discovery Service Continuous Export
  ContinuousExport:
    Type: AWS::ApplicationDiscoveryService::ContinuousExport
    Properties:
      S3BucketName: !Ref DiscoveryDataBucket

  # Discovery Data Bucket
  DiscoveryDataBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub 'migration-discovery-data-${AWS::AccountId}'
      VersioningConfiguration:
        Status: Enabled
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true

  # Migration Hub Home Region Control（別途 CLI で実行）
  # Note: CloudFormation では直接サポートなし。以下は疑似コード
  # aws migrationhub-config create-home-region-control \
  #   --home-region ap-northeast-1 \
  #   --target Type=ACCOUNT,Id=<account-id>

  # CloudWatch Log Group for Migration Tracking
  MigrationLogGroup:
    Type: AWS::Logs::LogGroup
    Properties:
      LogGroupName: /aws/migration/hub-tracking
      RetentionInDays: 90

  # IAM Role for Migration Hub API calls
  MigrationHubRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: MigrationHubAPIRole
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service:
                - discovery.amazonaws.com
                - migrationhub.amazonaws.com
            Action: sts:AssumeRole
      Policies:
        - PolicyName: MigrationHubAccess
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  - discovery:*
                  - migrationhub:*
                  - s3:GetObject
                  - s3:PutObject
                  - logs:PutLogEvents
                Resource: '*'

Outputs:
  DiscoveryBucketName:
    Value: !Ref DiscoveryDataBucket
    Description: S3 bucket for discovery data
  
  MigrationHubRoleArn:
    Value: !GetAtt MigrationHubRole.Arn
    Description: IAM role ARN for Migration Hub API access

類似サービス比較表

ベストプラクティス

1. ホームリージョン選定

✅ 推奨：

• グローバル企業では最大移行リソースが集約されるリージョンをハブに（例：日本企業なら ap-northeast-1）
• 低遅延・高可用性リージョンを選定（us-east-1 は世界的ハブだが、リージョン遠い場合は検討）

❌ アンチパターン：

• 複数リージョンに分散したハブ選定（1 つだけ）
• 移行開始後のホームリージョン変更（変更不可）

2. Application Group の設計

✅ 推奨：

• ビジネスアプリケーション単位でグループ化（「CRM」「在庫管理」「決済」）
• 各アプリの依存関係を明確にマッピング（Application Discovery Service で自動検出）
• グループ内に 3～50 サーバーの粒度が最適

❌ アンチパターン：

• 技術スタック単位のグループ化（「Web Servers」「DB Servers」）→ ビジネス価値が不透明
• 1 グループに 500+ サーバー（ダッシュボードが冗長化）
• グループ内の依存関係を無視したウェーブ設計

3. Wave Planning & Sequencing

✅ 推奨：

• Wave 1（非本番環境）→ Wave 2（ステージング）→ Wave 3（本番）
• 各ウェーブで 1～2 週間の検証期間を設ける
• 進捗追跡：Wave N 完了 → Wave N+1 承認 → 実行

❌ アンチパターン：

• すべてのサーバーを同時に 1 Wave で移行
• 依存関係なしでランダムにウェーブを実行
• Wave N 実行中に Wave N+1 計画なし（スケジュール遅延）

4. ステークホルダーコミュニケーション

✅ 推奨：

• Migration Hub ダッシュボードへの読み取り専用アクセスを経営陣・PMO に付与
• 週次 migration status meeting で具体的な進捗数値を共有（「X/Y サーバー完了」）
• リスクサーバーを自動検出・報告（遅延、失敗サーバー）

❌ アンチパターン：

• 毎週手動で Excel レポート作成（時間がかかり、更新が遅れやすい）
• 抽象的な進捗報告（「順調です」）
• ステークホルダーへのアクセス権なし（情報隔離）

5. パフォーマンス最適化

✅ 推奨：

• 複数ウェーブの並行実行（Wave 1 検証中に Wave 2 実行開始）
• Application Group 内で非依存サーバーは並行リプリケーション
• Migration Hub メトリクスを CloudWatch に連携（カスタム監視ダッシュボード）

❌ アンチパターン：

• Wave 1 完了待ち → Wave 2 開始（直列実行で全体スケジュール延長）
• リプリケーション帯域幅を制限しない（ネットワーク過負荷）

6. テスト検証フェーズの統制

✅ 推奨：

• ウェーブごとに Test Cutover → Validation → Go/No-Go Decision
• Migration Hub で「Ready for Cutover」状態を明示的に設定
• Application 単位の SLA を定義（「Web App は 99.9% availability」）

❌ アンチパターン：

• テストカットオーバーをスキップしてそのまま本番カットオーバー
• テスト検証の Go/No-Go 判定基準なし（属人的判断）

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

2025-2026 最新動向

1. AWS Migration Hub 新規顧客受け入れ終了（2025 年 11 月 7 日）

詳細：

• AWS Migration Hub は 2025 年 11 月 7 日をもって新規顧客へのサービス提供を中止
• 既存顧客は引き続き利用可能（最低 1 年間はサポート継続予定）
• 代替サービス：AWS Transform（より統合的な移行・モダナイゼーション プラットフォーム）

代替戦略：

• 既存 Migration Hub ユーザー → AWS Transform への段階的移行
• 新規移行プロジェクト → AWS Transform を推奨

2. AWS Transform プラットフォーム（2025 年以降）

概要：Migration Hub の後継として、以下を統合：

• アプリケーションディスカバリー & アセスメント
• 複数移行ツール管理
• クラウドネイティブ化戦略の提案
• AI による最適化推奨

利点：

• Migration Hub よりも包括的な移行・モダナイゼーション機能
• AI/ML による 7R 推奨の精度向上
• Cost Optimization Engine との統合

3. CloudEndure 廃止予定（2026 年 3 月）

詳細：

• CloudEndure は 2026 年 3 月 31 日でサービス終了予定
• 既存ユーザーは AWS Application Migration Service（MGN）への無料移行を推奨

4. Application Discovery Service の拡張

最新機能：

• agentless scan の改善（より詳細な依存関係検出）
• クラウド VM（Azure・GCP）の発見機能強化
• API 速度向上（大規模スキャンで 3x 高速化）

5. Orchestrator の機能拡張

計画中：

• Orchestrator テンプレートの拡張（Oracle → PostgreSQL、Monolith → Kubernetes など）
• カスタムワークフロー定義の簡素化（GUI ベースの Workflow Builder）

学習リソース・参考文献

公式ドキュメント

AWS 公開トレーニング & ウェビナー

コミュニティ・ベンダー資料

実装例・チェックリスト

実装例：エンタープライズ移行プロジェクトのセットアップ

#!/bin/bash
# Migration Hub 全体セットアップスクリプト

set -e

ACCOUNT_ID="123456789012"
HOME_REGION="ap-northeast-1"
SPOKE_REGIONS=("ap-northeast-1" "us-east-1" "eu-west-1")

echo "=== Migration Hub セットアップ開始 ==="

# Step 1: ホームリージョン設定
echo "[1/5] ホームリージョン設定 ($HOME_REGION)..."
aws migrationhub-config create-home-region-control \
  --home-region $HOME_REGION \
  --target Type=ACCOUNT,Id=$ACCOUNT_ID \
  --region us-east-1

# Step 2: Discovery 初期化
echo "[2/5] Application Discovery Service 初期化..."
for region in "${SPOKE_REGIONS[@]}"; do
  aws discovery start-continuous-export \
    --region $region || echo "Already started in $region"
done

# Step 3: IAM ロール作成
echo "[3/5] IAM ロール作成..."
cat > /tmp/trust-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": ["discovery.amazonaws.com", "migrationhub.amazonaws.com"]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF

aws iam create-role \
  --role-name MigrationHubAdminRole \
  --assume-role-policy-document file:///tmp/trust-policy.json || echo "Role already exists"

aws iam attach-role-policy \
  --role-name MigrationHubAdminRole \
  --policy-arn arn:aws:iam::aws:policy/AWSApplicationDiscoveryServiceAccess

aws iam attach-role-policy \
  --role-name MigrationHubAdminRole \
  --policy-arn arn:aws:iam::aws:policy/AWSApplicationMigrationServiceFullAccess

# Step 4: CloudWatch ログ設定
echo "[4/5] CloudWatch ログ設定..."
aws logs create-log-group \
  --log-group-name /aws/migration/hub-tracking \
  --region $HOME_REGION || echo "Log group already exists"

aws logs put-retention-policy \
  --log-group-name /aws/migration/hub-tracking \
  --retention-in-days 90 \
  --region $HOME_REGION

# Step 5: S3 バケット作成（Discovery データ保存）
echo "[5/5] Discovery データ用 S3 バケット作成..."
BUCKET_NAME="migration-discovery-data-${ACCOUNT_ID}"
aws s3 mb s3://$BUCKET_NAME \
  --region $HOME_REGION || echo "Bucket already exists"

echo "=== Migration Hub セットアップ完了 ==="
echo "ホームリージョン: $HOME_REGION"
echo "Discovery データバケット: s3://$BUCKET_NAME"
echo "CloudWatch ログ: /aws/migration/hub-tracking"

マイグレーションチェックリスト

事前準備フェーズ

• [ ] ステークホルダー準備

  • [ ] CIO・CFO から移行予算・スケジュール承認
  • [ ] PMO 体制確立（Migration Lead、Wave Lead、Infrastructure Lead）
  • [ ] 経営陣への概要説明（移行リスク・コスト・メリット）

• [ ] インベントリ & 分析フェーズ

  • [ ] Application Discovery Service agent 配置（オンプレ全サーバーへ）
  • [ ] 1 週間以上スキャンして依存関係を自動検出
  • [ ] Migration Hub Strategy Recommendations で 7R 分析（Rehost / Replatform / Refactor 分類）
  • [ ] Application Group 定義（ビジネスアプリケーション粒度）

• [ ] AWS 環境準備

  • [ ] AWS Account & IAM 権限設定（Migration Hub Admin Role）
  • [ ] ホームリージョン決定・設定
  • [ ] Network（VPC・セキュリティグループ・VPN）準備
  • [ ] Staging 環境リソース確保

計画フェーズ

• [ ] Wave 計画

  • [ ] Wave 1（Non-Production）定義：5～10 アプリケーション
  • [ ] Wave 2（Pre-Production）定義：15～20 アプリケーション
  • [ ] Wave 3+ (Production)定義：残存アプリケーション
  • [ ] 各ウェーブの依存関係チェック（Dependency graph）

• [ ] リソース計画

  • [ ] MGN Staging Area subnet / EBS 容量確認
  • [ ] DMS Replication Instance サイズ決定（ソースDB サイズに応じた t3.3xlarge 等）
  • [ ] Network 帯域幅確保（オンプレ ← → AWS）

実行フェーズ

• [ ] Wave 1 移行

  • [ ] MGN / DMS Replication 開始（Initial sync）
  • [ ] Test Cutover 実行（テスト用 EC2 起動）
  • [ ] アプリケーション検証（ログ確認、機能テスト、パフォーマンス測定）
  • [ ] 問題があれば修正・ロールバック

• [ ] Wave 2・3+ 移行

  • [ ] Wave 1 完了→ Wave 2 Approval→実行
  • [ ] 同様に Test Cutover → 検証 → 本番 Cutover
  • [ ] Migration Hub でウェーブ進捗を追跡

本番カットオーバーフェーズ

• [ ] 最終チェック

  • [ ] DMS CDC（Change Data Capture）が 0 秒 latency か確認
  • [ ] MGN テストカットオーバーの全テスト合格
  • [ ] ロールバック計画・リハーサル実施

• [ ] カットオーバー実行

  • [ ] メンテナンスウィンドウ設定（オンプレ・AWS 通知）
  • [ ] MGN / DMS start-cutover コマンド実行
  • [ ] DNS / Load Balancer を AWS に切り替え
  • [ ] ビジネス検証（1～2 時間）

• [ ] カットオーバー後

  • [ ] オンプレサーバーのレプリケーション停止
  • [ ] 30 日間のロールバック期間を設定（緊急時対応）
  • [ ] AWS 環境のリソース最適化（Right-sizing）

まとめ

AWS Migration Hub は 「複数の AWS 移行ツール・パートナーツールの進捗を一元管理し、ポートフォリオ全体の可視化・ステークホルダー報告を自動化するダッシュボード」 である。

主な価値

1. 複数ウェーブ・複数ツールの統合管理：MGN・DMS・SAP on AWS・Refactor Spaces を 1 つのダッシュボードで進捗追跡
2. Application 依存関係の自動反映：Application Discovery Service で発見した依存関係がウェーブ計画に自動反映
3. ステークホルダーへのセルフサービス報告：PMO・経営陣が読み取り専用で進捗をリアルタイム確認
4. 大規模移行の統制：500+ サーバー移行プロジェクトでウェーブ・Application・リージョンを統一管理
5. コスト追跡の自動化：移行リソースへの自動タグ付けで Application 別コスト分析が可能

注意点

• 新規顧客受け入れ終了（2025 年 11 月 7 日）：新規プロジェクトは AWS Transform への移行を検討
• 依存関係の正確な入力が必須：Wave 計画の精度は Application Discovery Service のスキャン品質に依存
• 手動操作の併用が必要：ダッシュボール提供のみで、実際の移行実行は MGN・DMS など個別ツールを使用

適用判定

✅ 使うべき：

• 複数の AWS 移行ツール（MGN・DMS 等）を並行利用
• 数十～数百のアプリケーション・サーバーの移行
• 複数リージョン・複数ウェーブでの段階的移行
• PMO・ステークホルダーへの定期的な進捗報告が必要

❌ 不要：

• 単一ツール（MGN のみ）の小規模移行
• Azure・GCP が主体（Azure Migrate・Google Cloud Migrate を推奨）

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