AWS Migration Hub

解決する課題

大規模な移行プロジェクトでは、データベースは DMS、サーバーは別のサーバー移行ツール、ファイルは DataSync というように、対象ごとに異なる移行ツールを使うのが普通です。その結果、進捗はツールごとのコンソールに分散し、「全体で何割が終わっているのか」「このアプリケーションを構成するサーバー群はどこまで移ったのか」が把握しづらくなります。Migration Hub は、各ツールが報告する進捗を一か所に集約し、サーバーやアプリケーション単位でまとめて可視化することで、移行全体の状況を一目で追えるようにします。

• 複数の移行ツールに進捗が分散していて、全体像が見えない
• どのリソースの移行が完了/進行中/未着手なのかをまとめて把握したい
• 個々のサーバーではなく、アプリケーション（業務システム）単位で進捗を管理したい
• 移行前に、対象環境のサーバー構成や依存関係を把握してから計画を立てたい

主要概念と用語

• 移行ハブ（ホーム）: 進捗を集約する中心拠点。移行データを集約するリージョン（ホームリージョン）を1つ選び、そこに状況がまとまる
• アプリケーション: 複数のサーバーやリソースをまとめた論理的な単位。業務システム単位で進捗を追跡するためにグルーピングする
• サーバー / リソース: 移行対象となる個々のサーバーやデータベースなど。移行ツールから報告される進捗の最小単位
• ディスカバリ（探索）: 移行前に対象環境のサーバー構成・スペック・依存関係を収集する仕組み。エージェント型やエージェントレス型の収集方法がある
• 移行ステータス: 各リソースの状態（未着手・進行中・完了など）。連携ツールから自動で更新される
• 連携ツール: 進捗をハブへ報告する移行ツール群。DMS などの AWS ツールに加え、対応するサードパーティツールも含む
• ポートフォリオ評価: 収集したインベントリをもとに、移行の優先度や対象を計画するための分析的な活用

仕様・制限・クォータ

• 進捗を集約するホームリージョンを1つ選択して利用する。集約された移行状況はそのリージョンにまとまる
• 連携ツールから進捗が自動で報告・更新され、利用者はサーバー単位またはアプリケーション単位で状態を確認できる
• ハブ単体は移行を実行せず、追跡と可視化が主な機能。実際の移行は連携先の各ツールが担う
• ディスカバリで収集したサーバーのインベントリや依存関係をもとに、移行計画やアプリケーションのグルーピングに活用できる
• 連携できるツールや収集できる項目、各種の上限は時期によって変わるため、設計時に確認が必要

内部の仕組み

Migration Hub の中心はホームリージョンに置かれた集約の仕組みです。利用者はまずホームリージョンを1つ選び、移行対象となるサーバーやリソースを、必要に応じてアプリケーション単位にグルーピングします。移行を実行するのは DMS をはじめとする各種ツールであり、それらのツールは処理の進行に合わせて、どのリソースがどの状態にあるかをハブへ報告します。

ハブはこの報告を受け取り、リソースごとのステータスを更新したうえで、アプリケーション単位に集計して表示します。これにより、複数ツールにまたがる移行であっても、全体の進捗率や個別リソースの状態を一つの画面で追えるようになります。移行に先立つディスカバリでは、対象環境のサーバー構成や依存関係を収集し、その結果をもとにグルーピングや優先順位付けといった計画を立てられます。

設計パターン / ベストプラクティス

• アプリケーション単位でグルーピングする: サーバーを個別に追うのではなく、業務システム単位でまとめて進捗と完了を判断する
• まずディスカバリで現状把握: 移行に着手する前に対象環境のインベントリと依存関係を収集し、移行の波（ウェーブ）を計画する
• ホームリージョンを早期に決める: 進捗の集約先となるリージョンを最初に固定し、関係者が同じ場所で状況を見られるようにする
• 連携ツールを活かす: 進捗を手で管理せず、DMS などの連携ツールから自動報告される状態を一元的に確認する
• 計画と実行を分けて考える: ハブは可視化と計画の場、実際の移行は各ツールという役割分担を前提に運用設計する

運用・監視

• 移行の全体進捗とリソース単位のステータスは、ハブのコンソールや API でまとめて確認できる
• 連携ツールからの報告により状態が自動更新されるため、各ツールのコンソールを個別に開かなくても全体像を追える
• アプリケーション単位で完了/未完了を判断し、移行プロジェクトのマイルストーン管理に使える
• 進捗が更新されないリソースがある場合は、連携ツール側の設定や報告経路を確認する
• ディスカバリで収集したインベントリは、移行後の構成確認や計画の見直しにも活用できる

コスト

• Migration Hub の追跡・可視化機能そのものは基本的に追加料金なしで利用できることが多い
• 実際に費用が発生するのは、移行を実行する DMS や各種移行ツール側のリソースであり、ハブはそれらを集約しているだけ
• ディスカバリでデータを収集・保管する場合は、その収集・保存に関わる費用が発生し得る
• 連携先ツールの稼働コストやデータ転送費用は、各ツールの料金体系に従う
• コストの中心は「何で移すか（連携ツール）」側にあるため、ツールごとの料金を個別に見積もる

セキュリティ

• ハブやディスカバリの操作権限は IAM で管理し、移行プロジェクトの関係者に最小権限を割り当てる
• 収集したサーバーのインベントリや依存関係は機微な情報を含み得るため、アクセス権限を絞る
• 連携ツールがハブへ進捗を報告するための権限も、必要な範囲に限定する
• 操作の監査証跡は CloudTrail で記録し、誰がどの設定を変更したかを追えるようにする
• ディスカバリのエージェントを使う場合は、その配置先サーバーの取り扱いと収集範囲を管理する

Well-Architected の観点

• 運用上の優秀性: 複数ツールにまたがる移行の進捗を一元的に可視化し、アプリケーション単位で計画的にカットオーバーを管理できる
• 信頼性: ディスカバリで依存関係を事前に把握し、取りこぼしのない移行計画を立てられる
• セキュリティ: IAM による権限の最小化と CloudTrail による操作の監査で、集約された機微情報を保護する
• コスト最適化: ハブ自体の追加コストを抑えつつ、ポートフォリオ評価で移行対象と優先度を見極めてムダな移行を避ける

試験で問われるポイント

関連サービス・比較

実際にデータベースを移行する AWS DMS とよく対比されます。DMS は移行を実行するツール、Migration Hub は複数ツールの進捗を集約・可視化する管制塔であり、両者は競合ではなく組み合わせて使う関係です。

ハンズオン / CLI例

# 進捗を集約するホームリージョンの設定状況を確認
aws migrationhub-config describe-home-region-control \
  --target Type=ACCOUNT

# 進捗を追跡するアプリケーションを Application Discovery Service 側で作成
aws discovery create-application \
  --name "order-system" \
  --description "受注システムの移行対象グループ"

# ハブに登録された移行タスクの進捗一覧を取得
aws mgh list-migration-tasks \
  --max-results 50

# 特定アプリケーションの移行状態を確認
aws mgh describe-application-state \
  --application-id app-0123456789abcdef