移行戦略（7R）を正しく選定するには、まず「何を、どれだけ、どう移行するか」を正確に把握する必要があります。この移行前アセスメントを担うのが AWS Application Discovery Serviceです。

SAA レベル：基礎概念

Application Discovery Serviceの基本

オンプレミス環境のサーバー構成（CPU、メモリ、ディスク使用率）や、サーバー間の通信関係（依存関係）を自動的に収集する
収集したデータはMigration Hubと連携し、移行計画の基礎データとして活用される

SAA 試験のポイント

移行を計画する前に、「どのサーバーが、どのサーバーと通信しているか」という依存関係を可視化することが重要です。依存関係を把握せずに一部のサーバーだけを移行すると、オンプレミスに残ったサーバーとの通信が断たれ、システム障害を引き起こすリスクがある、という基本認識がSAAで問われます。

SAP レベル：高度な設計シナリオ

エージェント型とエージェントレス型の使い分け

SAP 試験のポイント

Application Discovery Serviceには2つの収集方式があります。**エージェントレス型（Agentless Discovery Connector）**はVMware環境向けで、各VM上にエージェントをインストールせずにハイパーバイザーレベルで情報を収集します。**エージェント型（Discovery Agent）**は各サーバーに直接インストールし、より詳細なプロセスレベルの依存関係やパフォーマンスデータを収集できます。SAPでは、「大量のVMware環境をすばやく概観したい」→エージェントレス型、「特定の重要なサーバー群の詳細な依存関係を正確に把握したい」→エージェント型、という使い分けが問われます。

方式	収集できる情報の粒度	導入の手間
エージェントレス型	VMレベルの概略情報（VMware環境限定）	低い（各VMへの個別インストール不要）
エージェント型	プロセスレベルの詳細な依存関係・性能データ	各サーバーへの個別インストールが必要

依存関係マッピングによる移行波（Wave）の設計

SAP 試験のポイント

数百台規模のサーバーを一度に移行するのは非現実的です。SAPレベルでは、収集した依存関係データを分析し、互いに密接に通信するサーバー群を1つの「移行波（Migration Wave）」としてグルーピングし、波ごとに移行する計画設計が問われます。依存関係の強いサーバー群を分割して別々の波で移行すると、移行期間中に一時的なネットワーク分断が生じるリスクがあります。

設計上の落とし穴

「移行しやすいサーバーから順に、依存関係を考慮せず着手する」という進め方は、移行中に予期しない通信断が発生するリスクを高めます。SAPレベルでは、必ず依存関係マッピングの結果に基づいて移行波を設計することが、円滑な移行プロジェクトの前提条件として問われます。

Migration Evaluatorとの連携（TCO評価への橋渡し）

Application Discovery Serviceで収集したパフォーマンスデータ（CPU/メモリ使用率）は、次記事で解説するMigration Evaluatorでの適正なインスタンスサイジング・TCO試算の入力データとしても活用される

まとめ

SAA: 依存関係の可視化が移行計画の前提であること、Application Discovery Serviceの基本機能を理解する。
SAP: エージェント型/エージェントレス型の使い分け、依存関係に基づく移行波の設計ができる。

次は TCO評価・移行優先順位付けを見ていきましょう。