In the ever-evolving IT landscape, the decision to migrate workloads to the cloud is often a strategic one. It is driven by factors like cost efficiency, scalability, and performance optimization. Among the well-known 7Rs of migration strategies, rehosting, also known as a lift-and-shift migration, stands out as a straightforward yet powerful option. In this article, we will look into the intricacies of rehosting workloads to the cloud with the help of AWS Application Migration Service (AWS MGN).
Rehost migration involves lifting existing workloads and moving them to the cloud without modifying their architecture or application code. In simple terms, it is a like-for-like kind of migration with potential right-sizing along the way. This strategy offers a rapid transition, minimizing downtime and reducing the complexity associated with migrating to the cloud. By replicating the existing environment in the cloud infrastructure, rehost migration ensures continuity in operations while gaining access to the scalability and flexibility of cloud resources.
It is important to note that despite its benefits, in most cases, rehosting should be just a first step in the migration process. Although it paves the way for the creation of the Landing Zone, Infrastructure as Code templates, security and compliance guardrails, it is rarely an optimal way of running workloads in the Cloud. Applications should be further reviewed once they are lifted and shifted to the new environment to evaluate possible advantages of cloud-native solutions that can save even more money and require even less administrative overhead.
Now let us look closely at the AWS Application Migration Service (AWS MGN), which is currently a recommended lift-and-shirt solution that works with physical and virtual servers as its sources. It helps companies rehost workloads without compatibility issues, reducing error-prone manual processes, costs, and downtime. AWS MGN allows to migrate the applications and databases easily if they operate on compatible versions of Windows and Linux operating systems. With its agent-based approach, AWS MGN offers an automated block-level replication that provides ongoing data replication and shortens the cutover window. There is also an agentless snapshot replication possibility. However, this option is only available for the vCenter source environment. The latter approach entails a longer cutover window and is only recommended if the constraints in the environment prevent the company from installing the agent on each server.
For those who have been rehosting workloads to the AWS cloud before but have not yet heard of AWS MGN, this service is based on the CloudEndure solution, which was enhanced and reengineered after AWS acquired CloudEndure company in 2019. This technology is now a part of the console. It is a cloud-native solution that is easily integrated with other AWS services (like IAM, Migration Hub, SSM, etc). With many new features, it became a de facto standard for rehosting to AWS. Since AWS MGN came into the picture the AWS Server Migration Service (SMS) that served a similar purpose has been deprecated.
AWS MGN operates by replicating source servers into the staging area of the AWS account. The staging area is an environment (vpc/subnet) where AWS MGN creates replication instances that replicate the source servers with attached disks of your choice. After verifying that replication is completed successfully and that the initial snapshots are created, AWS MGN allows you to automatically launch test instances and examine them thoroughly. Once this is done, AWS Application Migration Service helps to provision the ‘cutover’ instances in the production area (production vpc/subnet) of the AWS environment. This allows you to quickly benefit from the cost savings, productivity, resilience, and agility of the cloud. The cutover window is typically measured in minutes. Once the applications are running on AWS, clients can leverage seamless integration with other AWS services to further re-platform or refactor them making lift-and-shift a fast route to modernization. AWS Application Migration Service is a simple and proven method to conduct non-disruptive tests before the cutover. An important aspect for MGN to work and drive value is sufficient network connectivity.
In my next article, I will demonstrate a step-by-step walkthrough on migrating VMs to AWS using AWS MGN. As an example, I will move a VM from Azure to AWS. The same approach can be used for other clouds and virtualization platforms like VMWare and Hyper-V.
AWS MGN and AWS DRS
AWS MGN and AWS Elastic Disaster Recovery Service (AWS DRS) share the same underlying technology for performing block-level replication. These services have different features but they share the same approach. AWS Elastic Disaster Recovery is the next-generation DR solution built on top of the CloudEndure DR solution with added features. Both MGN and DRS use a replication agent that replicates servers into a staging area in AWS. MGN helps to launch test instances to verify the replication and cutover instances to finalize the migration. DRS launches test and recovery instances from the staging area to perform the DR drills and recover servers in case of unexpected unavailability of the source servers. DRS can also help to fail back to the source server after it is recovered. An important thing to note is that DRS and MGN replication agents cannot be installed on the same server simultaneously. One needs to be uninstalled for another to be installed.
Pricing
AWS MGN is a complimentary service and is free for 90 days per server. This period starts when the MGN replication agent is installed on the source server and continues during active source server replication. With AWS DRS, by the way, you pay a flat per-hour fee for continuous data replication, as well as for test launches, recovery launches, and point-in-time recovery.
Global View
AWS MGN has a global view feature that benefits large-scale migrations across multiple accounts. It provides visibility and enables the management account or the delegated admin account for AWS Application Migration Service to perform specific actions on source servers, apps, and waves in different AWS accounts.
Post-launch Actions
AWS MGN offers post-launch actions with the ability to use AWS pre-defined and create custom post-launch templates. The predefined templates help to, for example: install software (like AWS SSM, Cloudwatch, and DRS agents), create AMIs from the source servers to be further distributed across accounts and regions, configure Linux time sync service, and convert Windows MS-SQL licenses (from MS-SQL BYOL to AWS License). These and many other pre-created initial setup options available through post-launch templates save time and enable migrated servers to use automation and avoid manual processes during re-configuration needed after migration.
On the other hand, with custom templates, clients can create the sets of actions needed for their specific use cases. It is done with the help of System Manager (SSM) documents which use JSON or YAML format to specify the steps needed to configure servers properly. While using SSM documents with AWS MGN post-launch actions enables the creation of per-case user-specific customizations, this also opens the door to more than 100 pre-configured SSM documents. Here is a recent article from AWS showing how this feature can be utilized to clean up VMWare Tools from Windows and Linux servers.
Cost Savings Programs
AWS MGN’s customers are eligible for multiple cost-saving programs like AWS Windows Migration Accelerator (AWS WMA) and AWS VMware Migration Accelerator (VMA) programs. The AWS WMA helps to reduce the migration cost of the Windows servers. It is worth noting that only servers migrated with Application Migration Service are counted towards this program. The AWS VMA provides customers with credits when migrating VMware Cloud on AWS workloads to Amazon EC2. While these credits can be accumulated with MGN, workloads qualify for VMA benefits irrespective of the migration tool used.
AWS MGN Connector
AWS MGN Connector is a great feature that AWS MGN offers to simplify the installation of replication agents in the data center environment. It helps to check the prerequisites and verify that the replication software can be installed. It installs the agent on the source servers. And lastly, it can perform other actions on the source servers in bulk. Together with the Post-launch actions, the AWS MGN connector offers a full cycle of automation within the migration process. The MGN connector needs to be installed on a dedicated Linux server. It can be the same server where the MGN vCenter agentless appliance is deployed.
VM Import/Export
This option is viable for cold migrations of non-mission-critical workloads because, unlike the AWS MGN service, the VM Import option entails a much longer cutover window. It cannot be used for applications with strict availability SLAs because this approach entails a server shutdown, hence the cold migration.
The way it works is that the VM snapshot is taken while the server is powered off. As a result, the OVA file is created. This file is then uploaded to S3 via AWS Management Console or AWS CLI. The clients using the VMware vSphere virtualization platform can also use the AWS Management Portal for vCenter, which provides an easy-to-use UI allowing to import virtual machines to AWS. The time it takes for the OVA file to upload to S3 depends on the file size and the network bandwidth. After the S3 upload, the VM snapshot is imported as an EC2 AMI which can then be launched as an EC2 instance. VM Import/Export feature is available for free and customers only pay for the S3 and EBS storage while it is used.
When comparing this method to AWS MGN’s live-migration strategy it is noticeable that the cutover window is close to zero with the Application Migration Service, while it can take a substantial amount of time with VM import/export approach eliminating this option for any Tier 1 applications. There are, however, some situations where VM import can save the day, like, for example when the server does not meet the MGN’s agent installation requirements or the systems that need to be migrated are not supported by the replication agent. It is important to note that VM Import/Export service has its own limitations like the fact that VMs that are created as the result of a physical-to-virtual (P2V) conversion are not supported.
AWS Snow Family
While services mentioned earlier offer online data transfer, AWS also offers offline data transfer options represented by the AWS Snow Family. Right now there are two offerings in the space of data transfer appliances. The first one is an AWS Snowcone with up to 14TB on a single device and both HDD and SSD-based options. The second one is an AWS Snowball with up to 210 TB on a single appliance. It comes in two flavors, namely: Snowball Edge Compute Optimized and AWS Snowball Edge Storage Optimized with different device configurations available.
Until March 2024, there was a third option called SnowMobile which was a truck able to store up to 100 PB of data.
With the Snow Family, the data is loaded onto one of the devices that works best for the workload in question and it is then physically shipped to AWS where it is subsequently restored. The Snow Family appliances are usually used by enterprises that have substantial amounts of data to migrate and lack sufficient bandwidth. Besides other features and use cases like running edge computing applications, they offer fast, and inexpensive one-time data transfer into AWS. Clients use AWS Snow Family appliances to migrate large quantities of data into AWS without worrying about network bandwidth and its cost making this approach considerably less expensive than upgrading infrastructure. They are perfectly suitable to move data that is not frequently changed. Oftentimes, customers utilize Snow Family devices as an offline method to capture static data, and then use other online data transfer methods like MGN or DataSync for incremental changes like SQL Server metadata changes.
When it comes to migrating VMs to the cloud, AWS Snow Family currently supports importing snapshots with sizes from 1 GB to 1 TB with the help of the VM Import/Export tool described earlier. Once the snapshot is uploaded to the device using S3-compatible storage it can then be registered as an EC2 AMI.
AWS estimates the end-to-end time to transfer up to 80 TB of data into AWS with Snowball Edge to be approximately one week. When deciding which data transfer method to use, clients need to answer the question of how much data would be changed during that time, because the changed data will then need to be uploaded via some online data transfer service. If there are not too many changes since the initial load to the Snow Family device, using the offline data transfer would be beneficial. Although this two-part migration introduces additional administrative overhead, it may be the only option when migrating workloads that have hundreds of terabytes of data (like SQL Server databases). When using AWS MGN, a significant amount of network bandwidth is needed whereas sometimes companies cannot provide enough to meet the networking requirements.
In contrast to AWS VM Import/Export service, which works with disk images only up to 16 TiB, AWS Snowball Edge offers much higher data capacity, with various configurations allowing up to 210 TB of data transfer on a single device.
This service is used for bulk migrations. It makes sense to use it when cold migrations are acceptable or when the data change rate is low whereas the amount of data is huge.
AWS DRS
Elastic Disaster Recovery service has been mentioned earlier and it is the recommended service for disaster recovery to AWS. For those familiar with it, AWS DRS provides similar capabilities as CloudEndure Disaster Recovery. Although it can be used to migrate servers to AWS, it has a different purpose and MGN needs to be used instead since it offers a robust feature set that makes the migration easier (like MGN connector or post-launch actions). Unlike MGN, AWS DRS does not support agentless replication and is not free of cost. Bottom line, it is possible to migrate servers with DRS but it is better to use the right tool to do the right job.
All this time we have been looking at rehosting to AWS with its proprietary tool AWS MGN. It is worth noting that each public cloud provider offers their own server migration services and tools. GCP, for example, has a service called Migrate for Compute Engine which also allows testing the workloads before the cutover and helps with the VMs right-sizing. It works with such sources as Amazon EC2 instances, VMware, and Microsoft Azure VMs.
Microsoft Azure, on the other hand, has a service called Azure Migrate with its Server Migration functionality that comparably to GCP’s and AWS’s alternatives provides the possibility to test VMs before finalizing the migration and offers a similar feature set as well as block-level replication with its Mobility Service Agent.
Offline data transfers are also available in the toolboxes of other public cloud providers. GCP offers storage devices called Transfer Appliances with different weights and capacities enabling secure transfers to GCP locations. Similarly, Azure offers offline data transfer devices called Data Box, Data Box Disk, and Data Box Heavy representing different appliance sizes and configurations. They are a good choice when clients need to quickly move large amounts of data to Azure or GCP but the networks are too busy to satisfy this requirement.
All of these services are easy to get a grasp on and use. Some of them are better suited for large-scale migrations that require complex orchestration and automation, some offer better speed of replication and provisioning, and some have a better-developed ecosystem of supporting services that help with the overall migration process. Ultimately, the choice between them depends on the target destination for the compute resources.
The Application Migration Service stands as the evolution from CloudEndure Migration, presenting new features and operational advantages that were absent in the earlier CloudEndure Migration solution. As your organization embarks on its cloud journey, MGN is a powerful ally, paving the way for a successful and efficient transition to the AWS ecosystem. Utilizing the AWS MGN, enables you to migrate applications from physical infrastructure, VMware vSphere, Microsoft Hyper-V, Amazon EC2, and other cloud environments to AWS. AWS MGN enables companies to lift and shift physical, virtual, or cloud servers without compatibility issues, performance disruption, or long cutover windows. For many reasons mentioned above, it is currently the AWS recommended service for seamlessly migrating your applications to the AWS cloud.
If your organization is considering the move to the cloud and needs some guidance on this, feel free to contact us. Ippon is a trusted migration partner who is here to help you! To learn more about cloud migrations, read our latest eBook Assessing the Maturity of your Cloud Strategy, or check out our Cloud Migration On-Demand Webinar Series, where we discuss how to prepare an organization for a seamless transition to the cloud.