Study guide
Technical reference and lesson notes
Purpose of This Lesson
AWS Application Discovery Service helps organizations understand their on-premises environment before migrating workloads to AWS. It collects server configuration, utilization, network, disk, and process data so architects can assess dependencies, size target resources, and plan migration waves.
The most important exam distinction is choosing between the Discovery Connector and the Discovery Agent based on the source environment.
Key Concepts
What Application Discovery Service Collects
Discovery data can include:
- Hostnames, IP addresses, and MAC addresses
- Operating system and server configuration details
- CPU, memory, and disk allocation
- CPU, memory, disk I/O, and other utilization metrics
- Network input/output information
- Running processes
- VM-level utilization data in VMware environments
This information supports migration planning, dependency analysis, workload right-sizing, and cost estimation.
Discovery Connector: Agentless VMware Discovery
The Discovery Connector is an agentless collection method for VMware environments.
Deployment characteristics:
- Deploy the connector as an OVA appliance into VMware vCenter.
- Configure it at the vCenter level rather than installing software individually on every VM.
- Use it to collect static configuration and VMware VM utilization data.
- It is suitable for VMware environments where installing an agent on every guest is undesirable or impractical.
The connector does not provide the same level of guest-level detail as the Discovery Agent. Its collected data is primarily VMware inventory and VM utilization information.
Discovery Agent: Per-Server Discovery
The Discovery Agent is installed directly on individual servers. It is required for:
- Physical servers
- Hyper-V virtual machines
- Other supported systems where the VMware connector cannot be used
The agent can collect more detailed host-level information, including:
- Static configuration data
- Time-series performance data
- Network I/O metrics
- Running processes
The agent supports selected Linux distributions and Windows Server versions. Always verify the current AWS documentation for exact operating-system and version support when implementing a real migration.
Import Templates
Instead of collecting data directly with a connector or agent, an organization can prepare an import template and upload inventory data to Application Discovery Service.
This approach is useful when data already exists in sources such as:
- Configuration management databases
- Existing infrastructure monitoring platforms
- Internal inventory systems
- Performance reporting tools
The data must follow the required AWS template format. Typical fields include server identity, networking information, processor and memory details, disk information, process data, and performance metrics.
Amazon S3, Athena, and QuickSight
Application Discovery Service can export collected discovery data to Amazon S3. Once in S3, the data can be analyzed with:
- Amazon Athena for SQL queries over the exported data
- Amazon QuickSight for dashboards and visualization
This is useful when migration teams need custom reporting beyond the standard discovery views.
Relationship with Migration Hub
Application Discovery Service is accessed through the AWS migration tooling experience, including AWS Migration Hub. Migration Hub provides a central place to organize discovery and migration activity, while Application Discovery Service supplies information about the existing environment.
Exam-Relevant Takeaways
- The Discovery Connector is agentless and is used for VMware environments.
- The connector is deployed per vCenter as an OVA appliance.
- The Discovery Agent is installed per server.
- Use the agent for physical servers and Hyper-V virtual machines.
- In a mixed environment, use the connector for VMware and the agent for physical and Hyper-V systems.
- Do not select the connector for Hyper-V merely because the workload is virtualized. The connector is VMware-specific.
- The connector primarily provides static inventory and VMware VM utilization data.
- The agent provides more detailed host-level data, including time-series metrics, network I/O, and running processes.
- Discovery data can be exported to S3 and queried with Athena or visualized with QuickSight.
- An import template is appropriate when inventory and performance data already exists in another system.
Architecture Decision Guide
| Source environment or requirement | Recommended method | Deployment scope | Typical data collected |
|---|---|---|---|
| VMware vCenter | Discovery Connector | Per vCenter | Static configuration and VM utilization |
| Physical Windows or Linux server | Discovery Agent | Per server | Configuration, performance, network I/O, and processes |
| Hyper-V virtual machine | Discovery Agent | Per server/VM | Configuration, performance, network I/O, and processes |
| VMware plus physical and Hyper-V systems | Connector for VMware; agent for the others | Per vCenter and per server as applicable | Environment-specific discovery data |
| Existing inventory in a CMDB or monitoring platform | Import template | Upload prepared data | Data supported by the template |
| Custom analysis and reporting | Export to S3, then use Athena or QuickSight | S3-based analytics | Queryable and visualized discovery data |
Common Exam Traps
Assuming All Virtual Machines Use the Connector
The connector is not a general virtual-machine discovery mechanism. It is designed for VMware environments. Hyper-V VMs require the Discovery Agent.
Using the Agent for Everything in a Mixed Environment
A mixed environment does not require installing agents on VMware guests. Use the agentless connector for VMware and reserve agents for physical and Hyper-V systems.
Confusing Deployment Scope
Remember the deployment distinction:
- Connector: deployed per vCenter
- Agent: installed per server
Expecting Identical Data from Both Methods
The connector gathers VMware inventory and VM utilization information. The agent gathers additional guest-level details, such as running processes and network I/O.
Treating Discovery as the Migration Mechanism
Application Discovery Service collects information for assessment and planning. It does not, by itself, migrate applications or servers to AWS. Select a separate migration service or process for the actual workload move.
Ignoring Import Templates
If the organization already has reliable inventory and performance data, uploading it through the import template may be more appropriate than deploying discovery software immediately.
Real-World Engineer Notes
- Begin discovery before selecting EC2 instance sizes or designing migration waves. Utilization data is more useful than allocated capacity alone.
- Use the least intrusive discovery method that still provides the required detail. The VMware connector reduces per-guest installation effort, while agents provide richer host-level data.
- Validate data quality before using it for right-sizing. A short or unrepresentative observation period can lead to incorrect capacity decisions.
- Treat discovery data as operationally sensitive. Hostnames, IP addresses, process lists, and infrastructure metadata should be protected with appropriate IAM, encryption, and access controls.
- For large estates, export data to S3 and build repeatable Athena queries or QuickSight dashboards for utilization, ownership, migration wave, and dependency analysis.
- Confirm current supported operating systems and connector behavior in AWS documentation before deployment; service capabilities and supported versions can change.
Quick Reference Summary
- VMware: use the agentless Discovery Connector.
- Physical servers: install the Discovery Agent.
- Hyper-V: install the Discovery Agent.
- Connector deployment: per vCenter.
- Agent deployment: per server.
- More detailed host data: generally comes from the agent.
- Existing external inventory: use an import template.
- Custom analytics: export to S3 and use Athena or QuickSight.
- Primary purpose: assess and plan migration, not perform the migration itself.
Flashcards
- Q: What is the primary purpose of AWS Application Discovery Service?
A: To collect information about on-premises servers, applications, utilization, and dependencies to support migration assessment and planning.
- Q: Which discovery method is agentless?
A: The Discovery Connector.
- Q: Which environment is supported by the Discovery Connector?
A: VMware environments managed through vCenter.
- Q: Where is the Discovery Connector deployed?
A: As an OVA appliance in VMware vCenter, generally per vCenter.
- Q: Which systems require the Discovery Agent?
A: Physical servers and Hyper-V virtual machines, among other supported systems where the connector is unavailable.
- Q: What is the agent deployment scope?
A: The agent is installed on each participating server.
- Q: Name three types of data collected by the Discovery Agent.
A: Static configuration, time-series performance metrics, network I/O, and running processes.
- Q: What is the correct approach for VMware, Hyper-V, and physical servers in the same data center?
A: Use the connector for VMware and the agent for Hyper-V and physical servers.
- Q: When is an import template useful?
A: When inventory or performance data already exists in a CMDB, monitoring platform, or other internal system.
- Q: Where can discovery data be exported for custom analysis?
A: Amazon S3, where it can be queried with Athena or visualized with QuickSight.
- Q: Does Application Discovery Service migrate workloads to AWS?
A: No. It provides assessment and planning data; separate migration tooling or procedures perform the migration.
- Q: What is a key limitation of the Discovery Connector compared with the agent?
A: The connector is focused on VMware inventory and VM utilization and does not provide the same guest-level detail as an installed agent.
Practice Questions
Question 1
A company is assessing a data center that contains VMware virtual machines, Hyper-V virtual machines, and physical Linux servers. The company wants to minimize software installation while collecting discovery data from the entire environment. Which approach should an architect recommend?
A. Install the Discovery Agent on every server, including VMware guests
B. Deploy the Discovery Connector to Hyper-V and install agents on VMware guests
C. Deploy the Discovery Connector for VMware and install the Discovery Agent on Hyper-V and physical servers
D. Use only an import template and do not connect to the environment
Correct answer: C
Explanation: The Discovery Connector is the agentless method for VMware and is deployed through vCenter. Hyper-V and physical systems require the Discovery Agent. This hybrid approach minimizes installation while using the appropriate method for each platform.
Question 2
A migration team needs to identify running processes, network I/O, and time-series performance metrics on a group of physical Windows servers. Which Application Discovery Service capability should the team use?
A. Discovery Connector
B. Discovery Agent
C. VMware vCenter inventory export
D. AWS Migration Hub only
Correct answer: B
Explanation: The Discovery Agent is installed per server and provides host-level information such as performance data, network I/O, and running processes. The connector is intended for VMware environments and does not provide equivalent guest-level detail.
Question 3
An enterprise has six months of server inventory and utilization data stored in an internal configuration management database. It wants to load the data into AWS Application Discovery Service without installing software on its servers. What should the enterprise do?
A. Deploy a connector to each physical server
B. Install the Discovery Agent on every server
C. Format the data according to the Application Discovery Service import template and upload it
D. Store the raw database directly in Amazon QuickSight
Correct answer: C
Explanation: Application Discovery Service supports importing collected inventory through a defined template. The source data must be transformed to the required format before upload. QuickSight is an analysis and visualization service, not the ingestion mechanism for this discovery workflow.
Question 4
A solutions architect wants to create custom dashboards showing server utilization and migration-wave readiness from Application Discovery Service data. Which design is most appropriate?
A. Export the data to Amazon S3, query it with Athena, and visualize results with QuickSight
B. Store the data in Amazon Route 53 and query it with AWS WAF
C. Send the data to Amazon CloudFront and use an Auto Scaling group for analysis
D. Use only the Migration Hub console because discovery data cannot be exported
Correct answer: A
Explanation: Discovery data can be exported to Amazon S3. Athena can query the S3 data, and QuickSight can use the results for dashboards and reporting.
Question 5
A team plans to use the VMware Discovery Connector for a Hyper-V estate because both platforms host virtual machines. What should the architect explain?
A. The connector supports all major hypervisors without modification
B. Hyper-V requires the Discovery Agent on the relevant servers
C. Hyper-V can be discovered only through an import template
D. Hyper-V does not support discovery by Application Discovery Service
Correct answer: B
Explanation: The connector is VMware-specific. Hyper-V systems are treated like physical servers for this decision and require the Discovery Agent.