AWS Application Discovery Service 完全ガイド v2.0（2026年最新対応）

エンタープライズ移行計画のインベントリ・依存関係自動検出

AWS Application Discovery Service（ADS） は、「オンプレミスのサーバー・アプリケーション・データベースのインベントリ・構成・パフォーマンス・TCP依存関係を自動検出し、AWS への移行計画を支援するサービス」 である。Migration Hub・Migration Evaluator と統合し、数百～数千台のオンプレサーバーの全体像を把握し、ウェーブ計画・コスト見積もり・リスク評価に必須のデータを提供する。2026年現在、新規顧客受け入れ終了に近づいているが、既存ユーザーは継続利用可能。

目次

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

ドキュメントメタデータ

• 最終更新: 2026-04-27
• バージョン: v2.0
• 対象者: Migration Architect、Infrastructure Manager、IT Portfolio Manager、Enterprise Architect
• 難易度: 初級～中級
• 関連サービス: Migration Hub、Migration Evaluator、MGN、DMS、Strategy Recommendations、AWS Transform
• 廃止・変更予定: 新規顧客受け入れ終了に近づいているが、既存顧客は継続利用可能。Migration Hub との統合は継続

概要と課題

本質

AWS Application Discovery Service は 「オンプレミス環境の全サーバー・DB・アプリケーション・依存関係を自動的に検出し、移行計画・コスト見積もり・リスク評価の根拠となるデータを収集するサービス」 である。以下を実現する：

• 全体インベントリの自動化：手作業による棚卸しの廃止、スプレッドシート管理の終焉
• 依存関係の可視化：TCP通信・プロセス・ネットワークフローから “このサーバー停止時の影響範囲” を自動算出
• Migration Hub との統合：発見データが自動的にハブに連携され、ウェーブ計画・進捗管理に反映
• コスト見積もり：サーバースペック・使用率データを Migration Evaluator に供給し、AWS月額コスト算出

従来の課題

AWS Application Discovery Service が提供する解決策

✅ エージェント / エージェントレスでの自動発見：1 週間で数百～数千台のインベントリを自動収集
✅ TCP 依存関係の自動マッピング：サーバー間の通信フローをグラフ化
✅ パフォーマンスメトリクスの継続収集：CPU・メモリ・ディスクの平均・ピーク使用率を時系列記録
✅ Migration Hub との自動連携：発見データがハブに自動反映、ウェーブ計画に活用
✅ データベース発見機能：Oracle・SQL Server・MySQL・PostgreSQL の構成・スキーマを自動取得
✅ コスト見積もり支援：スペック・使用率データを Migration Evaluator に供給

このサービスを選ぶ理由

なぜ AWS Application Discovery Service なのか？

1. 規模の大きなデータセンター移行

   • 数百～数千台のサーバーを手動で棚卸しするのは実務的不可能
   • Application Discovery は 1 週間で全体インベントリを自動化
   • オンプレミス全体の見える化が初めて可能

2. 正確なウェーブ計画

   • 発見した TCP 依存関係（「WebサーバーA → DBサーバーB」）に基づいて、自動的に移行順序を提案
   • 依存関係の漏落による移行失敗を事前防止
   • Migration Hub と統合すれば、計画 → 実行 → 追跡が一貫

3. 右サイジング・コスト見積もり

   • CPU・メモリ使用率データがあれば、適切な EC2 インスタンスタイプを選定可能
   • オーバープロビジョニング（高額インスタンス購入）を回避
   • Migration Evaluator と連携して月額 AWS コスト 3 年予測を算出

4. 複数の発見方法

   • Agentless Collector（VMware vCenter 用）：インストール最小化
   • Discovery Agent（Linux / Windows）：詳細なプロセス・ネットワーク情報
   • File-based Import：既存のインベントリスプレッドシートからのインポート
   • 環境に応じた柔軟な選択可能

5. パートナーツール統合

   • CloudEndure・Carbonite 等のサードパーティ発見ツールの API も利用可能
   • Application Discovery のデータと統合して、より包括的なインベントリを構築

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

• 小規模移行（< 10 台）：管理手数料より工数が大きい
• クラウドネイティブな新規構築：既存インベントリ不要
• オンプレミス内部の実験：移行を前提としない

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

全体構成図（Mermaid 1）

graph TB
    subgraph OnPrem["On-Premises Environment"]
        VM["VMware vCenter<br/>(VMs)"]
        PS["Physical Servers<br/>(Windows / Linux)"]
        DB["Databases<br/>(Oracle / SQL Server<br/>MySQL / PostgreSQL)"]
    end
    
    subgraph Discovery["Discovery & Collection Layer"]
        AC["Agentless Collector<br/>(OVA / vCenter)"]
        DA["Discovery Agent<br/>(Windows / Linux binary)"]
        FI["File-based Import<br/>(CSV / Excel)"]
    end
    
    subgraph Processing["Data Processing & Analysis"]
        DDAPI["Application Discovery Service<br/>Data Aggregation API"]
        DEP["Dependency Mapper<br/>(TCP connections)"]
        PM["Performance Metrics<br/>(CPU / Memory / Disk)"]
    end
    
    subgraph Migration["Migration Hub Integration"]
        MH["Migration Hub<br/>(Home Region)"]
        APP["Application Groups<br/>(Logical grouping)"]
        WAVE["Wave Planning<br/>(Dependency-aware)"]
    end
    
    subgraph Integration["Integration & Analysis"]
        ME["Migration Evaluator<br/>(Cost modeling)"]
        SR["Strategy Recommendations<br/>(7R analysis)"]
        EXPORT["Data Export<br/>(S3 / Athena / Excel)"]
    end
    
    VM --> AC
    PS --> DA
    DB --> AC
    
    AC --> DDAPI
    DA --> DDAPI
    FI --> DDAPI
    
    DDAPI --> DEP
    DDAPI --> PM
    
    DEP --> MH
    PM --> MH
    
    MH --> APP
    APP --> WAVE
    
    PM --> ME
    DDAPI --> SR
    MH --> EXPORT

データフロー詳細

1. 発見フェーズ（Week 1）
   Agentless Collector / Discovery Agent
   → VM / Physical / DB インベントリ収集
   → CPU・メモリ・ディスク使用率の時系列記録（15秒～60分間隔）
   → TCP接続・プロセス一覧の取得
   
2. 分析フェーズ（Week 2-3）
   Application Discovery Service API
   → 依存関係グラフの構築（サーバー間TCP通信を抽出）
   → Application の自動グループ化提案
   → パフォーマンス統計（平均・ピーク値）の計算
   
3. 計画フェーズ（Week 4-5）
   Migration Hub統合
   → 発見データがハブに自動反映
   → Wave計画の自動提案（依存関係に基づく）
   → Application単位での進捗管理準備
   
4. 見積もりフェーズ（Week 5-6）
   Migration Evaluator連携
   → Server spec + 使用率 → EC2 instance type 推奨
   → Database → RDS target 推奨
   → 3年間の Total Cost of Ownership 計算

コアコンポーネント

1. Agentless Collector（VMware エージェントレス）

役割：VMware vCenter 環境全体の VM 発見・スキャン（インストール最小化）

仕様：

• 形式：OVA ファイル（vCenter にデプロイする仮想アプライアンス）
• 収集対象：vCenter 傘下の全 VM・ホスト
• 静的データ：ホスト名・IP・MAC・ディスク容量・CPU/メモリスペック・DB エンジン・スキーマ
• パフォーマンスデータ：CPU・RAM・ディスク I/O の平均・ピーク値（60分間隔）
• ネットワーク：VM 間の TCP 通信フロー（ハイパーバイザーレベル）
• 収集間隔：60分（Agentless）

利点：

• 各 VM にエージェントインストール不要（数千台でも管理簡素）
• VM 内部を「見ることなく」ハイパーバイザーデータで発見可能

制限：

• プロセス一覧・ネットワーク接続の詳細が取得不可
• VM 内部の詳細分析が必要な場合は Discovery Agent 補完必須

2. Discovery Agent（エージェントベース・詳細）

役割：各サーバー（Linux / Windows）にインストール、詳細なパフォーマンス・プロセス・ネットワーク情報収集

仕様：

• インストール対象：Amazon Linux・RHEL・CentOS / Windows Server 2008R2 以降
• 静的データ：ホスト名・IP・MAC・ハードウェア・OS・インストールソフトウェア一覧
• パフォーマンス：CPU・メモリ・ディスク・ネットワーク使用率（15秒間隔・時系列）
• プロセス：実行中の全プロセス・コマンドライン
• ネットワーク：インバウンド・アウトバウンド TCP/UDP 接続・ポート・プロトコル
• 収集間隔：15秒（Agent ベース・高精度）

利点：

• VM 内部の詳細情報が取得可能（どのアプリがどのポートを使っているか）
• 依存関係マップの高精度化
• 時系列データで使用率パターンを分析可能（バッチ処理の時間帯等）

制限：

• 各サーバーへのエージェントインストール必要（数千台は工数かかる）
• ネットワークセグメント間の疎通確保必要

3. Application Groups（アプリケーション論理グループ）

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

構成例：

"E-commerce Platform" Application Group
├── Web Servers（Apache Tomcat）：3 台
├── API Servers（Java Spring Boot）：2 台
├── Application Database（Oracle 100GB）：1 台
├── Cache Server（Redis）：1 台
├── Load Balancer（F5 BIG-IP）：1 台
└── NAS Storage（NetApp）：500GB

メリット：

• アプリケーション単位でのステークホルダー報告
• ウェーブ計画時に依存関係が自動反映
• 移行後のコスト追跡（Application 別の月額 AWS コスト可視化）

4. Dependency Mapping（依存関係マッピング）

役割：Discovery Agent が収集した TCP 接続から、サーバー間・サービス間の依存グラフを自動構築

具体例：

Web Server A (port 80)
    ↓ TCP:3306 (MySQL query)
Application Database B (port 3306)
    ↓ TCP:6379 (cache fill)
Redis Server C (port 6379)

Web Server A が停止 → B にも影響 → C も巻き添え

自動検出内容：

• 同期呼び出し（REST API・DB クエリ）
• 非同期呼び出し（メッセージキュー、Syslog）
• ファイル共有（NFS・SMB）
• ライセンスサーバー依存（複数アプリが共有）

5. データベース発見（Database Discovery Module）

役割：Agentless Collector のデータベース・分析系サーバー発見モジュール

対応 DB エンジン：

• Oracle（11g / 12c / 19c）
• SQL Server（2008R2 / 2012 / 2016 / 2019 / 2022）
• MySQL（5.7 / 8.0）
• PostgreSQL（9.6 / 10～15）

収集情報：

• DB サーバーのスペック・OS
• Database インスタンス数・スキーマ・オブジェクト数
• テーブルサイズ・インデックス構成
• CPU・メモリ使用率（LDAP / WMI クエリ）

用途：

• DMS Fleet Advisor と統合して移行ターゲット（Aurora / RDS）を推奨
• データベースサイズに基づいた RDS インスタンスタイプ推定

6. Performance Metrics（パフォーマンスメトリクス）

収集項目（Agentless & Agent 共通）：

発見方法の詳細

Agentless Collector（VMware vCenter デプロイ）

# 1. vCenter に OVA をデプロイ
# AWS コンソール → Application Discovery Service → Agentless Collector
# → Download Connector → vCenter にインポート

# 2. Collector の設定（vCenter IP・認証情報）
#    ↓
# 3. スキャン開始（自動）
#    Collector が vCenter を照会 → VM・ホスト一覧取得
#    ↓
# 4. パフォーマンスデータ収集（60分間隔で継続）
#    ↓
# 5. AWS Migration Hub へのデータ送信（自動）

# 7～10 日後：依存関係マップ・統計データ完成

対応バージョン：vCenter 5.5 以降

Discovery Agent（Linux / Windows インストール）

# 1. Agent ダウンロード
curl -O https://s3.us-west-2.amazonaws.com/aws-discovery-agent.us-west-2/linux/latest/aws-discovery-agent.tar.gz

# 2. 解凍・インストール
tar -xzf aws-discovery-agent.tar.gz
cd aws-discovery-agent-installer/
sudo ./install -r ap-northeast-1 -k <ACCESS_KEY> -s <SECRET_KEY>

# 3. インストール確認
sudo systemctl status aws-discovery-daemon

# 4. 収集開始
aws discovery start-data-collection-by-agent-ids \
  --agent-ids agent-abc123 agent-def456 \
  --region ap-northeast-1

# 5. 1～2 週間データ収集で依存関係完成

ハイブリッド（Agentless + Agent 併用）

• VMware VM 1 ← Agentless Collector（vCenter 経由）
• • Discovery Agent（詳細分析用）
• Physical Server 1 ← Discovery Agent（必須・Agent のみ対応）
• Database Server 1 ← Agentless Collector（DB 発見モジュール）

主要ユースケース

1. データセンター全閉鎖プロジェクト（500 台サーバー移行）

シナリオ：レガシーオンプレミスデータセンター 3 施設（日本・米国・欧州）を AWS へ統合移行

Application Discovery Service の活用：

# フェーズ 1: 全体インベントリ自動化（Week 1-2）
→ Agentless Collector を 3 つの vCenter にデプロイ
→ 同時に Discovery Agent を 50 台の物理サーバーにインストール
→ 1 週間で 500 台全体のインベントリ・依存関係を自動検出

# フェーズ 2: ウェーブ計画自動生成（Week 3）
→ Discovery データから依存関係を分析
→ 「非本番環境」「ステージング」「本番」に自動分類
→ Wave 1（50 台）→ Wave 2（100 台）→ Wave 3-6（350 台）

# フェーズ 3: コスト見積もり（Week 4）
→ スペック・使用率データ → Migration Evaluator
→ 現在のオンプレコスト（ライセンス・ハード・電力）vs AWS 3 年コスト
→ ROI 計算：月 ¥500 万オンプレ → 月 ¥300 万 AWS（33% 削減）

# フェーズ 4: Migration Hub へのデータフィード（Week 5）
→ Application Discovery データが自動的にハブに連携
→ 500 台 × 100 アプリケーション の進捗管理準備完了

2. マルチクラウド統合（Azure VM + オンプレミス混在）

シナリオ：Azure で実行中の 100 台 VM と、オンプレミスで実行中の 200 台サーバーを AWS に統合

Discovery 方法：

# Azure VMs ← Discovery Agent（Azure VM 内にインストール）
# On-Premises VMs ← Agentless Collector（vCenter）
# On-Premises Physical ← Discovery Agent

# すべてのデータが同一の Application Discovery Service に集約
→ Migration Hub で統一管理（リージョン・ツール混在の複雑性を吸収）

3. レガシー ERP システム移行（Oracle ERP 数 TB）

シナリオ：Oracle ERP（Database 2TB、App Servers 20 台、報告ツール複数）を AWS に移行

Database Discovery の活用：

# Agentless Collector の DB モジュール
→ Oracle スキーマ自動分析（Table 数・Index 数・スペース使用率）
→ Dependent App Server の自動検出（JDBC 接続を追跡）
→ RDS Target 推奨：Oracle → Amazon RDS for Oracle / Aurora

# Migration Evaluator 連携
→ 2TB Database → RDS db.r6i.4xlarge 推奨
→ 3 年 AWC コスト：¥5,000 万（オンプレ：¥8,000 万）

4. 本番環境の Right-Sizing（過度にプロビジョニング）

シナリオ：「念のため高スペックを購入」した 50 台サーバーの実際の使用率を調査

パフォーマンスメトリクスの活用：

# Discovery Agent で 2 週間のパフォーマンス収集
→ CPU 平均使用率 5%、ピーク 15%
→ メモリ平均使用率 20%、ピーク 40%
→ 現在：16vCPU / 128GB メモリ → 推奨：4vCPU / 16GB（コスト 80% 削減）

# 複数台サーバーの類似パターン検出
→ 自動的に「軽量アプリ」グループを分類
→ 集約化・マイクロサービス化の検討対象を特定

5. アプリケーション依存関係の可視化（見えない接続を発見）

シナリオ：手作業のドキュメントでは把握不可能な隠れた依存関係を発見

具体例：

ドキュメント記載：
  Web App A → Database B （明示的な JDBC 接続）

Discovery Agent が自動検出：
  Web App A → Database B （JDBC）
  Web App A → Cache Server C （Redis port 6379）
  Web App A → License Server D （port 27005）
  Batch Job E → Database B （夜間 22:00 実行）
  Batch Job E → File Server F （NFS mount）

移行計画への反映：
  Database B の移行 → Cache C・License D に影響確認必須
  Batch Job E は Database B 移行完了後に実行

設定・操作の具体例

CLI ベースの操作

1. Home Region の設定

# Migration Hub ホームリージョン設定（必須・最初の 1 回）
aws migrationhub-config create-home-region-control \
  --home-region ap-northeast-1 \
  --target Type=ACCOUNT,Id=123456789012 \
  --region us-east-1

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

2. Data Collection 開始

# Agent ベースのデータ収集開始
aws discovery start-data-collection-by-agent-ids \
  --agent-ids agent-abc123 agent-def456 agent-ghi789 \
  --region ap-northeast-1

# Agent 一覧確認
aws discovery list-agents \
  --region ap-northeast-1 \
  --query 'agentsSummary[*].[agentId, agentStatus, version]'

# 出力例：
# [
#   ["agent-abc123", "RUNNING", "2.0.5"],
#   ["agent-def456", "RUNNING", "2.0.5"]
# ]

3. Server Configuration データ取得

# 発見されたサーバー一覧
aws discovery describe-configurations \
  --configuration-type SERVER \
  --query 'configurations[*].{
    ServerID: configurations[0].server.serverId,
    HostName: configurations[0].server.hostName,
    OS: configurations[0].server.osName,
    CPUs: configurations[0].server.cpuCount,
    Memory: configurations[0].server.ramInMbytes
  }' \
  --region ap-northeast-1 \
  > server-inventory.json

4. Network Connection 取得（依存関係マッピング）

# サーバー間の TCP 接続一覧をエクスポート
aws discovery start-export-task \
  --export-data-format CSV \
  --filters '[{"name":"ConfigurationType","values":["CONNECTION"]}]' \
  --region ap-northeast-1

# エクスポート進捗確認
aws discovery describe-export-tasks \
  --region ap-northeast-1 \
  --query 'exportsInfo[*].[exportId, exportStatus, configurationsDownloadUrl]'

# CSV ダウンロード（configurationsDownloadUrl から）
curl <URL> > network-connections.csv

5. Application Group 作成（Discovery API 経由）

# Application Group 作成
aws discovery create-application \
  --name "E-commerce Platform" \
  --description "Web + API + Database application" \
  --region ap-northeast-1

# 出力：applicationId

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

SDK ベースの操作（Python）

import boto3
import json

discovery_client = boto3.client('discovery', region_name='ap-northeast-1')

# Step 1: サーバー一覧取得
def get_servers():
    response = discovery_client.describe_configurations(
        configurationType='SERVER'
    )
    return response['configurations']

# Step 2: 依存関係グラフ構築
def get_network_connections():
    export_response = discovery_client.start_export_task(
        exportDataFormat='CSV',
        filters=[{'name': 'ConfigurationType', 'values': ['CONNECTION']}]
    )
    return export_response['exportId']

# Step 3: Application Group 作成
def create_app_group(app_name, server_ids):
    app_response = discovery_client.create_application(
        name=app_name
    )
    app_id = app_response['applicationId']
    
    discovery_client.associate_configuration_items_to_application(
        applicationConfigurationId=app_id,
        configurationIds=server_ids
    )
    return app_id

# 実行例
if __name__ == "__main__":
    servers = get_servers()
    print(f"Found {len(servers)} servers")
    
    export_id = get_network_connections()
    print(f"Export job started: {export_id}")
    
    # Web層サーバー抽出
    web_servers = [s['configurations'][0]['server']['serverId'] 
                   for s in servers 
                   if 'web' in s['configurations'][0]['server']['hostName'].lower()]
    
    app_id = create_app_group("E-commerce Web Tier", web_servers)
    print(f"Created application: {app_id}")

IaC ベースの操作（CloudFormation）

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Application Discovery Service Export & Processing Infrastructure'

Resources:
  # S3 bucket for export data
  DiscoveryDataBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub 'app-discovery-exports-${AWS::AccountId}'
      VersioningConfiguration:
        Status: Enabled
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true

  # IAM Role for Discovery data processing
  DiscoveryProcessingRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: ApplicationDiscoveryProcessingRole
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service:
                - discovery.amazonaws.com
                - athena.amazonaws.com
            Action: sts:AssumeRole
      Policies:
        - PolicyName: DiscoveryAccess
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  - discovery:*
                  - s3:GetObject
                  - s3:PutObject
                  - s3:ListBucket
                  - athena:StartQueryExecution
                  - glue:CreateTable
                  - glue:UpdateTable
                Resource: '*'

  # Athena Table for dependency analysis
  DiscoveryDependencyTable:
    Type: AWS::Glue::Table
    Properties:
      CatalogId: !Ref 'AWS::AccountId'
      DatabaseName: default
      TableInput:
        Name: discovery_dependencies
        TableType: EXTERNAL_TABLE
        Parameters:
          EXTERNAL: 'TRUE'
          format: 'csv'
        StorageDescriptor:
          Columns:
            - Name: source_server_id
              Type: string
            - Name: target_server_id
              Type: string
            - Name: port
              Type: int
            - Name: protocol
              Type: string
            - Name: data_transfer_mbps
              Type: double
          Location: !Sub 's3://${DiscoveryDataBucket}/dependencies/'
          InputFormat: org.apache.hadoop.mapred.TextInputFormat
          OutputFormat: org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat
          SerdeInfo:
            SerializationLibrary: org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe
            Parameters:
              field.delim: ','

Outputs:
  ExportBucketName:
    Value: !Ref DiscoveryDataBucket
  ProcessingRoleArn:
    Value: !GetAtt DiscoveryProcessingRole.Arn

類似サービス比較表

ベストプラクティス

1. 発見方法の選定

✅ 推奨：

• VMware 環境：Agentless Collector を vCenter にデプロイ（100+ VM なら必須）
• Physical サーバー：Discovery Agent（必須・Agentless は非対応）
• 混在環境：Agentless + Agent 併用（VM スキャン + Physical 詳細分析）
• Database：Agentless Collector の DB モジュール（別途スキャン不要）

❌ アンチパターン：

• 数千台の VM を個別に Discovery Agent インストール（管理負荷＝無駄）
• Application Discovery Service なし、スプレッドシート手作業（漏落・不正確）

2. データ収集期間

✅ 推奨：

• 最小 1 週間：平均パフォーマンスメトリクス取得
• 理想 2～4 週間：月次変動・バッチ処理ピークを捉える
• 例：月初の請求バッチ、月末のレポート生成時のリソース変動を観測

❌ アンチパターン：

• 数日だけスキャン → 使用率データが不正確 → Right-Sizing 失敗

3. Application Group 設計

✅ 推奨：

• ビジネスアプリケーション単位：「顧客管理システム」「決済システム」
• 各グループ 5～50 サーバー：粒度が適切でダッシュボード見やすい
• 依存関係を明確に：Discovery データから自動抽出

❌ アンチパターン：

• 技術スタック単位（「Web Servers」「DB Servers」）→ ビジネス価値が不透明
• 1 グループ 500+ サーバー → ダッシュボード冗長・管理困難

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

✅ 推奨：

• Discovery データを CSV・Excel でエクスポート → PMO・CFO に定期配信
• 具体的な数値：「全 500 台中 470 台発見・依存関係 2,300 接続点」
• Application 単位の進捗：「顧客管理システム 10 台、決済システム 8 台」

❌ アンチパターン：

• 「インベントリ集約中」と抽象的な報告
• Discovery コンソールの URL だけ共有（詳細不理解）

5. セキュリティ・権限管理

✅ 推奨：

• IAM で Discovery API アクセスを最小権限制御
• エクスポートデータ（CSV）は S3 プライベートバケット保管
• 機密情報（パスワード等）は Discovery エージェントで収集しない設定

❌ アンチパターン：

• 誰でも Discovery コンソールにアクセス可能
• エクスポートデータをメール・共有フォルダで配布

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

2025-2026 最新動向

1. AWS Transform への統合検討

詳細：

• Application Discovery Service は新規顧客受け入れ終了に近づいている
• Migration Hub と共に AWS Transform（統合移行・モダナイゼーションプラットフォーム）への段階的移行を検討
• 既存顧客は継続利用可能（EOL は未定）

代替戦略：

• 新規発見プロジェクト → AWS Transform の Discovery & Assessment 機能推奨
• 既存 Discovery データ → Migration Hub での管理は継続可能

2. AI による依存関係推定の強化

2026 年予定：

• 機械学習モデルによる「隠れた依存関係」の自動検出
• ネットワークフロー + アプリケーション動作ログから、予測的に未検出の接続点を特定
• 誤検知削減のための異常検知アルゴリズム

3. マルチクラウド発見の拡大

2026 年計画：

• Azure VM・GCP Compute Engine の直接スキャン機能
• AWS・Azure・GCP 混在環境でのハイブリッド発見・統合ダッシュボード
• Discovery Agent の cross-cloud サポート強化

4. Database Migration Service Fleet Advisor との統合強化

最新動向：

• DMS Fleet Advisor が Application Discovery の Database スキーマデータを自動取得
• スキーマ複雑度・オブジェクト数から最適な移行パターンを自動推奨
• 変換ルール（Oracle → PostgreSQL 等）の自動生成

学習リソース・参考文献

公式ドキュメント

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

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

実装例・チェックリスト

実装例：500 台サーバー発見プロジェクトの完全セットアップ

#!/bin/bash
# Application Discovery Service 初期セットアップスクリプト

set -e

ACCOUNT_ID="123456789012"
HOME_REGION="ap-northeast-1"
AGENTLESS_VCENTER="vcenter.example.com"

echo "=== Application Discovery Service セットアップ ==="

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

# Step 2: IAM ロール作成
echo "[2/6] IAM ロール作成..."
aws iam create-role \
  --role-name ApplicationDiscoveryRole \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"Service": ["discovery.amazonaws.com"]},
      "Action": "sts:AssumeRole"
    }]
  }' || echo "Role already exists"

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

# Step 3: S3 バケット作成（エクスポートデータ保管）
echo "[3/6] S3 バケット作成..."
BUCKET="app-discovery-exports-${ACCOUNT_ID}"
aws s3 mb s3://$BUCKET --region $HOME_REGION || echo "Bucket already exists"

aws s3api put-bucket-encryption \
  --bucket $BUCKET \
  --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "AES256"}
    }]
  }'

# Step 4: CloudWatch Log Group 作成
echo "[4/6] CloudWatch ログ設定..."
aws logs create-log-group \
  --log-group-name /aws/discovery/agent-logs \
  --region $HOME_REGION || echo "Log group already exists"

aws logs put-retention-policy \
  --log-group-name /aws/discovery/agent-logs \
  --retention-in-days 30 \
  --region $HOME_REGION

# Step 5: Agentless Collector OVA ダウンロード指示
echo "[5/6] Agentless Collector デプロイ手順..."
echo "以下の URL から OVA ファイルをダウンロード："
echo "https://console.aws.amazon.com/discovery/home?region=${HOME_REGION}#/"
echo ""
echo "vCenter にインポート手順："
echo "1. vCenter Web Client → Datacenters → Deploy OVA Template"
echo "2. OVA ファイルを選択 → Deploy"
echo "3. Collector 設定：vCenter IP・User・Password 入力"
echo "4. スキャン自動開始"

# Step 6: Agent ダウンロード準備
echo "[6/6] Discovery Agent ダウンロード準備..."
echo "Linux Agent:"
echo "curl -O https://s3.us-west-2.amazonaws.com/aws-discovery-agent.us-west-2/linux/latest/aws-discovery-agent.tar.gz"
echo ""
echo "Windows Agent:"
echo "Powershell: (New-Object System.Net.WebClient).DownloadFile('https://s3.us-west-2.amazonaws.com/aws-discovery-agent.us-west-2/windows/latest/AwsDiscoveryAgent.exe', 'AwsDiscoveryAgent.exe')"

echo ""
echo "=== セットアップ完了 ==="
echo "S3 Export Bucket: s3://$BUCKET"
echo "CloudWatch Logs: /aws/discovery/agent-logs"
echo "Home Region: $HOME_REGION"

発見プロジェクトチェックリスト

事前準備フェーズ

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

  • [ ] Project Sponsor から移行スコープ・予算承認取得
  • [ ] IT 運用チーム・セキュリティチームの同意
  • [ ] データセンター・VMware 管理者との協力体制

• [ ] インベントリ計画

  • [ ] 対象サーバー一覧の粗集計（VM 数・物理サーバー数・DB 数）
  • [ ] VMware vCenter のバージョン確認（5.5+対応確認）
  • [ ] Network 疎通確認（Discovery Collector → Migration Hub）

• [ ] ツール・アカウント準備

  • [ ] AWS Account・IAM ユーザー作成
  • [ ] 適切な IAM 権限確認（discovery:*）
  • [ ] S3 バケット・CloudWatch Log Group 作成

スキャン実施フェーズ

• [ ] Agentless Collector セットアップ

  • [ ] OVA ダウンロード・vCenter へのデプロイ
  • [ ] Collector の起動確認（AWS コンソール）
  • [ ] vCenter 認証情報の入力・スキャン開始

• [ ] Discovery Agent セットアップ

  • [ ] Agent ダウンロード・解凍
  • [ ] 各物理サーバー・VM への インストール（bash / Powershell）
  • [ ] Agent ステータス確認（systemctl / Windows Services）
  • [ ] データ収集開始（start-data-collection-by-agent-ids）

• [ ] スキャン期間の管理

  • [ ] 最小 1 週間はスキャン継続（パフォーマンスメトリクス蓄積）
  • [ ] 月次バッチ・ピーク時間帯を含めて 2～4 週間推奨
  • [ ] スキャン状況の定期確認（describe-agents）

分析・見積もりフェーズ

• [ ] インベントリデータの検証

  • [ ] describe-configurations で Server / DB データ確認
  • [ ] 期待値（総サーバー数）との一致確認
  • [ ] 発見漏れサーバーの追加スキャン

• [ ] 依存関係マッピング

  • [ ] start-export-task で CONNECTION データをエクスポート
  • [ ] CSV 分析：サーバー間 TCP 接続を可視化
  • [ ] Application Group への関連付け（create-application）

• [ ] パフォーマンス分析

  • [ ] CPU・メモリ・ディスク使用率の統計データ取得
  • [ ] Right-Sizing 候補検討（小さすぎる・大きすぎるサーバー）
  • [ ] スケーリング・集約化の可能性検討

• [ ] コスト見積もり

  • [ ] Migration Evaluator へのデータフィード
  • [ ] 3 年間 TCO 計算
  • [ ] オンプレ（ライセンス・ハード・電力）vs AWS 比較

計画フェーズ

• [ ] Migration Hub への統合

  • [ ] Application Discovery データが Hub に自動反映
  • [ ] Application Group の確認・調整
  • [ ] Wave 計画の自動提案確認

• [ ] ステークホルダー報告

  • [ ] インベントリサマリーレポート作成・配信
  • [ ] 依存関係グラフの共有
  • [ ] 推奨 Application Group の説明
  • [ ] 移行計画・リスク・コスト概算を提示

まとめ

AWS Application Discovery Service は 「エンタープライズ移行プロジェクトのインベントリ・依存関係・パフォーマンスデータを自動収集し、Migration Hub と統合する完全なポートフォリオ発見プラットフォーム」 である。

主な価値

1. 数百～数千台の自動インベントリ化：スプレッドシート手作業の廃止、精度向上
2. TCP 依存関係の自動マッピング：隠れた接続点を発見、ウェーブ計画の精度向上
3. パフォーマンスデータの継続収集：右サイジング・コスト見積もりの根拠
4. Migration Hub との統合：発見 → 計画 → 実行 → 追跡の一貫フロー
5. データベース発見機能：スキーマ・オブジェクト数から RDS ターゲット推奨

注意点

• 新規顧客受け入れ終了予定：AWS Transform への段階的移行を検討
• 最小 1 週間のスキャン期間：数日では不正確
• 全サーバーへの Agent インストール必須（依存関係完全把握のため）

適用判定

✅ 使うべき：

• 数十～数百のアプリケーション・サーバーの移行
• オンプレからクラウドへの包括的な移行計画
• 複数ウェーブ・複雑な依存関係の管理

❌ 不要：

• 小規模移行（< 10 台）
• 既に詳細なインベントリ・依存関係マップを保有
• AWS 以外のクラウド（Azure Migrate・GCP Migrate を推奨）

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