Experiences of Rehosting on-prem Customer Workloads Using AWS Application Migration Service (AWS MGN)

Customer Scenario*

Cyberdyne Systems, is a global robotics retailer with operations in 40 countries. Following a number of high-profile outages in 2020, the CIO and board decided to pursue a cloud-first strategy and to migrate existing workloads to AWS cloud. As of now, notice has been tendered to ten co-lo datacentres with an anticipated end date of December 31st, 2022.

Cyberdyne Systems enlisted the help of AWS Partner, Daemon to migrate its key business applications to AWS cloud using the framework of AWS’s Migration Application Programme (MAP) which includes three key phases:

1. Assess
2. Mobilize
3. Migrate & Modernize

The focus of this article is on the Application migration workstream of the Mobilize phase highlighted below, wherein migration teams build a foundation for successful migrations by migrating a small set of business applications to the cloud.

*Fictional company names are used where permission for a public case study could not be obtained

Figure 1: Phase 2 (Mobilize) highlighted in a customer’s migration journey

Applications Identified for Rehosting (Lift and Shift) during Mobilize

The Cyberdyne Systems migration team have identified the following six applications for migration using the Rehosting or Lift and Shift method:

• MyHR HRIS System: bespoke HRIS system developed in-house
• PraiseYou:  bespoke employee appraisal platform
• TechDocs: internal WIKI (based on MediaWiki) for technical documentation
• GitLab: self-hosted GitLab VCS for SWE teams
• cyberdynesystems.io website: uses WordPress
• Event Planner: custom event planning application built using FileMaker Pro

AWS Application Migration Service (MGN)

Some of the applications identified above including GitLab use a database backend such as PostgreSQL. While this is a great opportunity to consider Replatforming these to a service such as Amazon RDS for PostreSQL, there is no current appetite for this. Instead all servers and their backend databases will be migrated using the MGN service as illustrated below.

Figure 2: MGN is the recommended tool for Lift and Shift migrations

https://aws.amazon.com/blogs/architecture/accelerating-your-migration-to-aws/

At a high-level, MGN uses block-level continuous replication to migrate all data held on on-premises servers to replication volumes attached to Replication instances in a Staging Area in AWS. Once the source and destination volumes are fully synchronised, a cutover process is invoked which results in an appropriate-sized EC2 instance being launched with the replication volume data. This is further illustrated below:

Figure 3: MGN Service and Network Architecture

Service architecture and network architecture overview - Application Migration Service

Migration Steps using MGN

1. AWS Replication Agent installed on source on-prem server
2. Source servers added to the Application Migration Service console
3. Replication commences
4. When replication completes, launch a test instance and SSH or RDP to the instance to carry out functional tests, including connectivity and acceptance tests.
5. Once satisfied with the test instance, mark as ‘Ready for cutover’
6. Launch the cutover instance and finalise cutover upon successful launch

This is illustrated below:

Figure 4: https://aws.amazon.com/application-migration-service/

Operating System Considerations

While attempting to install the AWS Migration Agent on the PraiseYou server, the migration team realised that Windows 2003 is no longer supported. This can be common with large scale migrations to cloud where a lot of legacy applications are hosted on non-supported operating systems. A current list of supported operations systems can be found here: Supported operating systems - Application Migration Service

Figure 5: Windows 2003 and other legacy operating systems are not supported

Networking Considerations

Replication traffic to AWS

MGN uses TCP port 1500 to replicate the blocks from the source server via the AWS Replication Agent to AWS. The on-premises Network/Security teams must ensure that appropriate firewall ACLs are created to allow replication traffic to reach the AWS replication servers.

Prepare Subnets and Security Groups for Launch

Test and Cutover instance subnets must be defined to ensure successful launches. Furthermore, security groups should also be created and available for inclusion in the EC2 Launch template to ensure that the launch succeeds.

Figure 6: Security Group rules need to be defined to ensure the continued secure operation of migrated workloads

Source: https://aws.amazon.com/blogs/aws/new-descriptions-for-security-group-rules/

It is the customer’s responsibility to identify the exact security group rules that need to be defined. AWS does not provide tooling for firewall rules/security group rules discovery.

Cyberdyne Systems' migration team had to spend an additional two weeks to gain a definitive understanding of the least privileges security group rules required for MyHR and PraiseYou applications. Unfortunately, these legacy applications were not maintained well and had missing documentation, especially around security. Daemon assisted Cyberdyne Systems in the security group discovery exercise by analysing VPC Flow Logs.

Figure 7: Analysing VPC flow logs by ingesting them to the OpenSearch service and displaying using Kibana.

Closing Thoughts

In an ideal world, rehosting or lift and shift would not be used as a cloud migration approach as it does not leverage the agility and elasticity of cloud services and can often be more expensive than hosting on-premises. However, as Daemon consultants, we are especially pragmatic with our customers and understand the Bigger Picture and the motivations and constraints that drive their decisions. To this end, we look for the best processes and technologies to help them migrate the workloads to cloud.

However, all migrations require wider buy-in from diverse customer teams and as I’ve highlighted above, failure to consider things such as support for operating systems and network requirements may unnecessarily stall or delay a migration.

Further Reading