AWS Application Discovery Serviceとは？新規受付終了後の使い方とAWS Transformへの移行先

AWS Application Discovery Service（ADS）は、オンプレミスのサーバーやデータベースの構成情報・使用率・通信相手を集めて、AWS移行の計画材料にするサービスです。ただし2025年11月7日に新規顧客の受付を終了しており、いま新しく移行調査を始めるならAWS Transformのdiscovery toolが公式の推奨先です。

この記事では、ADSが何を集めるサービスなのかを押さえたうえで、受付終了で何が変わったか、既存顧客が手元のデータをどう取り出すか、新規案件をAWS Transformでどう始めるかを、AWSの公式ドキュメントに沿って整理します。

まとめ：ADSの現状と使い分けの要点

• ADSはオンプレミスのサーバーとデータベースの構成・使用率・TCP接続を収集し、AWS Migration Hubのホームリージョンに保存する移行調査用サービス
• 2025年11月7日に新規受付を終了。それ以前にサインアップした既存顧客は、進行中の調査を完了するまで使い続けられる（新機能の追加はなく、セキュリティ更新のみ継続）
• Discovery Connectorは2025年11月17日にデータ受付を停止、データベース調査の連携先だったDMS Fleet Advisorは2026年5月20日にサポート終了
• 新規の移行調査はAWS Transformのdiscovery toolから始める。VMware用OVA、Hyper-V用VHD、既存Linuxサーバーへのインストールから配置方法を選べ、ADSからのデータ移行作業は不要
• 既存顧客は aws discovery start-export-task でCSVを、start-continuous-export でAthena分析用のデータを取り出せる

以下、ADSの仕組み、受付終了後の変化、収集方式の前提、データの取り出し方、移行先の選び方の順に説明します。

AWS Application Discovery Serviceの役割と収集データ

ADSの役割は、移行前の「棚卸し」を自動化することです。どのサーバーが何台あり、CPUやメモリをどれだけ使い、どのサーバー同士が通信しているかを集め、移行対象をアプリケーション単位にまとめる材料にします。

集めたデータはすべてAWS Migration Hubのホームリージョンに保存されます。公式ドキュメントは、収集を始める前にMigration HubのコンソールまたはCLIでホームリージョンを設定するよう求めています。ホームリージョンに選べるのは、Migration Hubのエンドポイントがある東京（ap-northeast-1）、バージニア北部、オレゴン、シドニー、フランクフルト、アイルランド、ロンドンの7リージョンです。データはMigration Hubの画面で見られるほか、CSVでエクスポートしてExcelで開いたり、Amazon AthenaやAmazon Quickで分析したりできます。

収集の手段は3系統です。

• Agentless Collector：VMware vCenterにOVAとして1台置き、配下の仮想マシンをまとめて調べる
• Discovery Agent：WindowsやLinuxのサーバー1台ずつにインストールし、プロセスや通信まで細かく取る
• インポート：Migration HubのテンプレートやRVToolsの出力を読み込み、エージェントを置かずに登録する

集めたサーバー情報は、Migration HubでEC2インスタンスタイプの推奨を出したり、移行後の費用見積もりに使ったりします。実際のサーバー移行はAWS Transform MGN（旧AWS Application Migration Service）、データベースの移行はAWS Database Migration Service（DMS）が担い、ADSはその手前の調査を受け持つ位置づけです。

ADSの新規受付終了日と既存顧客への影響

ADSのユーザーガイドは全ページの冒頭に「AWS Application Discovery Service is no longer open to new customers.」と表示しています。ADSの受付終了の告知ページによれば、新規受付の停止は2025年11月7日で、同じ日にAWS Migration Hubも新規受付を止めました。サービスそのものの停止日は示されていません。

ADS既存顧客の継続利用と関連機能の終了日

2025年11月7日より前にサインアップした顧客は、進行中の調査を完了するまで従来どおり使えます。告知ページは、調査プロジェクトの典型的な期間を4か月としたうえで、新機能は追加しないがセキュリティ更新とサービスの可用性は維持すると説明しています。

一方、個別の機能はすでに止まり始めています。

影響が大きいのはDMS Fleet Advisorの終了です。Agentless Collectorのデータベース・分析モジュールは、集めたデータベースのメタデータをDMS Fleet Advisorに渡して移行先の推奨を出す作りでした。そのFleet Advisorが2026年5月20日に使えなくなったため、ADSのドキュメントにはデータベース調査の手順が残っていても、推奨を受け取る先がありません。Fleet Advisorの終了告知は、データベース評価のプロジェクトをAWS Migration Evaluatorへ移すよう勧めています。SQL ServerとOracleであれば、後述のAWS Transform discovery toolでも収集できます。

新規利用者向けAWS Transformの機能・料金

AWSが受付終了の告知で推奨しているのは、2025年5月に提供を始めたAWS Transformです。ADSの調査機能はAWS Transformに引き継がれており、告知ページは移行に際してデータ移行も特別なツールも不要だと明記しています。既存のADSの調査は完了までADSで続け、新しい調査からAWS Transformで始める、という切り替え方になります。

中心になるのは、2025年11月24日のAWSブログで紹介されたAWS Transform discovery toolです。ブログはこれを「Agentless Collectorを置き換えるもの」と位置づけています。ADSとの主な違いは次のとおりです。

discovery toolはデータをアプライアンス内に保存し、ユーザーがエクスポートしてアップロードしない限りAWSには送りません。出力はAWS Migration Portfolio Assessment（MPA）形式で、AWS Transformのアセスメントに読み込ませて総保有コストの分析やビジネスケースを作ります。アプライアンスの要件は4 vCPU、16GBメモリ、最低35GBのディスクです。大規模なインベントリではディスク容量を増やす必要があり、VMwareを調査する場合はvCenterへのTCP 443の到達性も必要です。OS内部の情報は、LinuxならSSH（TCP 22）、WindowsならWinRM（TCP 5985／5986）で取りに行きます。

料金について、AWS Transformの料金ページは、Windows・VMware・メインフレームといったエンタープライズワークロードの移行とモダナイゼーションを現在は無料で提供し、カスタム変換と継続的モダナイゼーションを有料機能としています。将来の機能が有料になる可能性にも触れているため、契約前に料金ページを確認してください。

収集方式の違い：Agentless Collector・Discovery Agent・インポート

既存顧客がADSで調査を続ける場合、どの方式で何が取れるかはADSユーザーガイドの比較表で決まっています。要点を抜き出すと次のとおりです。

VMwareの仮想マシンが大半なら、まずAgentless Collectorで全体を把握し、依存関係を詳しく見たいサーバーだけにDiscovery Agentを足すのが公式の想定です。両者は同じ仮想マシンに対して同時に使えます。物理サーバーはDiscovery Agentかインポートでしか扱えません。Athenaでの時系列分析やネットワーク接続のCSV出力が必要なら、Discovery Agentが前提になります。

Discovery Agentの前提条件

エージェントは32ビットの実行ファイル1つで、32ビット・64ビットどちらのOSでも動きます。インストール前に満たすべき条件は次のとおりです。

• Migration Hubのホームリージョンを設定済みで、エージェントをそのリージョンに登録する
• 1.x系のエージェントが入っている場合は先にアンインストールする
• IAMユーザーに管理ポリシー AWSApplicationDiscoveryAgentAccess を付け、アクセスキーを発行する
• 外向きにTCP 443で arsenal-discovery.<ホームリージョン>.amazonaws.com（オレゴンの場合は arsenal.us-west-2.amazonaws.com）へ到達できる（受信ポートは不要。HTTP／HTTPSの非透過プロキシも設定できる）
• 自動アップグレードのため、ホームリージョンのAmazon S3へ到達できる
• NTPとの時刻ずれを直しておく（ずれていると登録が失敗する）

対応OSはWindows Server 2003 R2 SP2・2008 R1 SP2・2008 R2 SP1・2012 R1・2012 R2・2016・2019・2022、Amazon Linux 2、Ubuntu 12.04・14.04・16.04・18.04・20.04、RHEL 5.11・6.10・7.3・7.7・8.1、CentOS 5.11・6.9・7.3、SUSE 11 SP4・12 SP5・15 SP5などで、Linuxは少なくともIntel i686アーキテクチャに対応している必要があります。RHEL 9やUbuntu 22.04以降は一覧に載っていないため、該当するサーバーはAgentless Collectorかインポートで補います。エージェントは約15秒ごとにデータを取り、15分ごとにTLSで送信します。

Agentless Collectorの前提条件

Agentless CollectorはvCenterにOVAとして展開する仮想マシンです。公式の前提条件で押さえるべきは次の3点です。

• 対応するvCenter ServerはV5.5・V6・V6.5・6.7・7.0で、テスト済みは6.7と7.0。Amazon Linux 2023ベースのバージョン2（4コア・16GBメモリ）はESXi 6.5以降が必要
• vCenterの資格情報には、SystemグループのRead・View権限が要る
• IAMユーザーに管理ポリシー AWSApplicationDiscoveryAgentlessCollectorAccess を付ける

前提条件の対応版一覧にvCenter 8.0はありません。トラブルシューティングのページには、S3のURLからOVAを展開して失敗する場合の条件として「8.0 Update 1以降、または7.0 Update 3q以降」が書かれていますが、前提条件のほうは改訂されていません。vSphere 8へ更新済みの環境では、サポート範囲が曖昧なADSを延命するより、AWS Transform discovery toolへ切り替える方が確実です。外向き通信は arsenal-discovery・migrationhub-config・sts・public.ecr.aws などのAWSドメインへTCP 443で必要になります。セットアップ時に「AWS cannot be reached」と出る場合は、まずこのドメインへの通信がプロキシやファイアウォールで止められていないかを確認します。

既存顧客向け：収集データをCLIで取り出す手順

ADSでの調査を締めくくる、あるいはAWS Transformへ移る前に手元へ控えておくには、AWS CLIの aws discovery コマンドを使います。以下はAWS CLIをインストールし、対象アカウントの認証情報と各操作の権限を設定したBash向けの例です。東京リージョンをホームリージョンとして実行します。

# 登録済みのエージェント・コレクターと収集状態を確認
aws discovery describe-agents --region ap-northeast-1 \
  --query "agentsInfo[].{id:agentId,host:hostName,health:health,status:collectionStatus,version:version}"

# 収集済み資産の件数をまとめて確認
aws discovery get-discovery-summary --region ap-northeast-1

# EC2インスタンスタイプの推奨付きでCSVエクスポートを開始
aws discovery start-export-task --region ap-northeast-1 \
  --preferences '{"ec2RecommendationsPreferences":{"enabled":true,"cpuPerformanceMetricBasis":{"name":"AVG","percentageAdjust":0},"ramPerformanceMetricBasis":{"name":"AVG","percentageAdjust":0},"tenancy":"SHARED","preferredRegion":"ap-northeast-1"}}'

# 直前の出力にあるexportIdと一致する行を確認し、その行がSUCCEEDEDになるまで再実行してURLを取得
aws discovery describe-export-tasks --region ap-northeast-1 \
  --query "exportsInfo[].{id:exportId,status:exportStatus,url:configurationsDownloadUrl}"

start-export-task の出力形式はCSVだけです（GRAPHMLは非推奨になりました）。--preferences と --filters の両方を省略すると、全サーバー・アプリケーション・タグ・性能の要約がZIPにまとまり、Server、SystemPerformance、NetworkInterface、VMwareInfo、Applicationなどのファイルに分かれて出てきます。

--filters で指定できるのは1台のDiscovery Agentの agentIds だけです。この場合はネットワーク・プロセス・性能の詳細データが最大72時間分出力され、--start-time と --end-time で期間を切れます。詳細データのエクスポートは同時実行5件まで、1日2回までに制限されているため、調べるサーバーが多いときは要約エクスポートやAthena連携と組み合わせます。

収集を止めるときは stop-data-collection-by-agent-ids を使います。batch-delete-agents でエージェントを削除しても収集済みデータは消えないため、データの削除は start-batch-delete-configuration-task で別に行います。

Athenaでの依存関係分析

Discovery Agentのデータは、継続エクスポート（Continuous Export）を有効にするとAmazon Athenaでクエリできます。コンソールではMigration Hubの［Data Collectors］→［Agents］で「Data exploration in Amazon Athena」を有効にし、CLIなら aws discovery start-continuous-export を実行します。初回はAthenaにデータが現れるまで最大30分かかります。

継続エクスポートの対象はDiscovery Agentのデータだけで、Agentless Collectorのデータは流れません。有効にすると、アカウント内にAmazon Data Firehoseのストリーム、データを溜めるS3バケット、Athenaから参照するためのAWS Glue Data Catalogが作られます。有効化するときにコンソールが関連費用への同意を求めるとおり、Firehoseの取り込み量、S3の保存容量、Athenaのスキャン量に応じた利用料がADSとは別に発生します。分析を終えたら、aws discovery describe-continuous-exports で確認したエクスポートIDを aws discovery stop-continuous-export --export-id に渡して継続エクスポートを止めます。止めてもS3に溜まったデータとGlue Data Catalogは残るため、保管が不要なら削除し、Firehoseのストリームも片付けておきます。サーバーごとの時系列の性能、実行中のプロセス、サーバー間の通信を用意済みのクエリで見られるほか、既存のCMDBのエクスポートを読み込んで突き合わせることもできます。

ADSを使い続ける場面とAWS Transformへ移る判断

既存顧客がADSとAWS Transformのどちらを使うかは、調査がいまどの段階にあるかで決まります。

• ADSで調査中の案件は、完了までADSで続ける。告知ページが既存プロジェクトの継続を保証している。途中でツールを替える場合は、収集間隔・項目・集計方法の違いを確認してから前後を比較する
• 新しい移行調査はAWS Transformで始める。ADSには新機能が入らず、Migration Hubも新規受付を終えているため、ADSで始める利点がない
• データベースの棚卸しはADSでは完結しない。連携先のDMS Fleet Advisorが2026年5月20日に終了しており、AWSはMigration Evaluatorへの移行を勧めている。SQL ServerとOracleならAWS Transform discovery toolでも収集できる

既存顧客でもADSを避けたいのは、調査データをAWSへ持ち出すこと自体が禁止されている環境です。ADSは収集方式を問わずデータをホームリージョンへ送って保存する仕組みなので、この制約は方式を替えても解消しません。AWS Transform discovery toolはインターネット接続なしで収集でき、エクスポートしたファイルをアップロードするかどうかを利用者が決められます。ただし、AWS Transformで総保有コストやビジネスケースを作るには、最終的にそのファイルのアップロードが必要です。

vSphere 8へ更新済みの環境はAgentless Collectorの前提条件から、RHEL 9やUbuntu 22.04以降のサーバーはDiscovery Agentの対応OS一覧から外れます。どちらも方式ごとの制約なので、該当する範囲が広ければ新しい調査はAWS Transformに寄せ、狭ければインポートで補うのが現実的です。discovery toolを選ぶ場合も、配置先の要件と対象サーバーへの接続・認証（SSH、WinRM）は事前に確認します。

調査が終わった後の実作業は、サーバーの移行がAWS Transform MGN、データの移行がクラウドデータ移行の手順で整理した各ツールの領域になります。オンプレミスとAWSを並行運用する期間が長くなるなら、ハイブリッドクラウド移行の接続方式とネットワーク設計も先に決めておきます。

よくある質問

AWS Application Discovery Serviceは今から新規に使えますか？

使えません。2025年11月7日に新規顧客の受付を終了しています。それ以前にサインアップしたアカウントだけが、進行中の調査を完了するまで利用できます。新しく始める場合は、AWSが推奨するAWS Transformのdiscovery toolを使います。

ADSの料金はかかりますか？

ADS自体は無料です。AWSの規範ガイダンス（移行ツールの比較ページ）は、ADSの料金モデルを「No charge」としています。ただし、Athenaで分析するための継続エクスポートを有効にすると、Amazon Data Firehose、S3、Athenaの利用料が別に発生し、有効化時にコンソールが費用への同意を求めます。後継のAWS Transformは、エンタープライズワークロードの移行を現在は無料で提供しています。

Agentless CollectorとDiscovery Agentはどちらを選べばよいですか？

VMwareの仮想マシンを一括で把握するならAgentless Collector、物理サーバーやプロセス単位の依存関係まで見たいならDiscovery Agentです。Athenaでの時系列分析やネットワーク接続のCSV出力もDiscovery Agentでしかできません。両方を同じ仮想マシンに併用することもできます。

AWS Migration Hubとの関係は何ですか？

ADSが集めたデータはMigration Hubのホームリージョンに保存され、Migration Hubの画面でサーバーの一覧やネットワーク図、アプリケーションへのグループ化、移行状況の追跡に使います。そのMigration Hubも2025年11月7日に新規受付を終え、戦略の推奨やEC2インスタンスの推奨、Orchestratorなどの機能はAWS Transformに引き継がれています。

ADSのデータをAWS Transformへ移す必要はありますか？

ありません。AWSの告知ページは、AWS Transformへの切り替えにデータ移行は不要だと明記しています。ADSの調査はADSで完了させ、新しい調査をAWS Transformで始めます。ADSのデータを手元に残したい場合は、start-export-task でCSVをダウンロードしておきます。

関連記事

• AWS Transform MGN（旧AWS Application Migration Service）とは｜料金・対応OS・移行手順【2026年版】
• AWS Database Migration Service（DMS）とは？サーバーレスと同種・異種移行の使い分け・料金を実装者目線で解説
• クラウドデータ移行の手順とは?移行ツール・整合性検証・大容量転送の実務を実装者向けに解説
• ハイブリッドクラウド移行とは？接続方式・ネットワーク設計・アプリ配置判断まで解説
• Amazon Athena（アテナ）とは？使い方・クエリの書き方・料金・Redshiftとの違いを解説