AWS Application Discovery Service Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Migration and transfer

1. Introduction

AWS Application Discovery Service is an AWS Migration and transfer service that helps you discover on-premises (and other) server environments by collecting configuration, system performance, and network dependency information. The goal is to build an accurate inventory and dependency map so you can plan migrations with fewer surprises.

In simple terms: it tells you what you have, how it behaves, and what it talks to—before you migrate.

Technically, AWS Application Discovery Service uses agent-based discovery (AWS Discovery Agent installed on servers) and agentless discovery (AWS Discovery Connector for VMware environments) to gather metadata such as CPU/memory utilization, processes, and inbound/outbound network connections. The collected data can be viewed in the discovery console and is commonly used with AWS Migration Hub to group servers into applications and plan migration waves.

The core problem it solves is migration uncertainty: incomplete inventories, unknown application dependencies, and inaccurate sizing assumptions. These issues are among the most common reasons migrations slip, fail, or become more expensive than planned.

2. What is AWS Application Discovery Service?

Official purpose: AWS Application Discovery Service helps you plan migrations to AWS by collecting usage and configuration data about your on-premises servers and data centers. It supports identifying system configurations, performance characteristics, and network dependencies so you can better understand applications and server relationships before migrating.

Core capabilities – Discover servers and gather system information (CPU, memory, disk, OS details, running processes). – Capture network connection/dependency data to understand which servers communicate and on what ports. – Support discovery via: – AWS Discovery Agent (installed on servers; works across many environments). – AWS Discovery Connector (agentless discovery for VMware vCenter-managed VMs). – Export discovery data (for analysis, CMDB enrichment, migration wave planning). – Integrate with AWS Migration Hub for application grouping and migration tracking.

Major components – AWS Discovery Agent: Lightweight software installed on Windows/Linux servers to collect configuration, performance, and network connection details. – AWS Discovery Connector: A VMware virtual appliance that connects to vCenter and discovers VM inventory (agentless approach). – Application Discovery Service console / APIs: Where you manage discovery, view discovered servers, and export data. – AWS Migration Hub integration: A common destination for grouping discovered servers into “applications” and coordinating migration tooling.

Service type – Managed AWS discovery/inventory service (SaaS-style control plane) used for migration planning. – Not a migration engine. It does not replicate data or move applications.

Scope: regional vs global – AWS Application Discovery Service is regional in terms of where you configure and store discovery data (you choose an AWS Region for discovery).
– It can collect data from servers located anywhere (on-premises, other clouds) as long as they can reach the AWS endpoints over the network. – Account-scoped: discovery data is associated with your AWS account in the selected Region.

How it fits into the AWS ecosystem – Commonly paired with: – AWS Migration Hub (application grouping and migration tracking). – Migration execution tools such as AWS Application Migration Service (MGN), AWS Database Migration Service (DMS), and partner tools. – Inventory governance and reporting systems (CMDBs, spreadsheets, BI tools), using exported data and APIs.

3. Why use AWS Application Discovery Service?

Business reasons

Reduce migration risk by discovering hidden dependencies (e.g., an app server talking to a legacy license server).
Improve migration estimates (timeline, staffing, and cost) using real utilization data instead of guesswork.
Prioritize: identify low-risk candidates for early waves and isolate complex workloads for later.

Technical reasons

Builds a server inventory: OS, CPU, RAM, installed software/processes (depth varies by method).
Collects utilization metrics to help right-size EC2 or choose managed services.
Collects network dependency data to inform security group rules, firewall changes, and cutover planning.

Operational reasons

Provides a repeatable workflow for discovery across estates.
Supports exporting data to standard formats for operational planning.
Helps teams avoid “tribal knowledge” dependencies on a few SMEs.

Security/compliance reasons

Helps identify where sensitive services live and what they connect to.
Provides discovery data that can support audit and segmentation planning (for example, identifying unexpected inbound connections).
Integrates with AWS IAM and AWS CloudTrail for administrative auditing of API actions.

Scalability/performance reasons

Designed to scale to large numbers of servers (subject to service quotas and best practices).
Agent-based collection is distributed: each server contributes its own data rather than relying on a single scanner.

When teams should choose it

Choose AWS Application Discovery Service when you need: – A reliable inventory of servers and basic application dependencies. – Pre-migration planning inputs for AWS Migration Hub and migration factories. – A managed AWS-native option instead of building discovery from scratch.

When teams should not choose it

It may not be the best fit if: – You need deep application performance monitoring (use APM tools). – You need packet-level network analysis or full traffic capture (use network monitoring tools). – You want a single tool that also executes migrations end-to-end (use migration tools like MGN, DMS, or third-party platforms; discovery remains a separate phase). – Your environment cannot allow outbound connectivity to AWS discovery endpoints (unless you have a compliant network path/proxy—verify with official docs).

4. Where is AWS Application Discovery Service used?

Industries

Financial services (regulated migrations, dependency mapping for segmentation).
Healthcare (inventory + change control before moving clinical systems).
Retail and e-commerce (seasonality sizing, phased modernization).
Manufacturing (legacy systems, plant connectivity, complex dependencies).
SaaS and tech companies (standardization and platform consolidation).

Team types

Cloud Center of Excellence (CCoE) and platform teams.
Migration factory teams.
Infrastructure and operations teams.
Security engineering teams validating network paths and segmentation.
Application owners and SREs supporting cutovers.

Workloads

Traditional 3-tier applications (web/app/db).
Windows-based line-of-business apps.
Linux-based services and middleware.
VMware estates (especially with the Discovery Connector).
Mixed environments spanning multiple data centers.

Architectures

Monoliths with shared database backends.
Distributed systems with multiple internal dependencies.
Legacy systems with hard-coded integrations.
Environments where CMDB data is incomplete or outdated.

Real-world deployment contexts

Pre-migration discovery in on-prem data centers.
Discovery in hosting providers/colocation environments.
Discovery of workloads running in other clouds (network permitting).
Continuous discovery for a period (weeks) to capture realistic patterns.

Production vs dev/test usage

Production: common, because you want real dependencies and real performance patterns.
Dev/test: helpful for rehearsal, but it may not reveal the true runtime dependencies and load characteristics you need for migration planning.

5. Top Use Cases and Scenarios

Below are realistic scenarios where AWS Application Discovery Service is commonly used.

1) Build an authoritative server inventory before migration

Problem: CMDB/spreadsheets are outdated; teams don’t know what servers exist.
Why this service fits: Discovers server metadata and usage characteristics from the environment itself.
Example: A company finds 300 “unknown” VMs that were never recorded in the CMDB, preventing missed workloads during migration.

2) Map application dependencies to prevent broken cutovers

Problem: Cutover fails because an application depends on an overlooked internal service.
Why this service fits: Agent-based discovery captures network connections, helping reveal dependencies.
Example: A web tier depends on a licensing server over a non-standard port; discovery identifies it early.

3) Right-size EC2 target instances using real utilization

Problem: Overprovisioning increases cost; underprovisioning causes performance incidents.
Why this service fits: Collects CPU/memory utilization metrics over time.
Example: The team migrates 8 vCPU servers to 4 vCPU equivalents after reviewing utilization trends.

4) Prepare security group/firewall rules based on observed traffic

Problem: Security rules are too permissive or block critical traffic during migration.
Why this service fits: Dependency data indicates which ports and peers are used.
Example: Security teams build least-privilege security group baselines per application group.

5) Plan migration waves and sequencing

Problem: Migration waves are chosen by intuition; dependent systems migrate out of order.
Why this service fits: Dependency mapping supports wave design (move tightly-coupled systems together).
Example: ERP app servers and middleware must move in the same wave due to tight internal calls.

6) Identify end-of-life OS and unsupported software

Problem: Legacy OS/software blocks migration or violates security policy.
Why this service fits: Discovery highlights OS versions and running processes (depth varies).
Example: Discovery finds Windows Server versions approaching end-of-support; the plan includes upgrades.

7) Validate which servers are actually used

Problem: “Zombie” servers exist but no one knows if they’re safe to retire.
Why this service fits: Utilization and network activity help confirm if a server is idle.
Example: A set of servers shows near-zero activity for 30 days; they are candidates for retirement.

8) Provide migration inputs to AWS Migration Hub applications

Problem: Teams need to group servers into logical “applications” for tracking.
Why this service fits: Discovery data flows into Migration Hub for application grouping and tracking.
Example: A migration factory uses Migration Hub applications to coordinate owners and cutover dates.

9) Support due diligence for data center exit planning

Problem: Leadership needs a defensible plan for exiting a data center contract.
Why this service fits: Produces measurable inventory and dependency data to support timelines and risks.
Example: The plan identifies high-dependency clusters that require early network design work.

10) Improve DR and resilience planning during modernization

Problem: DR design is unclear because dependencies and data flows aren’t documented.
Why this service fits: Dependency mapping informs where redundancy and failover routes are needed.
Example: Teams identify single points of failure (one shared file server) and modernize it first.

6. Core Features

Note: Exact fields collected can differ between agent-based and connector-based discovery and by OS. Always verify details in the official documentation.

1) Agent-based discovery (AWS Discovery Agent)

What it does: Installs on servers to collect system configuration, performance, and network connection data.
Why it matters: Provides richer, host-level discovery than purely inventory-based approaches.
Practical benefit: Better dependency mapping and sizing inputs.
Limitations/caveats: Requires installation, change management, and outbound connectivity to AWS endpoints.

2) Agentless discovery for VMware (AWS Discovery Connector)

What it does: Connects to VMware vCenter to collect VM inventory and configuration details without installing agents in each VM.
Why it matters: Faster initial inventory in VMware-heavy environments.
Practical benefit: Reduces per-VM operational overhead for inventory collection.
Limitations/caveats: Typically focused on VMware inventory; may not provide the same depth of process/network details as agents. Requires vCenter access and connector deployment.

3) Network dependency collection (agent-based)

What it does: Records observed network connections (who talks to whom, on what port/protocol).
Why it matters: Dependencies are a top cause of failed migrations and outages.
Practical benefit: Enables wave planning and firewall/security group design.
Limitations/caveats: Captures observed connections during the collection window; rare/seasonal dependencies may require longer collection.

4) System performance and utilization metrics

What it does: Collects metrics such as CPU and memory utilization over time (exact metrics vary).
Why it matters: Supports right-sizing and capacity planning.
Practical benefit: Prevents systematic overprovisioning in AWS.
Limitations/caveats: Metrics reflect the observation period; choose a window that reflects typical and peak usage.

5) Central console + API access

What it does: View discovered servers, agents/connectors, and export data through UI and APIs.
Why it matters: Supports automation and integration with migration tooling.
Practical benefit: Repeatable reporting and pipelines into analysis tools.
Limitations/caveats: Some teams still export and analyze externally; treat exports as sensitive.

6) Data export for analysis

What it does: Exports discovery results for offline analysis and stakeholder reporting.
Why it matters: Migration planning often happens in spreadsheets, BI tools, or CMDBs.
Practical benefit: Enables wave plans, risk scoring, and sizing analysis.
Limitations/caveats: Export formats and fields may differ; verify export capabilities in your Region and console.

7) Integration with AWS Migration Hub

What it does: Feeds discovery data into Migration Hub, where you can group servers into applications and track migrations.
Why it matters: Migration Hub acts as a central place to manage migration tracking.
Practical benefit: Application-centric tracking instead of server-by-server spreadsheets.
Limitations/caveats: Migration Hub is a coordination layer; it doesn’t replace execution tools.

8) IAM-based access control + CloudTrail auditing (management plane)

What it does: Uses IAM policies to control who can configure discovery and access data; CloudTrail logs supported API actions.
Why it matters: Discovery data can reveal sensitive architecture details.
Practical benefit: Least privilege and auditability for migration programs.
Limitations/caveats: CloudTrail logs management events; it’s not a substitute for OS-level auditing.

7. Architecture and How It Works

High-level architecture

AWS Application Discovery Service works by deploying collection components (agents or connector) in your environment. These components gather metadata and send it securely to AWS in the Region you select. You then use the console or APIs to view, group, and export discovered data—often using AWS Migration Hub for application grouping.

Control flow vs data flow

Control/administration flow
Admin authenticates via IAM to the AWS console/API.
Admin generates activation keys / registers agents (exact workflow depends on method).
Admin monitors agent status, exports data, and manages application grouping in Migration Hub.
Data flow
Agent/connector collects system and/or inventory data locally.
Sends discovery data to AWS Application Discovery Service endpoints over TLS (typically HTTPS/TCP 443).
Data becomes available for viewing and export; can populate Migration Hub views.

Integrations with related AWS services

AWS Migration Hub: Common consumption layer for discovery data and application grouping.
AWS Identity and Access Management (IAM): Controls administrative access to discovery setup, data viewing, and exports.
AWS CloudTrail: Audits API calls for governance and forensics.
AWS Organizations (indirect): Large programs may use multi-account strategies; discovery is still configured per account/Region (design accordingly).
AWS migration execution tools (adjacent): MGN, DMS, and partner tools are typically used after discovery/planning.

Dependency services

Reliable outbound network access (direct internet, NAT, or proxy as supported).
DNS resolution for AWS endpoints.
Time synchronization on servers (important for TLS and telemetry).

Security/authentication model

Administrators authenticate to AWS Application Discovery Service with IAM.
Agents/connectors authenticate using the service’s enrollment/activation mechanism (activation keys and registration are common patterns—verify exact workflow for your OS/collector type in official docs).
Data in transit uses TLS.

Networking model

Collectors require outbound connectivity to AWS endpoints in the chosen Region.
In locked-down environments, you may need to allowlist domains/IPs or use proxy configurations (verify official guidance; AWS endpoints and requirements can change).

Monitoring/logging/governance considerations

Use CloudTrail to record configuration and data access events in the AWS account.
Establish governance for:
Who can export discovery data.
Where exports are stored and how long they are retained.
Change control for agent installation and removal.
On the server side, maintain operational visibility (service status, local logs). Exact log locations vary by OS/agent version—verify in official docs.

Simple architecture diagram (Mermaid)

flowchart LR
  A[On-prem / VM / Server] -->|Discovery Agent collects\nmetrics + connections| B[AWS Application Discovery Service\n(Regional Endpoint)]
  C[VMware vCenter] -->|Discovery Connector collects\nVM inventory| B
  D[Admin: IAM user/role] -->|Console / API| B
  B --> E[AWS Migration Hub\n(Application grouping)]
  B --> F[Exported reports\n(CSV/API -> your tools)]

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph DC[Data Center / Hybrid Environment]
    subgraph NET[Restricted Network]
      S1[Linux/Windows Servers\n(Discovery Agent)]
      S2[VMware Cluster]
      VC[vCenter]
      CONN[Discovery Connector\n(OVA Appliance)]
      PROXY[HTTP/HTTPS Proxy\n(optional)]
    end
  end

  subgraph AWS[AWS Account (Chosen Region)]
    ADS[AWS Application Discovery Service]
    MH[AWS Migration Hub]
    CT[CloudTrail]
  end

  Admin[Platform/Migration Team\n(IAM + MFA)] --> ADS
  Admin --> MH

  S1 -->|TLS 443\nvia direct/NAT/proxy| ADS
  CONN -->|vCenter API| VC
  CONN -->|TLS 443\nvia direct/NAT/proxy| ADS

  ADS --> MH
  ADS -->|API events| CT
  MH -->|API events| CT

8. Prerequisites

AWS account and billing

An AWS account with billing enabled.
AWS Application Discovery Service itself is commonly listed as no additional charge (see pricing section), but you may incur costs for:
The compute you use for lab servers (e.g., EC2 if you simulate on-prem in AWS),
Network egress from on-prem to AWS (depending on your ISP/carrier),
Storage/analysis tooling where you store exported data.

Permissions / IAM roles

At minimum, you need IAM permissions to: – Access AWS Application Discovery Service console and APIs. – Manage discovery resources (agents/connectors registration, configuration). – Access AWS Migration Hub (if you will group discovered servers into applications). – Export discovery data.

AWS provides managed policies and/or documented permission sets for these services. Use least privilege and verify the exact required actions in the official docs: – https://docs.aws.amazon.com/application-discovery/latest/userguide/security_iam_id-based-policy-examples.html (verify current URL/structure in official docs)

Tools needed

AWS Management Console access (recommended for beginners).
Optionally, AWS CLI for related administration (not strictly required for a basic lab).
Server access for installing the AWS Discovery Agent:
SSH for Linux
RDP/WinRM for Windows
Ability to download the agent installer from AWS and install packages.

Region availability

AWS Application Discovery Service is available in many AWS Regions, but not necessarily all.
Verify Region support in official documentation and choose the Region where you want discovery data stored.

Quotas/limits

There are service quotas (for example, numbers of discovered servers, agents/connectors, API rates). Quotas can change.
Check Service Quotas and the AWS Application Discovery Service documentation for current limits. If the service does not appear in Service Quotas in your Region, rely on official docs and support channels.

Prerequisite services

AWS Migration Hub (optional but commonly used).
AWS CloudTrail (recommended for audit logging of discovery configuration and data access).

9. Pricing / Cost

Current pricing model (high confidence summary)

AWS Application Discovery Service is generally positioned as no additional charge for using the service itself. However, you still pay for the resources and infrastructure involved around it.

Always confirm on the official pricing page because pricing and included features can change: – Official pricing: https://aws.amazon.com/application-discovery/pricing/ – AWS Pricing Calculator: https://calculator.aws/

Pricing dimensions (what you may pay for)

Even if the service itself is free, costs can come from:

1) Compute where you run agents/connectors – On-prem: you pay your own hardware/VMware costs (already sunk/operational). – If you run discovery agents on EC2 for a lab, you pay standard EC2 charges.

2) Network data transfer – From your environment to AWS: typically internet egress from your network provider; AWS inbound transfer is often not charged, but verify current AWS data transfer rules. – If you route through VPN/Direct Connect, those services have their own costs.

3) Data storage and analytics – If you export discovery data and store it in Amazon S3, a data warehouse, or a CMDB, those services cost money. – Any BI tooling (QuickSight, third-party) can add costs.

4) Operations overhead – Time spent installing/maintaining agents, proxy configuration, change requests.

Free tier

AWS Application Discovery Service is not typically discussed as a “Free Tier” service; rather it’s commonly “no additional charge.” Confirm the exact wording and any exceptions on the pricing page.

Cost drivers

Number of servers/VMs discovered.
Duration of discovery (how many weeks/months you keep agents running).
Network path complexity (proxy/VPN/DX).
Data governance requirements (storage, retention, access controls).

Hidden or indirect costs

Security review and change management (agent installs in production).
Longer discovery windows to catch infrequent dependencies.
Stakeholder time to validate application groupings and ownership.

How to optimize cost

Start with agentless VMware discovery if you mainly need inventory and want speed (where applicable).
Use agent-based discovery selectively for the workloads where dependency mapping and performance history matter.
Run discovery long enough to capture real patterns, but not indefinitely without reason.
Export only what you need; treat exports as sensitive and minimize duplication.

Example low-cost starter estimate (no fabricated numbers)

A minimal lab can be close to zero service cost for AWS Application Discovery Service itself, but you may pay for: – 1 small EC2 instance for a few hours/days (if you simulate a server), – Minimal outbound network traffic (usually small telemetry), – Any optional storage for exported data.

Use the AWS Pricing Calculator for your Region and instance choice: – https://calculator.aws/

Example production cost considerations

In production, the main budget items are usually: – Staff time and change windows for deploying agents at scale, – Network considerations (proxy/VPN/DX), – Downstream data storage and reporting, – Program management overhead.

10. Step-by-Step Hands-On Tutorial

Objective

Discover a single server using AWS Application Discovery Service (agent-based), verify that discovery data appears in AWS, optionally view it in AWS Migration Hub, and then clean up by removing the agent and deleting the lab compute.

Lab Overview

You will: 1. Choose an AWS Region and open AWS Application Discovery Service. 2. Generate/obtain the AWS Discovery Agent installer and activation/registration information from the console. 3. Install the agent on a small Linux server (recommended: an EC2 instance used only for this lab). 4. Verify the agent is reporting and a server appears in the discovery console. 5. (Optional) Use AWS Migration Hub to group the server into an application. 6. Clean up by terminating the instance and uninstalling/stopping the agent.

Why use EC2 for the lab?
It’s a safe way to practice the workflow even if you don’t currently have on-prem servers. The same discovery pattern applies on-prem as long as network access to AWS endpoints is allowed.

Step 1: Choose a Region and open AWS Application Discovery Service

Sign in to the AWS Management Console.
Select an AWS Region you will use for discovery (for example, us-east-1).
Navigate to AWS Application Discovery Service: – Product page: https://aws.amazon.com/application-discovery/ – Documentation landing: https://docs.aws.amazon.com/application-discovery/latest/userguide/what-is-appdiscovery.html

Expected outcome: You can access the AWS Application Discovery Service console in your chosen Region.

Verification: – You can see sections for discovery collectors (agents/connectors) and discovered servers (wording may differ slightly as AWS updates the console UI).

Step 2: Confirm IAM permissions for discovery and Migration Hub

For this lab user/role, ensure you can: – Manage AWS Application Discovery Service resources. – View discovered servers and export data. – (Optional) Use AWS Migration Hub.

If you are using an admin role for a lab, that’s acceptable for learning. For real environments, create a least-privilege role.

Expected outcome: No “Access denied” errors in the discovery console.

Verification: – You can access pages for agents and discovered servers. – (Optional) You can open AWS Migration Hub: https://console.aws.amazon.com/migrationhub/

Step 3: Create a small Linux server for the agent (EC2 lab option)

If you already have a Linux server you can use (on-prem or VM), you can skip EC2 creation. Otherwise:

Go to Amazon EC2 console.
Launch an instance: – OS: Ubuntu LTS or Amazon Linux (choose what you’re comfortable with). – Size: a small instance type appropriate for a lab. – Networking: allow outbound internet access (via public IP or NAT).
Security group: – Allow SSH (22) inbound only from your IP. – Outbound: allow HTTPS (443) to the internet (or to your proxy).

Expected outcome: You can SSH into the instance.

Verification (from your terminal):

ssh -i /path/to/key.pem ubuntu@<EC2_PUBLIC_IP>

Step 4: In AWS Application Discovery Service, obtain the Discovery Agent installer and activation/registration info

The AWS console provides OS-specific instructions and downloads for the AWS Discovery Agent. Because AWS may update package names, paths, and installation commands, follow the current console guidance for your OS.

General workflow: 1. In the AWS Application Discovery Service console, locate the agent setup area. 2. Download the agent installer for your OS (Linux .deb/.rpm or Windows installer). 3. Generate or retrieve the activation key / registration step as instructed by the console.

Expected outcome: You have: – An agent installer file or download URL – The correct Region – Any activation key/registration values required

Verification: – You can see the downloaded file on your workstation or you have a download URL accessible from the server.

Step 5: Install the AWS Discovery Agent on the Linux server

SSH to the server and run the installation steps from the console.

Common patterns include: – Downloading the package to the server (for example, using curl or wget) – Installing via dpkg -i (Debian/Ubuntu) or rpm -i (RHEL/CentOS/Amazon Linux variants) – Running an agent configuration/registration command using the activation key and Region

Because exact commands differ by OS and agent version, use the console-provided commands. The structure often looks like:

# Example structure only — copy the exact commands from the console for your OS/region
curl -O "<AGENT_DOWNLOAD_URL>"

# Debian/Ubuntu example
sudo dpkg -i <agent-package>.deb

# RHEL/CentOS/Amazon Linux example
sudo rpm -ivh <agent-package>.rpm

# Register/configure (example pattern)
sudo <agent-command> --region <REGION> --activation-key <ACTIVATION_KEY>

Expected outcome: The agent service is installed and running.

Verification: – Check service status (exact service name varies; verify in agent docs/console instructions):

sudo systemctl status <discovery-agent-service-name>

If your OS doesn’t use systemd, use the appropriate service manager.

Step 6: Ensure outbound connectivity to AWS discovery endpoints

If the agent doesn’t appear, the most common issue is network egress restrictions.

On the server: – Confirm DNS resolution works. – Confirm HTTPS outbound works.

Basic checks:

# DNS check
nslookup amazonaws.com

# HTTPS check (general)
curl -I https://aws.amazon.com

If your environment requires an HTTP/HTTPS proxy, configure the agent to use it according to the official documentation (proxy configuration is environment-specific—verify in official docs).

Expected outcome: The server can reach AWS over HTTPS.

Verification: curl succeeds and returns HTTP headers.

Step 7: Verify the server appears in AWS Application Discovery Service

Return to the AWS Application Discovery Service console and check: – Agent status (healthy/active) – Discovered servers list

It can take several minutes after installation for data to appear.

Expected outcome: You see at least one discovered server entry corresponding to your lab instance.

Verification tips: – Match by hostname, private IP, or OS details. – Confirm timestamps indicate recent reporting.

Step 8 (Optional): View the discovered server in AWS Migration Hub and create an application group

Open AWS Migration Hub console: https://console.aws.amazon.com/migrationhub/
Find discovery data / servers section (UI can vary).
Create an application (or application group) and add the discovered server.

Expected outcome: Migration Hub shows the server assigned to an application, enabling application-centric planning.

Verification: – The application contains the server. – You can see basic server attributes inside the application.

Validation

You have successfully completed the lab if: – The AWS Discovery Agent is installed and running on your server. – The server shows up in AWS Application Discovery Service as discovered. – (Optional) The server is grouped into an application in AWS Migration Hub.

Checklist: – [ ] Agent installed – [ ] Agent reporting (healthy status) – [ ] Server visible in console – [ ] (Optional) Application created in Migration Hub and server added

Troubleshooting

Common issues and practical fixes:

1) Agent never appears in console – Confirm you selected the correct AWS Region in the console. – Confirm outbound HTTPS (443) is permitted. – Confirm proxy settings if required. – Wait 10–15 minutes after installation; initial reporting may take time.

2) “Access denied” or permission errors in console – Ensure IAM permissions for AWS Application Discovery Service and Migration Hub. – Check for SCPs (AWS Organizations Service Control Policies) that block actions.

3) Agent installed but not running – Check service status via systemctl. – Review agent logs (log locations vary—verify in official docs). – Confirm server time is correct (TLS can fail with bad time skew).

4) Server appears but dependency data looks empty – Dependency data requires observed network connections during the collection window. – Generate test traffic (e.g., connect to another host) or extend the collection period. – Verify that your chosen discovery method supports the depth of dependency data you expect.

5) Duplicate or confusing server entries – Ensure you’re not registering multiple agents to the same host image reused/cloned improperly. – In golden image workflows, install/register the agent post-clone with unique identity (verify best practice in official docs).

Cleanup

To avoid ongoing costs (especially if you used EC2):

1) Terminate the EC2 instance (if you used one) – EC2 Console → Instances → select instance → Terminate

2) Stop/disable/uninstall the agent (if installed on a persistent server) – Use the OS package manager to remove it, and stop the service first:

# Example patterns — exact package/service names vary by OS and agent version
sudo systemctl stop <discovery-agent-service-name>

# Debian/Ubuntu pattern
sudo apt remove <agent-package-name>

# RHEL/Amazon Linux pattern
sudo yum remove <agent-package-name>

3) Remove/retire discovered server records (optional) – If your environment requires it, remove discovered entries from the console or via API.
The exact lifecycle actions in the console can change—verify in official docs.

Expected outcome: No running lab infrastructure; agent no longer reports.

11. Best Practices

Architecture best practices

Run discovery for an observation window that captures:
Business-as-usual traffic
Batch jobs (weekly/monthly)
Peak periods (if feasible)
Use a combination of:
Connector-based inventory (fast breadth)
Agent-based discovery (depth on critical apps)

IAM/security best practices

Apply least privilege: separate roles for:
Discovery setup (agent/connector registration)
Data viewers
Export operators
Require MFA for console access.
Restrict who can export data; exports can reveal sensitive topology.

Cost best practices

Avoid installing agents on everything “forever.”
Focus agent-based discovery on:
High-risk applications
Systems with unclear ownership
Systems with uncertain network dependencies
Use short-lifecycle lab environments and clean up.

Performance best practices

Validate agent overhead in a pilot, especially on heavily utilized servers.
Use change management windows for production deployments.
Extend collection windows instead of increasing collection intensity (where applicable).

Reliability best practices

Ensure stable outbound connectivity (direct/NAT/proxy).
Standardize installation procedures and rollback steps.
Track which servers have agents installed and when they were last seen reporting.

Operations best practices

Treat discovery as a project with runbooks:
Installation steps per OS
Proxy configuration steps (if needed)
Troubleshooting guide
Periodically review discovered inventory and reconcile with CMDB.

Governance/tagging/naming best practices

Maintain a mapping of:
Server → application owner
Application → business criticality
Environment (prod/dev/test)
Use consistent naming in Migration Hub applications (e.g., APP-ERP-PROD, APP-CRM-DEV).
Store exported data in approved locations with defined retention and access controls.

12. Security Considerations

Identity and access model

Use IAM to control who can:
Configure discovery
Access discovered data
Export data
Use IAM roles and short-lived credentials for admins where possible.
In multi-account environments, decide whether discovery is centralized or per account.

Encryption

Data in transit from agents/connectors to AWS uses TLS.
For any exported data you store (S3, file shares), enforce encryption at rest and access logging.

Network exposure

Collectors typically require outbound connectivity to AWS endpoints (HTTPS/443).
In restricted environments:
Use allowlists/proxies per official docs.
Monitor for blocked traffic and TLS inspection issues.

Secrets handling

Avoid embedding sensitive credentials in scripts.
Store any proxy credentials securely (OS key store, secret manager) and follow your organization’s standards.
Activation keys/registration artifacts should be treated as sensitive and time-bound (verify behavior in official docs).

Audit/logging

Enable AWS CloudTrail in the account/Region for governance.
Track access to exported discovery data (for example, S3 server access logs or CloudTrail data events, if applicable).

Compliance considerations

Discovery data may include:
Hostnames, IPs, OS versions
Process/application hints
Connection metadata
Classify it appropriately (often “internal confidential”).
Define retention policies for exported datasets; avoid uncontrolled copies.

Common security mistakes

Over-permissioned IAM users exporting data to unmanaged laptops.
Leaving agents installed long after discovery is complete.
Not restricting outbound egress (agents should only reach required endpoints).
Treating discovery exports as harmless; they can reveal attack paths.

Secure deployment recommendations

Pilot in a non-production segment.
Use dedicated IAM roles and limit export permissions.
Store exports in a controlled repository with encryption and access logging.
Coordinate with security teams on firewall rules and proxy/TLS inspection policies.

13. Limitations and Gotchas

These items can vary by Region, OS, and collector type. Verify current specifics in official docs.

Discovery is observational: it only captures dependencies that occur during the collection window.
Agentless connector scope: VMware connector provides inventory and may provide less granular dependency/process data than agents.
Network restrictions are the #1 blocker: outbound HTTPS/proxy requirements must be satisfied.
Golden image pitfalls: cloning machines with pre-installed agents can cause duplicate/incorrect identity reporting if not handled properly.
Data sensitivity: exports can reveal topology; manage access carefully.
Not a CMDB replacement: it helps build/validate inventory, but lifecycle management and ownership tracking usually live elsewhere.
Not a migration tool: it doesn’t replicate or cut over workloads.
Regional data location: discovery data is tied to the Region you select; choose deliberately for governance and operations.
Quotas and API limits: large estates may need staged rollouts and quota planning.
Console UI changes: AWS updates console flows; use documentation for up-to-date steps.

14. Comparison with Alternatives

AWS Application Discovery Service sits in the “discovery & assessment” phase of Migration and transfer. Here’s how it compares.

Option	Best For	Strengths	Weaknesses	When to Choose
AWS Application Discovery Service	AWS migration discovery and dependency mapping	AWS-native, integrates with Migration Hub, agent + VMware connector options	Not a full CMDB; dependency capture depends on observation window; requires network egress	When migrating to AWS and you need AWS-supported discovery
AWS Migration Hub Strategy Recommendations	Portfolio analysis and migration strategy suggestions	Helps with strategy (rehost/refactor/etc.) and planning inputs	Different purpose; not a direct replacement for host-level dependency discovery	When you need strategy and modernization recommendations in addition to discovery
AWS Application Migration Service (MGN)	Lift-and-shift server migration	Automated replication and cutover for servers	Not a discovery tool; needs planning inputs	After discovery, when executing rehost migrations
AWS Database Migration Service (DMS)	Database migrations	Supports many DB engines, continuous replication	Not for general server/app discovery	When moving databases, often after discovery identifies sources
Azure Migrate (Microsoft Azure)	Discovery/assessment for Azure migrations	Strong Azure integration, assessment, dependency mapping options	Cloud-specific; not AWS-native	When migrating primarily to Azure
Google Cloud migration assessment tooling	Discovery/assessment for Google Cloud	Google Cloud-aligned planning	Cloud-specific; feature set differs	When migrating primarily to Google Cloud
CMDB discovery tools (e.g., ServiceNow Discovery) / third-party APM	Enterprise inventory and service mapping	Deep ITSM integration; sometimes richer service maps	Licensing cost; setup complexity; may be overkill for one-time migrations	When you need ongoing enterprise service mapping beyond migration
Open-source discovery (osquery + custom pipelines)	Highly custom environments	Full control; can integrate with existing tooling	Engineering effort; no turnkey Migration Hub integration	When you need bespoke discovery and can invest engineering time

15. Real-World Example

Enterprise example: 2,000-VM data center exit

Problem: A regulated enterprise must exit a data center in 12 months. CMDB data is incomplete, and application dependencies are unclear.
Proposed architecture:
Use AWS Discovery Connector to rapidly ingest VMware VM inventory.
Deploy AWS Discovery Agent on a targeted subset of critical workloads to capture network dependencies and utilization over 4–8 weeks.
Use AWS Migration Hub to group servers into business applications and manage migration waves.
Export discovery data to a governed analytics environment for reporting and sign-offs.
Why AWS Application Discovery Service was chosen:
AWS-native discovery with Migration Hub integration.
Supports both breadth (connector) and depth (agents).
Helps create evidence-based wave plans.
Expected outcomes:
Higher confidence migration sequencing.
Reduced cutover incidents caused by missed dependencies.
Better cost control through right-sizing and retirement candidates.

Startup/small-team example: migrating a small on-prem footprint

Problem: A startup has ~25 servers across a small colocation setup. Knowledge is tribal; one engineer “knows everything.”
Proposed architecture:
Install AWS Discovery Agent on all production servers for 2–3 weeks.
Use the discovered dependency information to plan a single migration wave per product.
Group servers into a few Migration Hub applications for tracking.
Why AWS Application Discovery Service was chosen:
Minimal service cost and AWS-native workflow.
Enough dependency visibility to avoid breaking critical integrations.
Expected outcomes:
A documented inventory and dependency list.
A cleaner cutover plan with fewer surprises.
Faster migration execution because planning is clearer.

16. FAQ

1) Is AWS Application Discovery Service the same as AWS Migration Hub?
No. AWS Application Discovery Service collects discovery data. AWS Migration Hub is a central place to group servers into applications and track migrations. They are commonly used together.

2) Does AWS Application Discovery Service migrate my servers to AWS?
No. It is for discovery and planning. For server migration, look at AWS Application Migration Service (MGN) or other migration tools.

3) What’s the difference between the Discovery Agent and the Discovery Connector?
The Discovery Agent is installed on servers and can collect deeper host-level metrics and network connections. The Discovery Connector is a VMware appliance that discovers VM inventory via vCenter without per-VM agent installs.

4) Can I use AWS Application Discovery Service for on-premises servers?
Yes. That is one of its primary use cases, as long as the servers can reach AWS discovery endpoints.

5) Can I run the Discovery Agent on EC2 instances?
Often yes for lab/testing, and sometimes for specific inventory needs, but the service is primarily intended for on-prem/hybrid discovery. Verify any constraints in the official docs.

6) How long should I run discovery?
Long enough to capture typical and infrequent dependencies (often weeks). For seasonal workloads, you may need longer. The right window depends on your environment.

7) Does it capture database queries or application-level traces?
No. It captures infrastructure-level and connection/dependency metadata, not APM traces.

8) Is the data encrypted in transit?
Yes, collectors communicate with AWS endpoints over TLS.

9) Where is discovery data stored?
In the AWS Region where you run the service. Choose the Region carefully for governance and operational needs.

10) Can I export discovery data?
Yes, you can export discovered data for analysis. Exact export formats and fields can vary—verify in the console and official docs.

11) How do I control who can see/export discovery results?
Use IAM policies and roles. Separate permissions for viewers vs exporters, and enforce MFA for console access.

12) What are the most common causes of “no data” after installing the agent?
Outbound network restrictions (HTTPS 443 blocked), wrong Region selected, proxy misconfiguration, or agent not running.

13) Does agentless discovery work without VMware?
The Discovery Connector is VMware-focused. For non-VMware environments, agent-based discovery is typical.

14) Is AWS Application Discovery Service free?
AWS generally lists it as no additional charge, but you still pay for related infrastructure and data transfer. Confirm on the official pricing page.

15) Can this replace our CMDB?
Usually no. It helps create/validate inventory and dependencies, but CMDB processes (ownership, lifecycle, approvals) are broader than discovery.

17. Top Online Resources to Learn AWS Application Discovery Service

Resource Type	Name	Why It Is Useful
Official Documentation	AWS Application Discovery Service User Guide: https://docs.aws.amazon.com/application-discovery/latest/userguide/what-is-appdiscovery.html	Canonical, up-to-date concepts, setup, and operational guidance
Official API Reference	AWS Application Discovery Service API Reference: https://docs.aws.amazon.com/application-discovery/latest/APIReference/Welcome.html	Automation, exports, and programmatic discovery workflows
Official Pricing Page	AWS Application Discovery Service Pricing: https://aws.amazon.com/application-discovery/pricing/	Confirms “no additional charge” status and any exceptions
Pricing Tool	AWS Pricing Calculator: https://calculator.aws/	Estimate indirect costs (EC2 lab, storage for exports, network)
Related Service (Official)	AWS Migration Hub: https://aws.amazon.com/migration-hub/	Shows how discovery data is grouped and used for migration tracking
Migration Guidance	AWS Migration & Transfer: https://aws.amazon.com/migration/	Broader migration methodology and service map
Architecture Guidance	AWS Architecture Center: https://aws.amazon.com/architecture/	Patterns and best practices for migration-related architectures
Video (Official)	AWS YouTube Channel: https://www.youtube.com/user/AmazonWebServices	Search for discovery/migration hub sessions and demos
Hands-on Learning (Official)	AWS Skill Builder: https://skillbuilder.aws/	Structured courses and labs (availability varies; search for migration discovery topics)
Community (Reputable)	AWS re:Post: https://repost.aws/	Real-world troubleshooting and Q&A from AWS community (validate answers against docs)

18. Training and Certification Providers

DevOpsSchool.com – Suitable audience: DevOps engineers, cloud engineers, SREs, platform teams, migration practitioners – Likely learning focus: AWS fundamentals, migration tooling overview, DevOps practices, hands-on labs – Mode: check website – Website: https://www.devopsschool.com/
ScmGalaxy.com – Suitable audience: DevOps and SCM learners, build/release engineers, platform teams – Likely learning focus: DevOps tooling, CI/CD, configuration management, cloud operations foundations – Mode: check website – Website: https://www.scmgalaxy.com/
CLoudOpsNow.in – Suitable audience: Cloud operations engineers, sysadmins transitioning to cloud, DevOps engineers – Likely learning focus: Cloud ops practices, monitoring, reliability, operational readiness – Mode: check website – Website: https://www.cloudopsnow.in/
SreSchool.com – Suitable audience: SREs, reliability engineers, operations teams, incident responders – Likely learning focus: SRE principles, observability, reliability patterns, operational excellence – Mode: check website – Website: https://www.sreschool.com/
AiOpsSchool.com – Suitable audience: Ops teams, SREs, ITSM practitioners exploring AIOps – Likely learning focus: AIOps concepts, event correlation, automation foundations, ops analytics – Mode: check website – Website: https://www.aiopsschool.com/

19. Top Trainers

RajeshKumar.xyz – Likely specialization: DevOps and cloud training (verify specific course offerings on site) – Suitable audience: Beginners to intermediate DevOps/cloud learners – Website: https://www.rajeshkumar.xyz/
devopstrainer.in – Likely specialization: DevOps training programs and practical coaching (verify current curricula on site) – Suitable audience: DevOps engineers, CI/CD practitioners, cloud learners – Website: https://www.devopstrainer.in/
devopsfreelancer.com – Likely specialization: Freelance DevOps services and/or training resources (verify offerings on site) – Suitable audience: Teams or individuals seeking practical DevOps guidance – Website: https://www.devopsfreelancer.com/
devopssupport.in – Likely specialization: DevOps support and training (verify specific services on site) – Suitable audience: Operations/DevOps teams needing hands-on help – Website: https://www.devopssupport.in/

20. Top Consulting Companies

cotocus.com – Likely service area: Cloud and DevOps consulting (verify exact services on website) – Where they may help: Migration planning, cloud architecture, DevOps enablement, operational readiness – Consulting use case examples:
- Designing a discovery and migration planning approach for a hybrid environment
- Setting up governance for discovery exports and access controls
- Website: https://cotocus.com/
DevOpsSchool.com – Likely service area: DevOps and cloud consulting and training (verify current offerings) – Where they may help: Migration program enablement, DevOps pipeline setup, cloud operations – Consulting use case examples:
- Building a migration factory runbook including discovery, grouping, and wave planning
- Training teams to operate migration tooling safely
- Website: https://www.devopsschool.com/
DEVOPSCONSULTING.IN – Likely service area: DevOps consulting services (verify exact offerings on website) – Where they may help: CI/CD, infrastructure automation, operational practices around migration – Consulting use case examples:
- Implementing least-privilege IAM patterns and audit controls for migration tooling
- Creating standardized server build and cutover automation runbooks
- Website: https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before this service

AWS basics: IAM, Regions, VPC fundamentals, EC2 basics.
Networking fundamentals: DNS, HTTPS/TLS, proxies, NAT, firewall allowlisting.
Linux/Windows administration: package installation, services, logs.
Migration fundamentals: discovery → assessment → planning → migration → validation.

What to learn after this service

AWS Migration Hub deeper usage: application grouping, tracking, integration patterns.
AWS Application Migration Service (MGN) for rehost migrations.
AWS Database Migration Service (DMS) for database moves.
Observability and operations on AWS: CloudWatch, logging strategies, incident response.
Security on AWS: IAM least privilege, CloudTrail governance, centralized logging.

Job roles that use it

Cloud solution architect
Migration architect / migration factory engineer
DevOps engineer / platform engineer
Systems engineer / infrastructure engineer
Security engineer (supporting segmentation and migration governance)
IT program technical lead

Certification path (AWS)

AWS certifications don’t typically focus on a single service, but these are relevant: – AWS Certified Solutions Architect – Associate/Professional – AWS Certified SysOps Administrator – Associate – AWS Certified DevOps Engineer – Professional

For migration-focused skills, also consider AWS training paths on migration in AWS Skill Builder: – https://skillbuilder.aws/

Project ideas for practice

Run agent-based discovery on a small set of Linux/Windows VMs and produce:
Inventory report
Dependency summary
Proposed migration waves
Compare sizing recommendations from utilization vs static instance mapping.
Create an “application grouping” model in Migration Hub for 3 sample apps and document:
Owners
Dependencies
Cutover runbook outline
Build a simple script using the API reference to list discovered servers and export key attributes (verify API permissions and endpoints in docs).

22. Glossary

Discovery (migration): The phase where you inventory systems, collect performance baselines, and map dependencies prior to migration.
AWS Discovery Agent: Software installed on servers to collect configuration, performance, and network connection metadata for AWS Application Discovery Service.
AWS Discovery Connector: VMware virtual appliance that integrates with vCenter for agentless VM inventory discovery.
Dependency mapping: Identifying which systems communicate with others (IPs, ports, protocols) so migrations don’t break connectivity.
Migration wave: A planned batch of workloads migrated together, often grouped by dependencies and business priorities.
AWS Migration Hub: AWS service that helps track migration progress and group resources into applications.
IAM (Identity and Access Management): AWS service used to control access to AWS resources through users, roles, and policies.
Least privilege: Security principle of granting only the minimum permissions needed to perform a task.
CloudTrail: AWS service that logs supported API calls and account activity for auditing and governance.
Right-sizing: Selecting an appropriate compute size in AWS based on observed utilization and performance needs.
Egress: Outbound network traffic leaving an environment (often a cost driver outside AWS when going to the internet).

23. Summary

AWS Application Discovery Service is an AWS Migration and transfer service used to discover servers, collect utilization metrics, and map network dependencies so you can plan migrations to AWS with fewer surprises. It fits best in the early migration phases—before you execute moves with tools like AWS Application Migration Service (MGN) or AWS Database Migration Service (DMS)—and it commonly integrates with AWS Migration Hub for application grouping and tracking.

Cost-wise, the service is typically listed as no additional charge, but you must account for indirect costs such as agent deployment effort, network egress, and storage/analytics for exported datasets. Security-wise, treat discovery data as sensitive, use least-privilege IAM, restrict exports, and enable CloudTrail for auditing.

Use AWS Application Discovery Service when you need trustworthy inventory and dependency insight for migration planning. Next, deepen your workflow by learning AWS Migration Hub application grouping and then move into execution tooling (MGN/DMS) for your chosen migration strategy.

Category