AWS Application Discovery Service FAQs

AWS Application Discovery Service collects and presents data to enable enterprise customers to understand the configuration, usage, and behavior of servers in their IT environments. Server data is retained in the Application Discovery Service where it can be tagged and grouped into applications to help organize AWS migration planning. Collected data can be exported for analysis in Excel or other cloud migration analysis tools.

Application Discovery Service helps enterprises obtain a snapshot of the current state of their data center servers by collecting server specification information, hardware configuration, performance data, and details of running processes and network connections. Once the data is collected, you can use it to perform a Total Cost of Ownership (TCO) analysis and then create a cost optimized migration plan based on your unique business requirements.

Application Discovery Service supports both agent and agentless-based on-premises tooling, in addition to file-based import. With agentless discovery, customers deploy the tooling on centralized servers which then leverage public APIs within the on-premises environment to discover resources and monitor utilization. This process allows one install to monitor many servers. For customers that need higher resolution data, including information about running processes, the collection tooling is deployed on each server (physical or virtual) within the on-premises environment.

To get started with Application Discovery Service, simply visit the AWS Migration Hub console.

Application Discovery Service is available worldwide. This means you can perform discovery on resources regardless of their location. To see which regions the service is hosted in, please refer to the AWS Region Table.

Before using the Migration Hub and Application Discovery Service, you need to select a Migration Hub home region from the Migration Hub Settings page or using the Migration Hub Config API. Application Discovery Service uses the Migration Hub home region as the only AWS region to store your discovery and planning data. The data stored in the Migration Hub home region provides a single repository of discovery and migration planning information for your entire portfolio and a single view of migrations into multiple AWS regions. See the docs to learn more about the Migration Hub home region.

Customers looking for configuration, performance or network connection about on-premises VMware infrastructure, or database discovery, should use the AWS Application Discovery Service Agentless Collector. The data discovered may be used in both Migration Hub and AWS Database Migration Service (AWS DMS) Fleet Advisor. Both agent-based and agentless Application Discovery may be run simultaneously.

Customers looking for process-level dependency data are advised to use the AWS Application Discovery Service Discovery Agent. The data collected may be used in both Migration Hub and HAQM Athena.

Customers looking for a guided migration assessment or agentless server dependency mapping should request an assessment via Migration Evaluator. This service offers a dedicated solutions architect to assist with data discovery and provide migration expertise. The Migration Evaluator Agentless Collector monitors VMware, Hyper-V, SQL Server, Windows, and Linux workloads. The data collected may be used in both Migration Hub and Migration Evaluator.

The Discovery Agent captures system configuration, system performance, running processes, and details of the network connections between systems.

Application Discovery Service launched a new 2.0 version of the Discovery Agent that offers better operating system support. 2.0 version of the Discovery Agent supports Microsoft Windows Server 2008 R1 SP2, 2008 R2 SP1, 2012 R1, 2012 R2, 2016, 2019, HAQM Linux 2012.03, 2015.03, HAQM Linux 2 (9/25/2018 update and later), Ubuntu 12.04, 14.04, 16.04, 18.04, 20.04, Red Hat Enterprise Linux 5.11, 6.10, 7.3, 7.7, 8.1, CentOS 5.11, 6.9, 7.3 and SUSE 11 SP4, 12 SP5.

The Discovery Agent uses HTTPS/TLS to transmit data to Application Discovery Service. The Discovery Agent can be operated in an offline test mode that writes data to a local file so customers can review collected data before enabling online mode.

Please refer to the documentation for details on how to install the Discovery Agent.

No, the Discovery Agent deployed on your data center server will not grant AWS remote access. However, the Discovery Agent does need to establish an outbound SSL connection to transfer the collected data to AWS.

Yes. You can install the Discovery Agents on your EC2 instances to perform discovery and report upon performance information, network connections, and running processes, just as for any other server.

‘Agentless’ means that software does not need to be installed on each host to use Application Discovery. Simply install the Agentless Collector as an OVA on the VMware vCenter.

The Agentless Connector is delivered as an Open Virtual Appliance (OVA) package that can be deployed to a VMware host. The data collected is dependant on which capabilities are configured. Providing credentials to connect to vCenter, the Agentless Collector collects VM inventory, configuration, and performance history such as CPU, memory, and disk usage. Proving read-only credential for the virtual machines running Windows or Linux collects established TCP connections. Providing credentials to databases such as Oracle, SQL Server, MySQL, or PostgreSQL collects version, edition and schema. Server and database information is uploaded to the Application Discovery Service data store. Database infromation can also be send to DMS Fleet Advisor for analysis.

Agentless discovery is OS agnostic. It collects information about VMware virtual machines regardless of the VM operating system.

The Agentless Collector uses HTTPS/TLS to transmit data to the Application Discovery Service.

Please refer to the documentation for details on how to install the Agentless Collector.

Data collection is controlled from the local Agentless Collector UI. You will need access to the on-premises environment to start or stop collection.

No, the Agentless Collector deployed on your VMware environment will not grant AWS remote access to your data center servers. However, the tool requires VMware credentials in order to collect data. These credentials reside locally and are never shared with AWS. The Agentless Collector establishes outbound SSL connection to transfer only the collected data.

No. The Agentless Collector installs on VMware and collects information only from the VMware vCenter.

Application Discovery Service is designed to capture a variety of data including static configuration such as server hostnames, IP addresses, MAC addresses, CPU allocation, network throughput, memory allocation, disk resource allocations, and DNS servers. It also captures resource utilization metrics such as CPU usage, memory usage and established TCP connections. In addition, the Discovery Agent can help determine server workloads by collecting process information.

Yes, disk metrics, such as read and write volume, throughput, allocated/provisioned and utilized capacity, are captured by this service.

Information is gathered only when the Discovery Agent or the Agentless Collector is online.

Yes, you can import information about your on-premises servers and applications into the Migration Hub so you can track the status of application migrations. To import your data, you can download and populate the import CSV template and then upload it using the Migration Hub import console or by invoking the Application Discovery Service APIs.

Summary data can be viewed in the AWS console. You can export detailed data collected by Application Discovery Service using the AWS Console or a public API. The service exports data in CSV format.

In Migration Hub, you can group your servers into applications and assign each a wave ID. Then, use the "EC2 recommendations" capability to generate a rightsized migration plan to import into Application Migration Service (MGN) and manage your migration waves.

The Data Exploration feature allows customers to analyze the data collected from their on-premises servers by Application Discovery Service agents in one single place. Once a customer enables this feature, data collected by agents is automatically stored in an HAQM S3 bucket created in their account. Customers can query the collected data in HAQM Athena and visualize the query output in HAQM QuickSight to perform migration planning.

If the Data Exploration feature is turned on when you get to HAQM Athena, you can see a database called “application_discovery_service_database”. Inside the database, a list of tables is created by default for you. These tables include:

• os_info_agent
• network_interface_agent
• sys_performance_agent
• processes_agent
• inbound_connection_agent
• outbound_connection_agent
• id_mapping_agent

The Application Discovery Service discovery tools are available at no charge. However, additional charges may apply for streaming agent data via HAQM Kinesis Data Firehose, for storing the agent data in a S3 bucket and for querying the agent data in HAQM Athena. The cost of using each of these AWS resources will vary based on the actual time period you collect data via agents, the number of agents you have deployed, the network activity on each server where the agent is deployed, and the number of queries that are run on the collected data.

No, the Data Exploration feature is a global setting for all agents. The global setting ensures that data collected by all agents is for the same time period.

No, you don’t have to create an S3 bucket on your own. When you turn on this new feature for the first time, a S3 bucket with the name “aws-application-discovery-service-” is created automatically on your behalf. By default, this bucket and the discovery data saved to this bucket are private. Only the users in your account with permission to Application Discovery Service and Migration Hub can access the bucket and the data it contains.

Yes, the data stored in the designed S3 bucket is encrypted using the customer master key. You can also further control access to your S3 resources by using a combination of bucket ACLs and IAM and bucket policies.