AWS Migration & Transfer
Application Migration Service
Lift-and-shift physical, virtual, and cloud servers to AWS automatically
AWS Application Migration Service (MGN) automates lift-and-shift migrations of physical servers, virtual machines, and cloud instances to AWS by continuously replicating block-level data using a lightweight agent. It replaces the older CloudEndure Migration service and is the recommended path for rehosting workloads without modification. For cloud engineers, MGN dramatically reduces the risk of server migrations by allowing unlimited test launches before cutover.
How MGN Replicates Servers
MGN installs a replication agent on each source server. The agent continuously replicates block-level changes to a staging area in your AWS account. When you are ready to cut over, MGN converts the replicated data to a native EC2 instance.
| Stage | What Happens | Impact on Source |
|---|---|---|
| Initial Sync | Full disk snapshot replicated to staging EBS volumes in AWS | CPU and I/O spike during initial sync (typically 1-4 hours) |
| Continuous Replication | Block-level changes streamed via TCP 1500 to AWS replication servers | Minimal - agent uses ~1% CPU at steady state |
| Test Launch | MGN boots a test EC2 instance from replicated data - source keeps running | None - source is untouched |
| Cutover | Stop source workload, final sync, MGN converts and launches production EC2 | Source goes offline |
You can perform unlimited test launches before committing to cutover. Test launches spin up in minutes and are billed as normal EC2. Use this to validate application compatibility, networking, and performance before your maintenance window.
Agent Installation and Source Server Requirements
The MGN agent runs on Linux and Windows. It requires outbound TCP 443 and TCP 1500 to AWS replication endpoints.
# Linux agent installation
wget -O ./aws-replication-installer-init.py \
https://aws-application-migration-service-us-east-1.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py
python3 aws-replication-installer-init.py \
--region us-east-1 \
--aws-access-key-id AKIAIOSFODNN7EXAMPLE \
--aws-secret-access-key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY| OS Support | Notes |
|---|---|
| Linux (RHEL, CentOS, Ubuntu, SUSE, Amazon Linux) | Kernel 2.6.32+ required |
| Windows Server 2003 - 2022 | PowerShell 3.0+ required |
| AIX, HP-UX, Solaris | Not supported - use Storage Gateway or manual migration |
The IAM user or role used during agent installation only needs AWSApplicationMigrationAgentPolicy. Do not use admin credentials on source servers. Rotate these credentials after all agents are installed.
EC2 Launch Template Configuration
Before test launch or cutover, configure the EC2 launch template for each source server. This defines how MGN will convert the replicated disk into an EC2 instance.
| Setting | Guidance |
|---|---|
| Instance type | Match or right-size from source specs. Use Compute Optimizer recommendations after first test launch. |
| Subnet | Choose a private subnet. Never launch migrated servers directly into a public subnet. |
| Security groups | Pre-create SGs matching source firewall rules. MGN does not migrate firewall rules automatically. |
| EBS volume type | gp3 for most workloads. io2 for databases requiring sustained high IOPS. |
| IAM instance profile | Assign SSM agent role so you can connect without bastion hosts after cutover. |
MGN's post-launch actions let you run SSM documents or scripts automatically after each test launch or cutover. Use this to join the instance to your domain, configure monitoring agents, or run smoke tests automatically.
Test Launch vs Cutover: The Migration Workflow
The recommended workflow separates testing from the actual cutover to minimize risk. Never skip test launches - they catch OS-level incompatibilities that only appear when the workload boots on EC2.
| Step | Action | Outcome |
|---|---|---|
| 1 | Install agents on all source servers | Servers appear in MGN console as "Not ready" |
| 2 | Wait for initial sync to complete | Status changes to "Ready for testing" |
| 3 | Configure launch templates | Instance type, networking, storage defined |
| 4 | Launch test instance | EC2 instance boots from replicated data alongside source |
| 5 | Validate application, networking, performance | Sign off before scheduling cutover window |
| 6 | Mark as "Ready for cutover" | Finalizes configuration, disables further changes |
| 7 | Stop source workload, initiate cutover | Final delta sync (seconds to minutes), EC2 launched |
| 8 | Finalize migration | Cleans up staging resources, stops billing for replication |
If you finalize the migration without disabling the agent on the source first, you may accidentally trigger replication in reverse. Always uninstall the MGN agent from source servers after a successful cutover.
MGN Pricing and Cost Optimization
MGN has no per-server licensing fee from AWS. You pay only for the staging area resources used during replication.
| Cost Component | Detail |
|---|---|
| MGN service fee | Free for the first 90 days per source server |
| After 90 days | $0.042/hr per source server actively replicating |
| Staging area storage | EBS volumes at standard gp3 rates (~$0.08/GB/month) |
| Staging EC2 instances | One t3.small replication server per source region (~$0.021/hr) |
| Data transfer in | Free - ingress to AWS is not charged |
Finalize migrations promptly after cutover. Every day a source server stays in "Replicated" state beyond 90 days costs money. Automate finalization with EventBridge rules that trigger after a successful cutover.
Interview Focus Points
- 1What is the difference between AWS MGN and AWS SMS (Server Migration Service)?
- 2How does block-level replication differ from snapshot-based migration and why does it matter for RPO/RTO?
- 3Walk me through the complete MGN migration workflow from agent installation to cutover finalization.
- 4How do you minimize downtime during MGN cutover for a database server?
- 5What networking requirements must be met for the MGN replication agent to reach AWS?
- 6How would you migrate 200 servers to AWS in 60 days using MGN? What is your sequencing approach?
- 7What are MGN post-launch actions and how would you use them to automate post-migration configuration?
- 8How do you handle applications that span multiple servers (app tier + database tier) during cutover?