Application Migration to AWS with MGN
A lift-and-shift rehost of a running Linux web server, using AWS Application Migration Service.
- AWS MGN
- Amazon EC2
- Amazon EBS
- Amazon VPC
- IAM
- Systems Manager
- Amazon CloudWatch
- Amazon RDS
I migrated a running Ubuntu 18.04 web server (2 vCPU, 1.9 GiB RAM, two disks) from a simulated on-prem environment into AWS with no changes to the source and minimal downtime. An agent on the source server replicates every attached disk at block level to a staging subnet in AWS, so a test launch or cutover never touches the live server — MGN just snapshots the already-synced data and boots an instance from it.
MGN sizes the target instance from CPU and RAM alone — it can only recommend C-family instances, so for this small server it recommended a c5.large. I overrode that with t3.micro, the size this workload actually needed. I ran a full test launch first, which passed 3/3 status checks and every post-launch action, then cut over to production — under 25 minutes from validated test to live instance.
Architecture
What I did
- Initialized MGN, pointed replication at a dedicated staging subnet, and installed the Replication Agent over Systems Manager — no inbound SSH port needed on the source
- Built an EC2 launch template defining the target's instance type, subnet, a HTTP-only security group, and IAM instance profile, with a post-launch action that installs the CloudWatch agent from a config in SSM Parameter Store
- Ran a test launch while the source kept replicating, confirmed 3/3 status checks and all post-launch actions succeeded, then marked it ready for cutover
- Cut over to production, then fixed the one real issue a rehost surfaces: the app was still pointed at the old database, so I repointed it to the RDS endpoint and opened MySQL from the web server's security group by reference, not by IP
- Finalized the cutover — replication disconnected, source no longer needed, migration complete
Applying this in production
- Size from real utilization data (AWS Transform), not the specs-only recommendation MGN gives you
- Map every downstream dependency before cutover day, not after
- Harden further: temporary credentials via IAM Roles Anywhere instead of long-lived keys, a private instance behind an ALB with HTTPS instead of open HTTP, and an Auto Scaling group across multiple AZs instead of a single instance