Large enterprises migrating to AWS almost never have an accurate, current picture of their own infrastructure. Configuration management databases drift out of date the moment they’re written; server owners change teams; undocumented dependencies between applications accumulate silently over a decade of ad hoc changes. When a migration team tries to plan “move these 40 servers in wave one,” they frequently discover mid-migration that server #23 was quietly talking to a database server nobody scheduled for that wave, and the application breaks the moment it’s moved in isolation. Application Discovery Service exists to replace that guesswork with measured, automated data collection — actual CPU and memory utilization, actual network connections between servers, actual running processes — gathered continuously over weeks, not reconstructed from memory in a planning meeting.

Production example: large financial institutions migrating mainframe-adjacent server farms to AWS commonly report that Discovery Service surfaces dependency chains their own internal teams didn’t know existed — a batch-processing server quietly polling a reporting server every night that nobody had documented since the engineer who built that integration left the company years earlier. Catching that before migration, rather than during a failed cutover, is the entire value proposition.

This section assumes you already know Discovery Service “collects data about on-premises servers for migration planning.” It focuses on the mechanics and vocabulary that matter once you’re actually running a discovery project.

You may likeAWS Transit Gateway→

Agent-Based vs. Agentless Discovery

Discovery Service offers two fundamentally different collection mechanisms. The Discovery Agent is lightweight software installed directly on each server (Windows or Linux) that collects detailed, high-fidelity system performance data, running processes, and network connection information at the operating-system level. The Agentless Discovery Connector, by contrast, is a virtual appliance deployed into a VMware vCenter environment that collects inventory and utilization data about VMs without installing anything on the guest operating systems themselves, by querying vCenter’s own APIs. The intermediate-level distinction that matters: agent-based discovery sees inside the OS (actual process names, actual per-process network connections) while agentless discovery sees only what vCenter exposes about the VM from the hypervisor level — less granular, but zero-touch to the guest OS, which matters enormously in environments where installing new software on production servers requires a lengthy change-control process.

Static Configuration Data vs. Time-Series Utilization Data

Discovery Service collects two distinct categories of data that serve different purposes in migration planning. Static configuration data — hostname, OS version, installed applications, IP addresses — is captured largely as a snapshot and changes infrequently. Time-series performance data — CPU utilization, memory usage, disk I/O, network throughput — is sampled repeatedly (roughly every 15 seconds by the agent, aggregated into 5-minute and hourly rollups for reporting) over the full discovery window, which is what lets you right-size the target AWS instance based on actual peak and average load rather than the server’s theoretical maximum capacity, which is almost always wildly overprovisioned relative to real usage.

Network Connection Graphs and Dependency Mapping

Perhaps the single most valuable intermediate-level capability is the network connection data: Discovery Service records which servers are actually talking to which other servers, over which ports, and how frequently. This data is what powers dependency visualization in Migration Hub — instead of manually asking every application owner “what does your app talk to,” the connection graph is built empirically from observed TCP connections over the discovery period. This is also why discovery windows typically run for at least two to four weeks: many enterprise applications have monthly or quarterly batch jobs, and a connection that only fires once a month will be invisible if you only discover for a few days.

Grouping Servers Into “Applications”

Raw discovered servers are just a flat inventory until they’re grouped into logical Applications inside Migration Hub — a construct that represents a set of servers that should be migrated together as a unit because they’re functionally interdependent. This grouping can be done manually by a migration analyst reviewing the dependency graph, or informed by tagging conventions already present in the source environment. Grouping matters because migration waves are planned at the Application level, not the individual server level — you don’t want to migrate a web tier in wave one and its database tier in wave four, because the application simply won’t function correctly with that network latency and dependency gap in between.

The architecture separates cleanly into three layers: collection (agents and the agentless connector running in or near the source environment), transport (encrypted outbound connections carrying collected data to the AWS discovery service endpoint), and aggregation/presentation (the Discovery Service data store feeding Migration Hub’s visualization and grouping interface). Crucially, all communication is outbound-initiated from the source environment to AWS — neither the agent nor the agentless connector requires AWS to open any inbound connection into the on-premises network, which is a deliberate design choice that avoids the security review overhead of punching new inbound firewall holes into a production data center.

graph TB
    subgraph OnPrem["On-Premises / Data Center"]
        SRV1["Physical & Virtual
Servers"]
        AGENT["Discovery Agent
(installed per server)"]
        VCENTER["VMware vCenter"]
        CONNECTOR["Agentless Discovery
Connector (virtual appliance)"]
    end

    subgraph AWSCloud["AWS Cloud"]
        ENDPOINT["Discovery Service
API Endpoint"]
        STORE["Discovery Data Store"]
        HUB["AWS Migration Hub"]
        S3["Amazon S3
(Data Export)"]
    end

    SRV1 --> AGENT
    AGENT -->|"Outbound HTTPS"| ENDPOINT
    VCENTER --> CONNECTOR
    CONNECTOR -->|"Outbound HTTPS"| ENDPOINT
    ENDPOINT --> STORE
    STORE --> HUB
    STORE --> S3
    HUB -->|"Application Grouping
& Dependency View"| STORE
        

Migration Hub itself is not a separate data-collection system — it’s a presentation and orchestration layer that reads from the same underlying discovery data store, which is why data you see in Migration Hub’s dependency map is exactly the data Discovery Service collected, not a separately synchronized copy that could drift out of sync.

The Discovery Agent runs as a lightweight background process that periodically samples system-level metrics — CPU, memory, disk, and network counters exposed by the operating system — roughly every 15 seconds, buffers them locally, and transmits them in batches over an encrypted connection to the Discovery Service endpoint at a regular interval, typically every few minutes. This batching is deliberate: it avoids generating a constant drip of tiny network calls from thousands of servers simultaneously, which would create its own network load problem in the very data center you’re trying to profile without disruption.

For network connection data specifically, the agent inspects the server’s active TCP connection table (similar to what a command like netstat would show) at each sampling interval, records the local and remote IP/port pairs, and associates that connection with the local process that owns it where the OS exposes that mapping. Over the full discovery window, these individual snapshots are aggregated server-side into a connection graph — if server A is observed connecting to server B on port 5432 repeatedly across many samples, Discovery Service infers a persistent dependency, whereas a connection seen only once might be treated as transient or ignored depending on the analysis threshold.

The agentless connector works differently at the collection layer: rather than sampling from inside each guest OS, it periodically queries the vCenter API for VM-level performance counters (CPU ready time, memory balloon, datastore I/O) that vCenter itself already aggregates from the hypervisor, and separately queries inventory metadata (VM name, guest OS type, allocated resources). It does not have visibility into per-process network connections inside the guest, which is the direct architectural consequence of not running inside the guest OS at all.

You may likeAWS Artifact→

Follow a discovery project from start to finish. A migration team first deploys either the Discovery Agent on target servers or the Agentless Discovery Connector into their vCenter environment, both of which register themselves with the Discovery Service endpoint in AWS using credentials scoped for data submission only. Over the following weeks, collected performance and connection data streams into the Discovery Service data store, growing richer as more of the natural usage cycle of each application is captured — daily peaks, weekly batch jobs, month-end processing spikes.

Partway through this window, a migration analyst opens Migration Hub and begins reviewing the emerging dependency graph, grouping discovered servers into logical Applications as patterns become clear. This grouping is iterative — early in the discovery window, the graph may show incomplete or ambiguous connections that only resolve into a clear picture after a full business cycle has been observed. Once the team is satisfied with the data completeness, they export the inventory and utilization data to S3 as CSV, feed it into right-sizing logic (either AWS’s own recommendations or a third-party TCO tool), and use the finalized Application groupings to define migration waves — which servers move together, in what order, and on what timeline.

Discovery Service is built to profile environments ranging from a few dozen servers to tens of thousands without requiring the migration team to provision or manage any collection infrastructure themselves beyond deploying the lightweight agent or connector. Because each agent operates independently, batching and transmitting its own data on its own schedule, the collection layer scales horizontally simply by installing more agents — there’s no shared collection bottleneck comparable to a single centralized polling server that would need capacity planning as the fleet grows.

The agentless connector, by contrast, does introduce a single point that scales less linearly: because it polls vCenter’s API on behalf of every VM it’s configured to discover, very large VMware environments (many thousands of VMs under one vCenter) can require tuning the connector’s polling interval or deploying multiple connector appliances across vCenter clusters to keep collection latency reasonable. This is a direct consequence of the architectural choice to collect from the hypervisor side rather than distributing collection load across each individual guest OS.

You may likeEC2 Auto Scaling→

Because both the agent and the agentless connector buffer data locally before transmission, transient network interruptions between the data center and AWS do not cause data loss for short outages — collected samples queue locally and transmit once connectivity resumes. This matters in practice because enterprise data centers undergoing migration planning are frequently also undergoing other network changes concurrently, and discovery data collection needs to tolerate that churn without silently losing weeks of collected history over a brief connectivity blip.

On the AWS side, the discovery data store itself inherits the standard multi-AZ durability of the underlying storage service backing it, meaning data that has successfully reached AWS is not at meaningful risk of loss from an AWS-side infrastructure failure — the reliability risk in practice sits almost entirely on the collection side, inside the customer’s own network.

The agent and agentless connector authenticate to AWS using credentials scoped narrowly to data submission for the Discovery Service, following the principle that a component collecting sensitive internal network topology data should not also hold broad permissions to read or modify anything else in the AWS account. All data in transit between the collection layer and AWS uses encrypted connections, and collected data at rest inherits AWS’s standard encryption for the underlying storage.

In practice, discovery deployment is staged rather than all-at-once: teams typically pilot the agent or connector against a small, representative subset of servers first to validate that data is flowing correctly and that the collection mechanism doesn’t introduce any measurable performance overhead on production systems, before rolling it out across the full fleet slated for migration. This staged approach also gives the security and change-management teams a concrete, low-risk example to review before approving fleet-wide deployment.

You may likeAWS Site-to-Site VPN→

Large insurance and financial services firms undertaking data-center exit projects — moving entirely off owned data centers onto AWS within a fixed multi-year deadline — commonly cite Discovery Service’s dependency mapping as the tool that let them sequence thousands of servers into coherent migration waves rather than attempting the far riskier approach of migrating servers in isolation based on incomplete internal documentation. Healthcare organizations migrating clinical and administrative systems have described using extended discovery windows specifically to capture month-end and quarter-end billing cycle dependencies that would otherwise have been invisible in a standard multi-week assessment. Retail companies preparing for a full cloud migration ahead of a major shopping season have used discovery data to identify which server clusters experience genuine seasonal peak load, ensuring those specific applications receive more conservative right-sizing rather than applying a single generic sizing formula across the entire estate.