Question

Difficulty: HardMigration Discovery, Planning, and Tracking (Application Discovery Service, Migration Hub)

A global agricultural technology platform is preparing to migrate its core crop-yield analysis and logistics coordination system to AWS. The on-premises infrastructure includes:

* 180180 VMware vSphere VMs running Red Hat Enterprise Linux (RHEL) and Windows Server. These VMs host the API layers and distributed processing nodes. The team requires deep mapping of network dependencies (TCP connections) between these servers to group them into application stacks.
* 3535 bare-metal servers running Oracle Solaris, hosting legacy databases and proprietary data processing engines. These servers are located in a highly secure zone with no outbound internet connectivity, and the OS is not supported by the AWS Application Discovery Agent.

All outbound traffic from the VMware vSphere environment must go through an on-premises HTTP proxy. The platform team wants to use AWS Migration Hub as the single pane of glass to plan the migration, group servers, and track the migration status of these workloads.

Which combination of discovery mechanisms and tracking setup should a solutions architect recommend to satisfy these requirements?

  1. Install the AWS Application Discovery Agent on the 180180 VMware vSphere VMs, configuring the agents to communicate via the on-premises HTTP proxy. For the 3535 bare-metal Solaris servers, manually collect configuration metadata and import it into AWS Migration Hub using a CSV file. Group the discovered assets into applications within Migration Hub, and track migration status using AWS Application Migration Service (MGN) or compatible third-party tools integrated with Migration Hub.Answer
  2. B
    Deploy the AWS Application Discovery Agentless Collector on VMware vCenter to discover the 180180 vSphere VMs and map their TCP network connections. Install the AWS Application Discovery Agent on the 3535 bare-metal Solaris servers, configuring a local port forwarder to route the discovery data through the RHEL VMs' HTTP proxy. Group the assets in AWS Systems Manager Application Manager and track migration status there.
  3. C
    Deploy the AWS Application Discovery Agentless Collector on VMware vCenter. For the 3535 bare-metal Solaris servers, establish a temporary IPSec VPN connection to AWS and install the AWS Application Discovery Agent on each server to stream discovery data. Group the servers into applications in AWS Migration Hub, and write custom AWS Lambda functions to query the Systems Manager Inventory API to update migration status.
  4. D
    Install the AWS Application Discovery Agent on all 180180 VMware vSphere VMs and the 3535 bare-metal Solaris servers, using the on-premises HTTP proxy for all outbound agent traffic. Group the discovered assets into applications in AWS Migration Hub. Track the migration status using AWS DataSync to monitor real-time virtual machine replication progress.

Answer

Install the AWS Application Discovery Agent on the VMware vSphere VMs, configuring the agents to communicate via the on-premises HTTP proxy. Manually collect metadata for the bare-metal Solaris servers and import it into AWS Migration Hub using a CSV file. Use Migration Hub-integrated migration tools to track migration status.
The correct recommendation is to install the AWS Application Discovery Agent on the VMware vSphere VMs because the team requires mapping of TCP network connections to group servers into application stacks, a capability that the Agentless Collector does not support. The Discovery Agent can be configured with proxy settings to route outbound traffic through the on-premises HTTP proxy. For the bare-metal Solaris servers, since Solaris is an unsupported operating system for the Discovery Agent, and they are not hosted on VMware, their configuration data must be manually collected and imported into AWS Migration Hub using a CSV file. Once assets are grouped into applications, migration status is natively tracked using Migration Hub-compatible tools such as AWS Application Migration Service.

Step-by-Step Solution

1
Determine the discovery mechanism for the VMware vSphere VMs that requires TCP network dependency mapping.
Select the AWS Application Discovery Agent (agent-based) because the Agentless Collector does not gather TCP network connection or process-level dependency data.
Agent-based discovery is required to map network dependencies between servers to identify application boundaries.
2
Determine the discovery mechanism for the bare-metal Solaris servers that are isolated and run an unsupported OS.
Select manual configuration import using a CSV template.
Solaris is not supported by the AWS Application Discovery Agent, and bare-metal servers cannot be discovered by the VMware Agentless Collector. An offline CSV import bypasses agent and network requirements.
3
Address the network proxy requirement for the discovery agents.
Configure the agent installation parameters to route outbound traffic through the on-premises HTTP proxy.
The agents require outbound connectivity to AWS endpoints to upload discovery data, which must go through the proxy per corporate security policy.
4
Set up tracking in AWS Migration Hub using integrated migration tools.
Group the discovered assets into applications in AWS Migration Hub, and execute the migration using AWS Application Migration Service (MGN) or other integrated tools.
Migration Hub tracks migration status natively only for tools that are registered and integrated with it, such as MGN.

Key Concept

Selecting and configuring the appropriate AWS Application Discovery Service and AWS Migration Hub tracking mechanisms based on OS compatibility, network constraints, and dependency mapping needs.
Estimated Time:2m 30s
Rate this question