Application Discovery ServiceとApplication Migration Service

既存ワークロードをAWSへ移行するときは、

現在環境を把握する
↓
移行対象とDependencyを整理する
↓
実際にSource ServerをAWSへ移行する

という流れで考えます。

この中で役割が異なるのが、

AWS Application Discovery Service
↓
既存環境の発見・Inventory・Dependency把握

AWS Application Migration Service
↓
Source ServerをReplicationしてRehost

です。

なお、2026年時点では、AWS Application Discovery Serviceは新規顧客の受付を終了し、AWS Application Migration ServiceはAWS Transform MGNへ名称変更されています。

固定されたサービス名だけを覚えるのではなく、どの機能が「環境調査」で、どの機能が「実際のRehost移行」なのかを判断できることが重要です。

1. 環境調査と移行は別の処理

まず区別する必要があるのは、既存環境を調査することと、既存サーバーをAWSへ移すことです。

何台のサーバーがあるか、CPU / メモリ利用率はどうか、どのプロセスが動いているか、どのサーバー同士が通信しているかを調べたい場合、目的は環境調査です。

一方、既存サーバーのディスクをAWSへReplicationし、AWS上でテストして本番切り替えを行いたい場合、目的は移行です。

環境調査
≠
移行

2. AWS Application Discovery Serviceは既存環境を把握する

AWS Application Discovery Service は、オンプレミス環境などの既存サーバーに関する情報を収集し、移行計画に利用するサービスです。

サーバー構成、OS、CPU、メモリ、ディスク、利用率、実行中プロセス、ネットワーク接続などの情報を収集できます。

この情報を使って、Inventoryを作る、Dependencyを把握する、関連サーバーをアプリケーションとして整理する、移行計画を作る、といった作業につなげます。

重要なのは、AWS Application Discovery Service自体がSource ServerをAWSへRehostするわけではないことです。

3. Dependency / Inventoryを移行計画へ使う

例えば、Inventory上ではウェブサーバーA、アプリケーションサーバーB、データベースCという3台のSource Serverが存在するとします。

ネットワーク接続情報を確認すると、

ウェブサーバーA
↓
アプリケーションサーバーB
↓
データベースC

というDependencyが判明する場合があります。

単なるサーバー一覧では3台の独立したサーバーに見えても、実際には1つの業務アプリケーションを構成する相互依存サーバーかもしれません。

このため環境調査で得たInventoryとDependencyは、アプリケーションのグループ化、移行対象の整理、Wave Planning、移行時のテスト範囲などへ利用できます。

4. AWS Application Discovery AgentとAWS Replication Agentを混同しない

AWS Application Discovery Agent は、既存環境の構成情報、性能情報、実行中プロセス、ネットワーク接続などを収集するためのエージェントです。

一方、Rehost移行で使用するAWS Replication Agentは、Source ServerのデータをAWS側へReplicationするためのものです。

AWS Application Discovery Agent
→ 調査・Inventory・Dependency

AWS Replication Agent
→ Source ServerのデータReplication

5. AWS Application Discovery Serviceの現在の位置付け

AWS Application Discovery Serviceは、2025年11月7日から新規顧客の受付を終了しています。

一方、受付終了前から利用している顧客の進行中の検出プロジェクトは、AWS Application Discovery Serviceで完了まで継続できます。

ただし、既存顧客であっても今後の新しい検出プロジェクトをAWS Application Discovery Serviceで開始するという意味ではありません。新しい検出・評価プロジェクトにはAWS Transformが案内されています。

進行中の既存プロジェクト
→ AWS Application Discovery Serviceで完了可能

新しいプロジェクト
→ AWS Transformを検討

6. AWS Application Migration Serviceは現在AWS Transform MGN

従来のAWS Application Migration Service（MGN）は、2026年6月8日にAWS Transform MGNへ名称変更されました。

名称は変わりましたが、主要なMGNのReplication機能は継続しています。

AWS Application Migration Service
=
現在のAWS Transform MGN

MGNは、既存のSource Serverを大きく作り変えずAWSへ移行するRehostに適したサービスです。

7. RehostではSource Serverを大きく変更しない

Rehost は、既存ワークロードのアーキテクチャを大幅に変更せずAWS上へ移す方式です。

オンプレミスVM
↓
Amazon EC2

のような移行です。

MGNではSource ServerのデータをAWS側へReplicationし、AWS上で起動できる状態へ準備します。アプリケーションを全面的に書き換える、コンテナへ再設計する、データベースエンジンを変更することを主目的としたサービスではありません。

MGNの中心は、Source ServerをRehostすることです。

8. Source ServerがReplicationの起点になる

MGNでは移行元となるサーバーをSource Serverとして扱います。Source Serverには物理サーバー、仮想マシン、他クラウド上のサーバーなどを含めることができます。

一般的な流れでは、Source ServerへAWS Replication Agentを導入します。

Source Server
↓
Replication
↓
AWS

というデータ転送が開始されます。Source Serverをすぐ停止するわけではなく、業務を継続しながらReplicationを進め、本番切り替えへ備えます。

9. ReplicationをMGNの移行ライフサイクルへつなげる

MGNではSource ServerのデータをAWS側へReplicationします。

ここで重要なのはReplicationの詳細な仕組みそのものではなく、

Source Server
↓
Replication
↓
Staging Area
↓
Test Instance
↓
Cutover Instance

というMGN固有の移行ライフサイクルへどう接続されるかです。

ReplicationによってAWS側へデータを準備した後、本番前の検証はTest Instance、本番移行はCutover Instanceへ進みます。

10. Replication先はStaging Area

Source ServerからReplicationされたデータは、最初から本番用EC2へ直接書き込まれるわけではありません。

MGNではStaging Areaを使用します。

Source Server
↓
Replication
↓
Staging Area
↓
Test Instance / Cutover Instance

Staging AreaにはReplicationを処理するためのAWSリソースが配置され、Source ServerからのReplicationを受け取り、後続の起動へつなげます。

11. Staging Areaは本番サーバーではない

Replicationされたデータがあるからといって、そのまま本番アプリケーションとして使えるわけではありません。

Staging AreaはReplicationのための領域であり、ユーザーが直接利用する本番EC2環境ではありません。

Staging Area
↓
Test Instance

で検証し、本番切り替えでは、

Staging Area
↓
Cutover Instance

へ進みます。

12. Test Instanceで本番切り替え前に検証する

Replicationが正常に進み、テスト可能な状態になったらTest Instanceを起動できます。

Test Instanceでは、OSが起動するか、アプリケーションが起動するか、ネットワーク接続は正しいか、業務機能が動作するかなどを、本番切り替え前に確認します。

Test Instanceを起動した
=
本番切り替え完了

ではありません。Test Instanceは本番切り替え前の検証段階です。

13. テストと本番切り替えを分離する

Source Server
→ 本番業務を継続

Test Instance
→ AWS側で動作確認

という形で、本番移行前にAWS側の環境を確認できます。

この段階で問題が見つかれば、ネットワーク設定、EC2起動設定、アプリケーション設定などを確認し、切り替え前に修正できます。

本番停止時間の中で初めてAWS側をテストするのではありません。

14. Cutover Instanceが本番移行先になる

テストが完了し、本番切り替え準備が整ったらCutover Instanceを起動します。

Replication正常
↓
Test Instanceで検証
↓
切り替え準備完了
↓
Source Server側の業務処理を停止
↓
Replication遅延を解消
↓
Cutover Instanceを起動
↓
本番確認
↓
切り替えを確定

Cutover Instanceは、本番移行のために起動するターゲットです。

15. Test InstanceとCutover Instanceを混同しない

Test Instance
↓
検証

Cutover Instance
↓
本番切り替え

16. 検出情報だけではMGNのReplicationは始まらない

AWS Application Discovery ServiceによってSource Server Aを発見し、CPU利用率、Dependency、Inventoryを整理できても、そのサーバーが自動的にMGNでReplicationされるわけではありません。

環境調査と移行は別の処理だからです。

移行対象Source ServerをMGNへ追加
↓
Replicationを開始
↓
Staging Area
↓
Test Instance
↓
Cutover Instance

という移行ライフサイクルへ進めます。

17. 環境調査の目的とMGNの目的を整理する

環境調査

既存環境を知りたい
↓
Inventory
Dependency
利用状況
構成情報

MGN

既存Source ServerをRehostしたい
↓
Replication
Staging Area
Test Instance
Cutover Instance

調査したいならAWS Application Discovery Service等の検出・評価機能、実際にRehostしたいならMGN、と整理します。

18. この段階ではデータ転送サービスの比較へ広げない

MGNはSource ServerをRehostするためのサービスです。

ファイルをAWSへ転送する、大量データをオンラインで送る、特定プロトコルでファイルを受け付けるなど、Source ServerのRehostとは異なるTransfer Strategyも存在します。

ここではそれらの個別サービス選択までは行いません。判断するのは、既存Source ServerそのものをRehostするならMGNが候補になるという範囲までです。

19. 全体の流れ

既存環境
↓
環境調査
↓
Inventory / Dependencyを把握
↓
移行対象を決定
↓
Source ServerをMGNへ追加
↓
Replication
↓
Staging Area
↓
Test Instance
↓
アプリケーション検証
↓
切り替え準備
↓
Cutover Instance
↓
Rehost完了

SAP-C02では、AWS Application Discovery ServiceとMGNの役割を混同しないことと、

Replication
↓
Staging Area
↓
Test Instance
↓
Cutover Instance

の関係が重要です。