Migration & Modernization

No Internet? No Problem: Mastering AWS MGN in Isolated Environments

In today’s cloud-driven world, migrating applications is often as simple as a few clicks. But what happens when you face a fortress-like environment where servers are running in an isolated environment with no internet like islands in a digital ocean? This is the reality for many organizations with high-security requirements, where even a simple task like installing the AWS Application Migration Service (MGN) replication agent becomes a formidable challenge.

Imagine an environment where there is no internet gateway, no NAT gateway, not even a proxy server in sight. In these isolated environments, the usual straightforward process of installing the MGN agent turns into a complex puzzle. Why? Because the agent needs to reach out to the S3 service endpoint to download its installer and the replication agent itself. And that’s not all – it also requires an ongoing connection to the MGN console, both during installation and throughout its operational life. So, how do you work round this lack of connectivity ? How do you maintain ironclad security while still leveraging the power of AWS MGN? Let’s explore secure migrations together. We’ll show you simple ways to connect systems and move data, making the process easy and achievable for everyone. Our approach makes the process manageable and achievable for any customer.

This post demonstrates the process of setting up the AWS MGN replication agent on servers within tightly secured environments that lack internet access. This includes replicating and safeguarding an Amazon Elastic Compute Cloud (EC2) instance running within a secured Virtual Private Cloud (VPC). We will employ VPC interface endpoints and the Amazon Simple Storage Service (S3) Gateway VPC endpoint. It is important to note that the AWS MGN agent requires access to the Amazon S3 service endpoint to download the agent installer and the replication agent itself. Additionally, during the installation process and while the source server is being replicated, the replication agent needs to maintain connectivity with the Application Migration Service console.

In the first part of this blog, our primary emphasis will be on utilizing interface endpoints. It is essential to configure a gateway endpoint for S3 as well. Detailed steps below will elucidate the entire process, providing a more comprehensive understanding.

Prerequisites

1. AWS Account and Access: You will need an AWS account and AWS Identity and Access Management (IAM) user to use AWS MGN. Please refer to AWS MGN initialization and permissions for details.

2. Initialize AWS MGN to use it. See AWS MGN User Guide for details.

3. EC2 instance running to test and install the AWS MGN agent.

4. Two separate VPCs, with one in each Region with no connection to the internet. Both Regions will be connected via VPC Peering connection. The target VPC will have staging subnets as well where data will be replicated and private subnets as target to launch the workload EC2s post cutover.

5. IAM user configured to create VPC endpoints, S3 endpoints, Gateway endpoints, and Security Groups.

6. To connect your on-premise DNS to Amazon Route53, you’ll need to create a private hosted zone in Route53 and configure your on-premise DNS server to forward queries for the hosted zone to the Route53 resolvers endpoints.

7. Replication and launch settings: Configure replication settings and launch settings in AWS MGN.

8. An understanding of VPC and S3 endpoints, along with VPC peering.

Solution Overview:

Scenario 1: From AWS region 1 to AWS region 2
                      (ap-southeast-1 -> ap-south-1)

In this scenario, we are replicating an EC2 instance that is currently operating within a highly secured VPC environment in the ap-southeast-1(Singapore) region to the ap-south-1(Mumbai) region. The VPC in the Asia Pacific (Mumbai) region is also tightly secured and lacks direct internet access. To facilitate communication between these two isolated VPC environments, a VPC peering connection has been established in this demo.

Figure 1: Architecture for AWS region 1 to AWS region 2

Scenario 2: On-premises to AWS

When it comes to on-premises infrastructure, the overall architectural approach remains consistent. However, the distinguishing factor lies in the connectivity method employed to establish a link between the on-premises infrastructure and the cloud infrastructure. The key points to consider in this approach are:

1. Connectivity Options:

AWS offers two primary options for establishing a secure connection between your on-premises infrastructure and its cloud services. The first option is AWS Direct Connect, which provides a dedicated, private network link directly from your data center to AWS. This direct connection ensures consistent network performance and can potentially reduce networking costs compared to other alternatives. Alternatively, you can utilize an AWS Site-to-Site VPN, which creates an encrypted virtual tunnel over the internet, connecting your on-premises network to your Amazon Virtual Private Cloud (VPC). This VPN option allows for secure communication between your local resources and AWS resources without the need for a dedicated physical connection. VPN would require less efforts and can get you started quickly, while Direct Connect offers plenty of bandwidth and types to choose from based on your requirements. You should consider properties such as performance, resilience and cost when deciding whether to go with VPN or Direct Connect and the environment such as Direct Connect for production and workloads that require high bandwidth and VPN for testing or generic workloads.

2. DNS Resolution:

The AWS MGN and Amazon EC2 interface endpoints have private DNS names that are resolvable within the VPC. However, on-premises servers also need to be configured to resolve these private DNS names. We need to resolve the private DNS names by forwarding on-premises DNS queries to the Amazon Route 53 Resolver inbound endpoint located in the staging area VPC.

3. AWS Transit Gateway: To interconnect customer on-premise network and VPCs in AWS.

Figure 2: Architecture for on-premises to AWS

Figure 2: Architecture for on-premises to AWS

Walkthrough

For the purpose of this blog, we have setup our source and architecture in different AWS regions (scenario 1) but you can follow a similar approach (scenario 2) as well, where your on-premises will become the source.

When setting up the installation, your source virtual machines would require a connection to the AWS MGN regional endpoint. This is the only network connectivity necessary during the agent installation process and throughout the agent’s operational lifetime on the source server. To guarantee that the source servers can access the Amazon S3 and AWS MGN regional endpoints, verify that the security groups associated with the VPC Interface endpoints permit HTTPS traffic originating from the source VPC CIDR as well as the staging area subnet.

Connecting source servers to endpoints

1. To facilitate the download of the replication installer and the replication agent on the source server, we will require access to S3. Hence, create a VPC S3 Interface endpoint in ap-south-1.

2. To download the installer, we will need to modify the URL of the installer and then specify the --s3-endpoint switch during the agent installation process.

3. During the installation, we will require connectivity to the MGN regional endpoint, and therefore, we will create an MGN VPC interface endpoint in the ap-south-1 region.

Connecting replication servers to endpoints

After determining the connection method between source servers and service endpoints, we will now explore how replication servers will be connected to these service endpoints. The replication servers located in the staging subnet will utilize the MGN interface endpoint to establish a connection with the regional MGN endpoint and the EC2 interface endpoint, to connect to the EC2 regional endpoint. However, the question arises: How will the connectivity to the S3 regional endpoint be facilitated?

To ensure that the replication servers can access Amazon S3 and download the replication server software, we need to create an S3 Gateway endpoint.

The specified connectivity for the staging area subnet is sufficient. However, it is crucial to verify that the security groups associated with these VPC interface endpoints permit HTTPS traffic originating from the staging subnet.

Verifying the accuracy and correctness of the route table.

A private source server is operational in the ap-southeast-1 region without any internet connectivity. The server’s subnet has a route table that enables communication with two different VPCs through respective VPC peering connections. The 172.16.0.0/16 CIDR range corresponds to the VPC from which you can establish an SSH connection to access this server. The 10.0.0.0/16 CIDR belongs to the VPC located in the ap-south-1 region, from which you want to protect this server.

Source server subnet route table:

Figure 3: Image of source route table with VPC peering connection for scenario 1

Likewise, the subnet designated as the staging area in the ap-south-1 region lacks internet connectivity, as evidenced by its route table. This route table displays the peering connection with the subnet hosting the source server, and it also includes a route specifically for the Amazon S3 VPC Gateway endpoint.

Staging area subnet route table:

Figure 4: Image of source route table with VPC peering connection for scenario 1

Verifying the endpoints for Staging area

You must create VPC Interface endpoints to enable connectivity between the staging area subnet and the regional MGN endpoint, as well as the EC2 endpoint in the ap-south-1 region. Additionally, create S3 Interface endpoint specifically for facilitating the installation of agents. Furthermore, create one S3 Gateway endpoint to allow the replication server to access the regional S3 endpoint. Consequently, a total of four VPC endpoints are created within the ap-south-1 region to fulfil the stated requirements.

VPC Endpoints in ap-south-1 region:

Figure 5: Image of VPC endpoints for connection

Figure 5: Image of VPC endpoints for connection

Checking the connectivity to VPC endpoints

After setting up the required components, you can now verify connectivity with each interface endpoint on port 443. This will allow you to verify that you can connect to the ap-south-1 regional application programming interface (API) endpoints from the ap-southeast-1 region. Since the DNS names created from VPC endpoints are publicly resolvable, you can resolve the endpoints from any location on the internet. These DNS names resolve to the private IP addresses of the endpoint network interfaces for the enabled Availability Zones (AZ).

Figure 6: Image of connectivity verification via endpoints

To establish a connection with the regional API endpoints, you can utilize the interface endpoints. Once the connection is established, you can proceed with installing the Application Migration Service replication agent. But before proceeding with installation, we need to change an additional setting under the replication template.

Within the AWS MGN console, we must modify a specific setting related to the replication configuration. Under the replication template section, we need to adjust the data routing option to ensure that the source server establishes a connection using the private IP address of the AWS MGN Replication Server, utilizing port 1500.

Figure 7(a and b): Selecting private connection for replication and open ports at source server(s) or firewall and/or gateway

To install the replication agent on the source server, you need to first download the installer using the ap-south-1 URL. The first step is to modify the URL of the installer by replacing the original .s3.region.amazonaws.com with the Amazon S3 endpoint-specific DNS name with the s3 interface endpoint that you created in previous step.

Standard command

Command to run with S3 endpoint (make sure to change the s3 interface endpoint DNS name with the one that you created earlier)

  • https://aws-application-migration-service-<region>.bucket.<your s3-interface-endpoint-DNS-name>/latest/linux/aws-replication-installer-init

for e.g. in our case below is how it looks:

What has changed

  • The standard command establishes a connection with a public IP, which requires internet access and is unavailable in our isolated environment. On the other hand, the endpoint command establishes a connection with a private IP, which is accessible due to the addition of an S3 endpoint in the VPC.

Figure 8: Image showing MGN agent download

Once you have successfully downloaded the installer file, proceed to install the replication agent. During the installation process, utilize the --endpoint parameter to specify the Application Migration Service VPC Interface endpoint. Additionally, employ the --s3-endpoint to reflect the use of the Amazon S3 VPC interface endpoint.

Figure 9: Image showing MGN agent installed

The replication agent for the Application Migration Service has been installed, marking the completion of the Amazon S3 interface endpoint’s role. As mentioned earlier, the staging area utilizes the S3 Gateway endpoint to retrieve the replication software from S3. Consequently, the replication subnet will consistently employ the Gateway endpoint for its operations.

At this step, we can see that the source server is added to the AWS MGN console.

Figure 10: Image showing replication completion

At this stage, your source server(s) are replicating and ready for testing. You can now launch a test instance for this server. The server will stay in the Ready for testing lifecycle state until you launch a Test instance for the server. Once the testing is completed, you can proceed to the cutover by following the MGN lifecycle course.

Clean up

To avoid accruing any additional charges related to the setup explained in this post, be sure to clean up your resources, including:

  • Terminate Amazon EC2 Instances, replication server(s).
  • Delete VPC interface and gateway endpoints.
  • Delete VPC peering connection and associated route tables.
  • Disconnect any MGN Source Servers created for the purpose of this post including Direct Connect or VPN connection.
  • Any EBS volumes attached to the EC2 instances associated with your testing.

Conclusion

Deploying a service agent in an internet-restricted environment, like those with stringent security measures, can be a daunting task. Most agents require an internet connection to establish a link with the service. However, we demonstrated how to install the Application Migration Service replication agent on servers operating in tightly secured environments without internet access, without compromising the security posture of your infrastructure.

We implemented this solution by leveraging VPC interface and Gateway endpoints. We demonstrated how AWS Private Link, a service for AWS services, can provision interface VPC endpoints (interface endpoints) within a Virtual Private Cloud (VPC) environment. Applications on-premises can directly access these endpoints through VPN and AWS Direct Connect, while applications in a different AWS region can access them via VPC peering. Specifically, for the Application Migration service, we utilized the AWS MGN interface endpoint, EC2 interface endpoint, Amazon S3 interface, and Gateway endpoints to access the service privately through Private Link. These endpoints help secure the workload and facilitate seamless application migration using the Application Migration Service.

About the authors: