AWS Services
AWS Application Migration Service
Understand AWS Application Migration Service for lift-and-shift server migration, including source servers, replication agents, staging area resources, launch settings, testing, cutover, security, cost, and SAA-C03 traps.
After this, you will understand
Application Migration Service helps learners distinguish server rehosting from database migration, file transfer, and application refactoring.
AWS Application Migration Service continuously replicates source servers to AWS and launches them as EC2 instances for test and cutover.
Learners choose DMS for whole-server migration or assume MGN modernizes the application instead of rehosting it first.
Use MGN when the business needs a low-disruption lift-and-shift path for physical, virtual, or cloud servers into AWS.
Think before readingWhat does Application Migration Service migrate?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- AWS Application Migration Service
- MGN and lift-and-shift migration
- Source servers
- Replication agents
- Staging area resources
- Continuous block-level replication
- Test launch and cutover
- Launch settings and EC2 targets
- MGN versus DMS, DataSync, and Migration Hub
- Security, reliability, scaling, and cost traps
1. Plain-English Mental Model
AWS Application Migration Service, often called MGN, is server rehosting machinery.
The simple model is:
source server -> continuous replication to AWS -> test EC2 launch -> cutover EC2 launch
It is for moving applications by moving their servers. The source can be physical, virtual, or cloud-based, depending on support. MGN replicates source server disks into your AWS account and then launches the server as an EC2 instance when you test or cut over.
MGN is not a database-specific migration service. It is not a file transfer scheduler. It is not application refactoring. It is the "lift and shift" path: get the workload running on AWS first, then modernize later if needed.
2. Why This Service Exists
Many organizations cannot rewrite everything before moving to AWS.
A data center exit may have a deadline. A licensing contract may be ending. A hardware refresh may be too expensive. An acquisition may require fast consolidation. The application may be poorly documented, but the business still needs it running.
The ideal cloud-native answer might be redesigning the application around managed services, containers, serverless, and managed databases. That can be the right long-term move, but it may take months or years.
Application Migration Service exists for the pragmatic rehost path. It helps teams replicate existing servers to AWS with shorter cutover windows and less compatibility risk than a manual rebuild.
For SAA-C03, MGN is the service to recognize when the scenario says lift and shift, rehost, replicate physical or virtual servers, or reduce cutover downtime for server migration.
3. The Naive Approach And Where It Breaks
The naive pattern is:
build new EC2 instance -> reinstall app -> copy files -> reconfigure -> hope it matches
This breaks when no one knows every package, registry setting, cron job, certificate, local dependency, driver, or configuration file. It also breaks when the source server keeps changing during the migration.
Another naive approach is to take a one-time image and restore it later. That creates a large cutover window because all changes after the image must be captured.
A third mistake is using DMS for the entire application. DMS helps move database data. It does not replicate a web server, app server, Windows server, or Linux host into EC2.
MGN reduces these problems by continuously replicating server disks until test and cutover.
4. Core Primitives
A source server is the machine being migrated.
The AWS Replication Agent is installed on source servers in the common MGN workflow. It sends replicated data to AWS.
The staging area contains lightweight AWS resources used for replication before the final migrated instances are launched.
Replication settings define how data is copied, which subnet and security groups are used for staging resources, and how replication behaves.
Launch settings define the target EC2 instance configuration used for test and cutover launches. This includes instance type, subnet, security groups, and other EC2-related choices.
A test launch creates test instances so teams can validate the application in AWS before cutover.
A cutover launch creates the production migrated instances when the team is ready to switch traffic.
Post-launch actions can help perform tasks after instances launch, depending on configuration.
5. Architecture Use Cases
Use MGN for a data center exit where many existing application servers must move to EC2:
on-premises servers -> MGN replication -> EC2 test instances -> EC2 cutover instances
Use it when the application cannot be easily rebuilt from infrastructure-as-code or deployment pipelines.
Use it when the business wants minimal downtime rehosting before later modernization.
Use DMS alongside MGN when the application also has databases that should move to RDS, Aurora, or another target with database-aware migration.
Use DataSync alongside MGN when large file shares or object datasets must move separately from the server disks.
Use Migration Hub-style tracking when a program needs central visibility across many MGN and DMS migrations, while checking current AWS service availability.
7. Security Model
MGN security includes source server agent permissions, network connectivity, staging area design, IAM permissions, encryption, launch settings, and target instance hardening.
The source servers must be able to communicate with AWS endpoints required by MGN. Network routes, firewalls, proxies, security groups, and private connectivity may matter.
Staging resources should live in controlled subnets with appropriate security groups.
IAM permissions should be scoped for migration operators and automation.
Replicated data should be encrypted according to workload requirements. Target EBS volumes and snapshots should use appropriate KMS keys.
The migrated EC2 instance inherits many source server risks. Old OS versions, weak local users, secrets on disk, agents, and exposed services do not become safe just because the server runs in AWS.
8. Reliability And Resilience
MGN improves migration reliability by supporting continuous replication and test launches before cutover.
Test launch is essential. It proves that the replicated server can boot, attach networking, run services, reach dependencies, and pass application health checks in AWS.
Cutover planning must include DNS changes, load balancer targets, firewall rules, database endpoints, external integrations, and rollback decisions.
Replication lag matters. If the source changes faster than replication can keep up, cutover readiness is affected.
MGN rehosts the workload. It does not automatically make it highly available. After migration, the architecture may still need Auto Scaling, load balancers, Multi-AZ databases, backups, monitoring, and disaster recovery design.
9. Performance And Scaling
MGN performance depends on source disk change rate, network bandwidth, source server resources, staging area configuration, and target EC2 choices.
Initial replication can take time for large disks. Ongoing replication must keep up with write rates.
Test instances should use realistic instance types. A server that runs poorly in test because it was launched too small may create false migration issues.
Right sizing is a major opportunity after rehosting. Old servers are often overprovisioned or under-observed. After migration, use CloudWatch, Compute Optimizer, load testing, and business metrics to tune instance families and sizes.
For application performance, network adjacency changes matter. A rehosted app server may now be farther from a database, file share, license server, or third-party dependency unless those dependencies migrate too.
10. Cost Model
MGN cost includes replication resources, staging area infrastructure, EBS volumes and snapshots, launched EC2 instances for test and cutover, data transfer, logs, and target architecture costs.
During migration, you may pay for both source infrastructure and AWS staging or test resources.
After cutover, cost depends heavily on EC2 instance size, storage, licensing, data transfer, backup, monitoring, and support services.
Lift and shift can be faster than refactoring, but it may preserve inefficient architecture. Cost optimization often happens after migration through right sizing, managed databases, storage cleanup, Auto Scaling, reserved pricing, or modernization.
The exam may frame MGN as reducing migration time and disruption, not as the cheapest final architecture.
12. SAA-C03 Exam Signals
"Lift and shift applications to AWS" points to AWS Application Migration Service.
"Rehost physical, virtual, or cloud servers as EC2 instances" points to MGN.
"Continuously replicate source servers and launch cutover instances" points to MGN.
"Need short cutover windows for server migration" points to MGN.
"Migrate relational database with CDC" points to DMS, not MGN.
"Move NFS or SMB file data to S3 or EFS" points to DataSync, not MGN.
"Track migration status across tools" historically points to Migration Hub-style capability, not MGN itself.
13. Common Exam Traps
Do not choose DMS for whole-server migration.
Do not choose MGN for database engine conversion.
Do not assume lift and shift means modernization. MGN rehosts first; refactoring comes later.
Do not ignore target network design. Migrated EC2 instances still need subnets, routes, security groups, load balancers, DNS, and access to dependencies.
Do not skip test launch. Cutover without testing is a migration risk, not an architecture best practice.
Do not assume MGN automatically creates high availability. Rehosted single servers can remain single points of failure.
15. Related Topics
Review Amazon EC2 before studying MGN because the target of a rehosted server migration is usually EC2.
Next, study AWS Database Migration Service and AWS DataSync so server, database, and storage migrations stay separate in exam scenarios.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.