AWS Application Migration Service - Part 1
AWS Application Migration Service (MGN) provides automated lift-and-shift migration to AWS. Install the replication agent on source servers, data continuously replicates to a staging area, then launch test/cutover instances when ready. The service handles driver conversion and OS compatibility automatically.
Introduction
AWS MGN is a highly automated, adaptable, and dependable lift and shift system. Anyone can utilize the AWS Application Migration Service (AWS MGN), a lift-and-shift AWS service, using the AWS Management Console. In this post, I will explain the AWS MGN service and network architecture.
AWS MGN can assist with streamlining, accelerating, and lowering the cost of application migration to AWS. It can be used to move physical, virtual, or cloud services to AWS without affecting performance, causing a disturbance, or requiring a lengthy cutover period. Any source infrastructure that utilizes a supported operating system can be used to migrate apps and databases - including widely used databases like Oracle and SQL Server, critical programs like SAP, and in-house developed programs.
Network Requirements
Before starting migration, ensure your network meets all connectivity requirements. Missing firewall rules are the most common cause of replication failures.
Source Servers to AWS MGN API (Port 443)
Allow communication on port 443 between the AWS MGN endpoint and source servers. This HTTPS connection is used for monitoring, configuration, and authentication. Required during agent installation and throughout replication. Can be routed through a web proxy.
Source Servers to Staging Subnet (Port 1500)
Data is sent over port 1500 directly from source servers to replication servers. This connection must remain open for continuous data replication.
Staging Subnet to AWS Services (Port 443)
Replication and conversion servers need connectivity to:
- AWS MGN endpoints for authentication and monitoring
- S3 for configuration and software downloads
- EC2 API endpoint for EBS snapshot operations
Architecture - Phase 1
Task 1 - Agent Installation (Pregame)
Installing the AWS replication agent on your source servers is the first step. The agent can be obtained from the MGN console and installed via scripts without intervention or reboot.
The root drive needs 2 GB of free space for post-replication launch. If you modify source volumes/drives after initial sync, replication must rescan ALL volumes - not just the modified one.
What Happens After Agent Installation
- Agent initiates TLS-encrypted authentication handshake with AWS MGN API
- Agent registers with the service
- Service provisions staging area subnet resources automatically
Staging Area Resources
- Replication Servers - Lightweight T3.small EC2 instances (one server supports up to 15 disks)
- Staging Volumes - Low-cost EBS volumes matching source disk sizes
- EBS Snapshots - Incremental snapshots for point-in-time recovery
Replication Process
Data is encrypted with AES 256-bit encryption and compressed during transit. Replication occurs in two phases:
- Initial sync - Copies all data from source disks to staging EBS volumes
- Continuous replication - Asynchronously replicates data writes as they happen
You control how replication happens - over public internet, Site-to-Site VPN, or Direct Connect. Choose based on your bandwidth requirements and security policies.
Task 2 - Launch Configuration
Review launch settings once agent installation and replication begins. Launch configurations determine where and how migrated instances are created:
- Subnet and security groups
- Instance type
- Volume type
- Tags
Launch Process
When you initiate a test or cutover:
- AWS MGN spins up a conversion server
- Conversion modifies drivers, network, and OS license for AWS compatibility
- Conversion server terminates after completion
- New instance launches and is ready for use
Important Launch Behavior
- Launched volumes are NOT kept in sync with source servers after launch
- Replication continues to staging area volumes
- Each new test/cutover instance reflects the latest replicated state
- Previous instances are automatically cleaned up when new ones are launched
Troubleshooting
- Agent fails to connect - Verify outbound port 443 to AWS MGN endpoints and S3. Check if a proxy is required and configured.
- Replication stuck or slow - Check network bandwidth between source and staging subnet on port 1500. Consider using Direct Connect or VPN for better throughput.
- "Stalled" status on source server - Agent lost connectivity. Verify network, restart agent service, check ports 443/1500.
- Conversion fails - Ensure 2 GB free space on root drive. Check staging subnet has connectivity to EC2 and S3 endpoints.
- Instance launches but won't boot - Review launch template settings. Check instance type compatibility. Verify security groups allow necessary traffic.
- Full resync triggered unexpectedly - Volume modifications on source require full rescan. Plan disk changes carefully during active replication.
Conclusion
AWS Application Migration Service (MGN) is a fully automated lift-and-shift (rehost) service that makes moving applications to AWS easier, faster, and less expensive. It allows businesses to move physical, virtual, or cloud servers quickly without compatibility issues, performance problems, or lengthy cutover windows.
Your AWS account receives source server replication from MGN. It automatically converts and runs your servers on AWS when you're ready, allowing you to reap the cost savings, productivity gains, resilience, and agility of the Cloud right away. Lift-and-shift is a speedy path to modernization because once your applications are running on AWS, you can use AWS services to replatform or refactor those applications.