Table of contents
AWS MGN (AWS Application Migration Service) is a highly automated lift-and-shift (rehost) solution:
• Simplifies, expedites, and reduces the cost of migrating applications to AWS
• Enables lift-and-shift migration from any source infrastructure with minimal business disruption.
AWS MGN utilizes continuous, block-level replication and enables short cutover windows measured in minutes.
AWS MGN (AWS Application Migration Service) is based on CloudEndure Migration and improves on it by integrating with the AWS Management Console. (Note: CloudEndure Migration will be no longer be available for use in most AWS Regions as of December 30, 2022. It will continue to be available for migrations into GovCloud and China Regions through 2023).
AWS recommends AWS MGN as the primary migration service for lift-and-shift migrations. If AWS MGN is unavailable in a specific AWS Region, we can use the AWS SMS APIs through March 2023. AWS SMS (AWS Server Migration Service) utilizes incremental, snapshot-based replication and enables cutover windows measured in hours.
With AWS MGN, we can migrate our applications from physical infrastructure, VMware vSphere, Microsoft Hyper-V, Amazon Elastic Compute Cloud (Amazon EC2), Amazon Virtual Private Cloud (Amazon VPC), and other clouds to AWS.
AWS MGN Benefits
• Minimal downtime during migration • Reduced costs • Automated modernization
Initializing Application Migration Service
In order to use Application Migration Service, the service must first be initialized for any AWS Region in which we plan to use Application Migration Service.
Application Migration Service must be initialized upon first use from within the Application Migration Service Console. The initialization process occurs automatically once a user accesses the Application Migration Service Console. The user is directed to create the Replication Settings template, and upon saving the template, the service is initialized by creating the IAM Roles which are required for the service to work.
Application Migration Service can only be initialized by the Admin user of our AWS Account.
During initialization the following IAM roles will be created:
You can create roles with granular permission for Application Migration Service. The service comes with the following pre-defined managed IAM policies:
• AWSApplicationMigrationFullAccess - This policy provides permissions to all public APIs of AWS Application Migration Service (MGN), as well as permissions to read KMS key information.
• AWSApplicationMigrationEC2Access - This policy allows Amazon EC2 operations required to use Application Migration Service (MGN) to launch the migrated servers as EC2 instances.
• AWSApplicationMigrationReadOnlyAccess - The Read-Only policy allows the user to view all data available in the Application Migration Service Console but does not allow them to modify any data or perform any actions. This policy also includes several EC2 read-only permissions.
• AWSApplicationMigrationAgentPolicy - This policy allows a user to install the AWS Replication Agent.
• AWSApplicationMigrationAgentInstallationPolicy - This policy allows a user to install the AWS Replication Agent.
we must attach the AWSApplicationMigrationFullAccess and the AWSApplicationMigrationEC2Access policies to our IAM users and roles in order to be able to launch Test and Cutover instances and to complete a full migration cycle with Application Migration Service.
Accessing the Application Migration Service Console
We can access Application Migration Service through the AWS Console:
Application Migration Service is AWS Region-specific. We have to select the correct Region from the Select a Region menu when using Application Migration Service.
AWS MGN Lifecycle
Implementation begins by installing the AWS Replication Agent on your source servers. Once it’s installed, you can view and define replication settings. AWS Application Migration Service (AWS MGN) uses these settings to create and manage a Staging Area Subnet with lightweight Amazon EC2 instances that act as Replication Servers and low-cost staging Amazon EBS volumes. (Note: If we cannot install agents on our servers, we can use the agentless replication option)
Replication Servers receive data from the agent running on our source servers and write this data to the staging Amazon EBS volumes. our replicated data is compressed and encrypted in transit, and can be encrypted at rest using EBS encryption. AWS Application Migration Service keeps our source servers up to date on AWS using continuous, block-level data replication. It uses our defined launch settings to launch instances when we conduct non-disruptive tests or perform a cutover.
Testing and Cutover
When we launch Test or Cutover instances, AWS Application Migration Service automatically converts our source servers to boot and run natively on AWS. After confirming that our launched instances are operating properly on AWS, we can decommission our source servers. We can choose to modernize our migrated applications by leveraging AWS Application Migration Service and additional AWS services.
• Plan your Migration project prior to installing the AWS Replication Agent on your source servers.
• Do not perform any reboots on the source servers prior to a Cutover.
• Do not archive or disconnect the source server from AWS until your launched Cutover instance in AWS is working as expected.
• Perform Test at least two weeks before you plan to migrate your Source servers. This time frame is intended for identifying potential problems and solving them, before the actual Cutover takes place. After performing the test launch, validate connectivity to your Test instances (using SSH for Linux or RDP for Windows), and perform acceptance tests for your application.
• Ensure that you perform a Test prior to performing a Cutover.
The following are the required steps to complete a successful migration implementation with Application Migration Service:
• Deploy the AWS Replication Agent on your source servers.
• Confirm that the data replication status is Healthy.
• Test the launch of Test instances a week before the actual Cutover.
• Address any issues that come up, such as Launch setting misconfiguration and potential AWS limits.
• Launch Cutover instances for the servers on the planned date.
Best Practices for Ensuring Project Success
• Train a field technical team & assign a Application Migration Service SME. • Share project timelines with Application Migration Service. • Monitor data replication progress and report any issues in advance. • Perform a test for every server in advance, and report issues to Application Migration Service. • Coordinate Cutover windows with Application Migration Service in advance.
The general process is:
• Install the AWS Replication Agent on the source server. (If we are using the agentless replication for vCenter feature, then e will need to add our source servers by installing the AWS MGN vCenter Client)
• Wait until Initial Sync is finished.
• Launch Test instances.
• Perform acceptance tests on the servers. After the Test instance is tested successfully, finalize the Test and delete the Test instance.
• Wait for the Cutover window.
• Confirm that there is no Lag.
• Stop all operational services on the source server.
• Launch a Cutover instance.
• Confirm that the Cutover instance was launched successfully and then finalize the Cutover.
• Archive the source server.
AWS MGN Pricing
For each source server that we want to migrate, we can use AWS Application Migration Service for a free period of 2,160 hours, which is 90 days when used continuously.
The free period starts as soon as we install the AWS Replication Agent on our source server and continues during active source server replication.
If we do not complete our migration of a specific server within the free period, we will be charged per hour while we continue replicating that server.
While our source servers are actively replicating, including during the free period, we will incur charges for any AWS infrastructure that is provisioned by AWS Application Migration Service to facilitate data replication.
We will also incur charges for resources that are provisioned when we launch test or cutover instances, such as compute (Amazon EC2) and storage (Amazon EBS) resources, according to our AWS pricing plan.
AWS Application Migration Service pricing is the same for all supported AWS Regions.
Supported AWS Regions
The following AWS Regions are supported by Application Migration Service:
AWS Application Migration Service is not yet supported in AWS GovCloud and China Regions, and does not currently support some legacy operating systems that are supported by CloudEndure Migration. Consider using CloudEndure Migration if our preferred AWS Region or operating system is not currently supported by AWS Application Migration Service.
Note: While CloudEndure Migration will continue to be available for use in AWS GovCloud and China Regions, it will no longer be available in other AWS Regions as of December 30, 2022. After January 1, 2023, CloudEndure Migration will be available only for migrations to AWS Outposts and AWS GovCloud and China Regions.
CloudEndure Migration EOL
Important dates to plan for:
June 30, 2022 - No new CloudEndure Migration licenses will be allocated, but we can continue using existing licenses.
September 30, 2022 - No new CloudEndure Migration agents can be installed, but we can complete migrations in progress, using the agents already installed
December 30, 2022 - Existing CloudEndure Migration licenses will expire, and the service will no longer be available
(Note: These dates are excluding for the GovCloud and China Regions. The CloudEndure Migration service will continue to be available for migrations into GovCloud and China Regions, at this time.)
Supported operating systems - docs.aws.amazon.com/mgn/latest/ug/Supported..
CloudEndure Migration EOL - docs.cloudendure.com/#Configuring_and_Runni..
Hope you got some valuable information.
Community and Social Footprints:
Happy Learning 📚
Did you find this article valuable?
Support Cloudnloud Tech Community by becoming a sponsor. Any amount is appreciated!