Configuration best practices

This section describes the configuration for the most restrictive scenario (replication over private networks only), as shown in the first diagram, based on the considerations discussed earlier. You can configure both hybrid scenarios by skipping parts of the most restrictive configuration:

The following sections assume that the initial AWS Transform MGN configuration is already complete, as described in the blog posts Accelerate your Migration with AWS Transform MGN and How to Use the New AWS Transform MGN for Lift-and-Shift Migrations). This discussion focuses on components that are specific to the restrictive scenario, and assumes a private staging subnet that has no connectivity to the internet.

Subnets and routing configurations

For the restrictive scenario, you configure the required AWS resources in the private subnet of a staging VPC. This subnet has no connectivity to the internet (there's no internet gateway attached to the routing table as a default route). Instead, it uses either a virtual gateway associated with an AWS Site-to-Site VPN gateway (connected through an IPsec tunnel to an on-premises gateway), or it's connected to a transfer gateway or to AWS Direct Connect services to provide private interconnectivity to the on-premises data centers.

You will use that private subnet as a staging subnet for replication-related resources managed by MGN, and you'll configure all required network access through this subnet by using VPC endpoints, as discussed in the next section.

VPC endpoints configuration

You now need to create VPC endpoints in the staging subnet to provide connectivity for the replication servers and MGN Agents from on-premises subnets.

Here's a full list of VPC endpoints you need:

The next sections go into more detail about how VPC endpoints work. The following table lists all the endpoints created for the staging private subnet. (Note that the Amazon S3 gateway endpoint has no network interfaces provisioned but does have specific prefix lists provisioned into the subnet's route table, as will be described later in this guide.)

You can create optional VPC endpoints to enable access to Amazon EC2 instances on private isolated subnets through AWS Systems Manager, as discussed in Creating VPC endpoints in the Systems Manager documentation.

VPC interface endpoints

Creating an interface endpoint also creates a specific elastic network interface for each subnet that the given interface endpoint is provisioned for. For example, the MGN interface endpoint is provisioned in a private subnet in the staging VPC with an elastic network interface that is associated with the IP address inside that subnet, and it also has three DNS names resolvable from the subnet to this IP address:

This allows any instance running in the subnet that is using the default Dynamic Host Configuration Protocol (DHCP) option set configuration in the VPC, and has both DNS attributes enableDnsHostnames and enableDnsSupport enabled, to:

That fixes connectivity for any instances running in the staging subnet (such as the MGN replication server or conversion server) for any AWS service that has interface endpoints provisioned in the subnet (such as Amazon EC2, MGN, Systems Manager, AWS KMS, and so on).

VPC gateway endpoints

For services such as Amazon S3 there's no fixed DNS name that can be provisioned, because each bucket has its own DNS name. For this scenario you will use VPC gateway endpoints. 

Creating an Amazon S3 gateway endpoint also creates a specific prefix list object with a list of subnet destinations (in CIDR notation), which can be added in the subnet route table. Thus, DNS names of Amazon S3 buckets resolved to IP addresses included in this list would be accessible through internal connectivity. 

When you provision an Amazon S3 gateway endpoint, you can specify the subnets in the route tables that should include that prefix list ID (PL-<id>). The resulting route table for the staging private subnet must include that prefix list ID, as in this example route table:

DNS resolver inbound endpoints

The configuration described in the previous section is sufficient for instances that are running inside the AWS subnets, because they are already configured to use internal Amazon Route 53 DNS servers. However, on-premises source servers require additional steps to be able to communicate with AWS services privately. In particular, MGN Agent has to download the installer from Amazon S3 and then communicate with MGN by using DNS names provided in the documentation. On-premises servers use their default DNS servers to resolve these DNS names, resulting in public IP addresses. Communications with these addresses over HTTPS/TCP port 443 are eventually blocked by corporate firewalls.

To prevent this, you need to configure source servers or their default DNS servers to use Amazon Route 53 Resolver for resolution of these specific DNS names or a subdomain zone (that is, the full *.<region>.amazonaws.com zone) . This can be configured by creating a Route 53 Resolver inbound endpoint, which, like a VPC interface endpoint, has a dedicated elastic network interface created in the dedicated private subnet on AWS, and is thus able to forward DNS requests to Amazon Route 53 Resolver. 

Elastic network interface security groups

Each elastic network interface has a dedicated security group associated with it, which must permit traffic that's expected for this elastic network interface and corresponding endpoint. Thus, the DNS resolver endpoint's security group should permit inbound UDP port 53 (and sometimes TCP port 53) for DNS requests, and the endpoint security groups for most other services (MGN, Amazon EC2, Systems Manager, and so on) need inbound HTTPS/TCP port 443 enabled.

Installing MGN Agent on source servers

To install MGN Agent on source servers, you need to supply the DNS names of the MGN and Amazon S3 interface endpoints to the Agent's command line parameters (see Installing the Agent on a secured network in the MGN documentation). 

For the MGN endpoint, you can use any of the DNS names associated with it―a "Private DNS" field (mgn.<region>.amazonaws.com) or a VPC-specific DNS name (vpce-<VPC-id>-<suffix>.mgn.<region>.vpce.amazonaws.com)―and supply an argument: --endpoint <FQDN>. In fact, if you skip this argument, the Agent uses the specified AWS Region to reconstruct the default DNS FQDN (mgn.<region>.amazonaws.com) and uses the FQDN to access the MGN control plane. In most cases, that default behavior should suffice, as long as that FQDN resolves from the source server correctly to the private IP address of the elastic network interface for the MGN VPC endpoint created in the staging subnet. 

The Amazon S3 interface endpoint won't have a single private DNS name (because each bucket will have its own), so that option isn't supported. However, an Amazon S3 interface endpoint still has an elastic network interface associated with it. It also has a specific private IP and wildcard DNS names (in the format .vpce-<VPC-ID>-<suffix>.s3.<region>.vpce.amazonaws.com or Region-specific .vpce-<VPC-ID>-<suffix>-<region>.s3.<region>.vpce.amazonaws.com) that are resolvable to this private IP.

That wildcard DNS name can be used for the --s3-endpoint argument, as in the following:

aws-replication-installer-init.py --region <region> --aws-access-key-id <MGN_IAM_ACCESS_KEY>  --aws-secret-access-key <MGN_IAM_SECRET> --no-prompt \ 
--endpoint vpce-<VPC-id>-<suffix>.mgn.<region>.vpce.amazonaws.com --s3-endpoint vpce-<VPC-ID>-<suffix>-<region>.s3.<region>.vpce.amazonaws.com

The next section provides an example of configuring MGN, including all required VPC endpoints, and deploying the Agents by using VPC endpoints on Windows and Linux source servers. The section covers both manual and automated deployment.