AWS Application Migration Service (MGN) — Lift-and-Shift Rehost
Recap: From Inventory to Movement
Application Discovery Service gave us the inventory half of the migration problem. Agent-based discovery captured process-level network connections, agentless discovery gave us VM-level utilization, and both fed into Migration Hub so the portfolio could be grouped into waves and the target instances right-sized against measured demand rather than vendor spec sheets. That work answers what moves and in what order. It deliberately does not answer how the bytes get from the source server to the target.
MGN extends that assessment work directly: the discovery output becomes the input to a replication plan. Every server that discovery flagged as a rehost candidate needs a replication agent, a staging area subnet, and a cutover window, and the utilization data discovery collected is what tells you which instance type the cutover instance should launch as. The dependency mapping matters too, because MGN replicates servers individually — it has no concept of an application group, so the wave boundaries discovery produced are the boundaries you cut over within.
Foundations You'll Need Today
This day is about copying an entire running server from one place to another, so it leans on a handful of ideas about servers, disks, and AWS networking that the rest of the curriculum treats as already known. Here they are, built up from scratch.
A server is an operating system plus disks, and disks are written in blocks
When you picture a server, it helps to separate two things: the operating system (Windows or Linux, plus its kernel, which is the core program that talks to the hardware) and the storage attached to it. The operating system does not write files to disk one byte at a time. It writes in fixed-size chunks called blocks, typically a few kilobytes each, and the filesystem is just a layer of bookkeeping on top that decides which blocks belong to which file. This matters because it means you can copy a server without understanding anything about the files on it. If you capture every block the operating system writes, in order, you have captured the whole machine — the OS, the installed applications, the registry or configuration files, the boot setup, and the data. That is what "block-level replication" means, and it is why a tool that works this way does not care whether the server is running Oracle, a custom Java app, or something nobody has the source code for.
EC2 instances, AMIs, and launch templates
An EC2 instance is a virtual server running in AWS. You do not install an operating system onto it from scratch; instead you start it from an image. That image is called an AMI (Amazon Machine Image), and it is essentially a snapshot of a disk that a new instance can boot from. If you have a copy of a server's disks, you can turn them into an AMI, and from that AMI you can launch as many identical instances as you want. A launch template is the set of instructions AWS uses when it launches an instance from an image: which instance type (how much CPU and memory), which network subnet to place it in, which security group to attach, which IAM role to give it, and what tags to apply. The important consequence for today is that MGN does not decide any of those things for you. It produces the AMI from the replicated blocks, but the launch template you supply determines what kind of machine actually comes up and whether it can reach anything.
Subnets, security groups, and private network paths
A subnet is a slice of a network with its own range of IP addresses, and it is where an instance physically lives. A security group is a set of rules attached to an instance that says which network traffic is allowed in and which is allowed out — think of it as a firewall that follows the instance around. These two things are why a migrated server can boot perfectly and still be useless: if the launch template puts it in a subnet with no route to the database, or attaches a security group that does not permit the database port, the application will fail to connect even though the server itself is healthy. Separately, "private network path" refers to a dedicated connection between your data center and AWS — either AWS Direct Connect (a physical circuit) or a VPN (an encrypted tunnel over the internet) — as opposed to traffic that leaves your building and travels across the public internet. When a scenario says replication traffic must never touch the public internet, it is asking you to route the agent's outbound connections over one of those private paths.
IAM roles and instance profiles
IAM is AWS's permission system. A role is a set of permissions that something can temporarily assume, rather than a username and password that a person logs in with. An instance profile is the mechanism that attaches a role to an EC2 instance, so that programs running on that instance can call AWS APIs — for example, writing logs to CloudWatch or reading a file from S3 — without anyone embedding secret keys on the server. This is relevant today because the launch template specifies the instance profile, and if it is missing or wrong, the migrated application will fail in ways that look like ordinary bugs: a log line that never appears, a file that cannot be read. The server is fine; it simply was never given permission to do its job.
Quotas
A quota (sometimes still called a limit) is a ceiling AWS places on how much of a resource you can create in a region — for example, the total number of virtual CPUs across all your EC2 instances, or the number of EBS volumes. Quotas exist to protect both you and AWS from runaway usage, and most of them can be raised on request, but the request takes time to process. This matters for migrations because a cutover is a burst: you might launch fifty instances in an afternoon after running almost nothing in that account for months. If the quota was never raised in advance, the launches fail, and the error looks like a migration problem when it is really a capacity-planning problem.
With that grounding, here is why MGN exists, what problem it actually solves, and how it differs from the other services that also move data into AWS.
1. Why This Is on the Exam
Rehost is the least glamorous of the seven migration strategies and, by volume, the one most real migrations actually use. The SAP-C02 exam reflects that reality. Scenarios that describe a data center exit deadline, a portfolio of hundreds of servers, an application that cannot be re-architected inside the timeline, or a mandate to "lift and shift first, modernize later" are almost always testing whether you reach for AWS Application Migration Service rather than proposing a refactor the business cannot absorb. The service maps most directly to Domain 3, Migration and Modernization, but it also surfaces in Domain 2 resilience questions where the answer hinges on whether a cutover can be tested without touching production.
The reason MGN is worth a full day rather than a paragraph is that the exam does not ask "what is MGN." It asks you to distinguish MGN from the four or five other services that also move data, and the distinctions are subtle. DataSync moves files. DMS moves database contents. Snowball moves bulk data offline. Storage Gateway keeps data on-premises and tiers it to AWS. MGN moves whole servers — operating system, installed applications, registry, boot configuration, and data volumes — and lands them as bootable EC2 instances. A scenario that says "the application team has no source code and no vendor support" is telling you that only a block-level server replication tool can work, because there is nothing to rebuild.
There is also a governance dimension the exam likes to probe. MGN is a service that, by design, copies an entire production server into an AWS account. That means the replication traffic, the staging area, and the cutover instances all need to be inside the account structure and network controls you built in Phase 1. A scenario that pairs MGN with a requirement that replication traffic never traverse the public internet is testing whether you connect the migration tool to the Direct Connect or VPN path rather than assuming the agent will find its own way.
2. How MGN Actually Works
MGN is a block-level replication system, not a file-copy or image-export tool. You install a lightweight replication agent on the source server — Windows or Linux, physical or virtual, on-premises or in another cloud. The agent installs a kernel-level driver that intercepts writes at the block layer, so every write the operating system issues to disk is captured and forwarded to the MGN replication servers in your AWS account. This is the same continuous data protection model that CloudEndure used, and MGN is the direct successor to that product line as well as to the older Server Migration Service. The interception happens below the filesystem, which is why MGN does not care what filesystem, database engine, or application is running on the server.
The destination of that stream is the staging area: a small, automatically provisioned set of EC2 instances and EBS volumes in a subnet you designate, in the target region and account. The staging area is not the migration target. It is a landing zone where the replicated blocks are written into volumes that MGN manages, and it exists so that the source server's data is continuously current in AWS before you decide to do anything with it. Replication is incremental after the initial sync — the agent sends changed blocks, not whole volumes — which is what keeps the ongoing bandwidth cost proportional to write rate rather than to disk size.
When you want to see the server running in AWS, you launch a test instance. MGN takes the current state of the replicated volumes, creates an AMI from them, and launches an EC2 instance from that AMI using a launch template you control. The test instance is a real, bootable copy of the server. It is not connected to the source in any way, and it does not affect replication — the agent keeps streaming blocks the whole time. This is the property that makes MGN valuable for planning: you can boot the migrated server, run your acceptance tests, fix the launch template, and repeat, all without a maintenance window. When the test passes, cutover is the same operation with a different label, plus a final sync of the last few blocks and a stop of the source server.
3. The Core Decision Boundary: Rehost or Something Else
Almost every MGN scenario question reduces to a single fork: does the workload need to arrive in AWS as a running server, or does it need to arrive as data that something else will consume? If the answer is a running server, MGN is the tool. If the answer is data, MGN is the wrong tool and the question is really about DataSync, DMS, or the Snow Family. The exam writes distractors that blur this line by describing the workload in terms of what it contains rather than what it is — "a server hosting a 2 TB Oracle database" is a server question, not a database question, unless the scenario explicitly says the database is being migrated to RDS or Aurora.
The second half of the boundary is about how much change the business can tolerate. Rehost means the application arrives unchanged, which is fast and low-risk but also means you inherit every piece of technical debt the server had. Replatform means you change one layer — self-managed MySQL becomes RDS, or a self-managed load balancer becomes an ALB — which costs more effort but removes operational burden. Refactor means re-architecting, which is the most expensive and slowest path. MGN is the rehost tool, and the exam expects you to recognize when a scenario's constraints (deadline, no source code, no vendor support, regulatory freeze) eliminate the other two options.
| Signal in the scenario | Strategy | Tool |
|---|---|---|
| Data center lease expiring, hundreds of servers, no time to re-architect | Rehost | AWS MGN |
| Application must keep running on the same OS and middleware, unchanged | Rehost | AWS MGN |
| Self-managed database engine being replaced with a managed AWS engine | Replatform | AWS DMS (+ SCT if engines differ) |
| File share or object store being copied to S3, EFS, or FSx | Replatform / Retain | AWS DataSync |
| Petabyte dataset, no viable network path | Rehost (data only) | Snowball Edge / Snowmobile |
| VMware VMs must stay VMware, no conversion to AMI | Relocate | VMware Cloud on AWS |
| On-prem application needs low-latency access to AWS services but stays on-prem | Retain | Storage Gateway / Outposts |
4. Configuration Modes and Their Tradeoffs
The knobs that matter in MGN are not about how data is copied — that part is automatic — but about how the cutover instance is constructed and how much of the process you automate. The first and most consequential choice is the launch template. MGN does not guess at instance type, subnet, security groups, or IAM instance profile; it uses a launch template you supply, and every test and cutover instance is launched from it. This is where the discovery data from Day 44 pays off, because the launch template's instance type should be sized from measured utilization, not from the source server's physical CPU count. A common failure is to size the cutover instance identically to the source and then discover the workload is now over-provisioned and over-priced in AWS.
The second choice is whether to use the default launch template or per-server overrides. MGN lets you set a default template for the whole source server fleet and then override it for individual servers. In a wave-based migration this matters: a wave of web servers can share a template, while the database server in the same wave needs a different instance family, a different subnet, and possibly a different EBS volume type. Managing this as a small number of templates with targeted overrides is far more maintainable than one template per server, and it is the pattern the exam tends to describe when it asks how to standardize a large migration.
The third choice is the cutover lifecycle itself: test, then cut over, then finalize. Test launches an instance without touching the source. Cutover launches an instance and, once you confirm it is healthy, you stop the source server and let MGN perform a final sync of the last changed blocks. Finalize detaches the source server from MGN and stops replication, which is the point of no return — after finalize, the source server is no longer tracked and the staging area resources for it can be cleaned up. The exam likes the distinction between cutover and finalize because it is the difference between "we have moved" and "we have committed."
| Setting | What it controls | Cost of getting it wrong |
|---|---|---|
| Launch template | Instance type, subnet, security groups, IAM profile, tags | Over-provisioned or unreachable cutover instances |
| Default vs per-server template | Standardization across a wave | Template sprawl, drift between servers in the same wave |
| Replication settings (throttling) | Bandwidth consumed by the agent | Saturated WAN link, impact on production traffic |
| Staging area subnet | Where replicated volumes live before cutover | Replication traffic crossing the public internet |
| Cutover vs finalize | Whether the source is still tracked | Premature finalize removes the rollback path |
5. Sizing, Limits, and Quotas
Sizing an MGN migration has two independent dimensions: the bandwidth the replication stream consumes, and the compute the cutover instances will need. The bandwidth dimension is governed by the source server's write rate, not its disk size, because replication is incremental after the initial sync. A 4 TB server that writes 20 GB a day costs far less ongoing bandwidth than a 200 GB server that writes 500 GB a day. The initial sync, however, is proportional to the used blocks on disk, and that is the phase where a constrained link becomes the bottleneck. This is the same arithmetic that drives the Snowball-plus-CDC pattern from Day 52: if the initial sync over the available link would take longer than the migration window, the bulk data has to move physically.
On the compute side, the cutover instance is an ordinary EC2 instance and is subject to ordinary EC2 quotas — vCPU limits per region, EBS volume limits, and the availability of the instance family you selected in the target Availability Zone. A migration wave that launches fifty cutover instances at once can hit a regional vCPU quota that nobody raised in advance, and the failure looks like a launch error rather than a migration error. The staging area itself consumes a small number of instances and EBS volumes per source server, so a fleet of several hundred servers has a non-trivial standing footprint in the target account even before any cutover happens.
The operational limits worth knowing are about the agent and the source server rather than AWS quotas. The agent requires a supported operating system version and kernel, and it needs outbound network access to the MGN replication endpoints — either over the public internet with TLS or over a private path such as Direct Connect or VPN. It also needs to be able to reach the MGN API endpoints for control-plane operations. Servers that cannot install a kernel driver, such as some hardened or appliance-style systems, are not MGN candidates and have to be handled by a different strategy. The exam rarely asks for exact numeric quotas, but it does ask whether you would check them before a large cutover, and the answer is always yes.
6. Failure Modes and What They Look Like in Production
The most common production failure is a stalled replication stream, and it presents as a source server whose "last replicated" timestamp stops advancing in the MGN console. The cause is usually network: the agent lost its path to the replication endpoint, a firewall rule changed, or the link saturated and the agent is falling behind faster than it can catch up. The first diagnostic move is to check the agent's own logs on the source server and the replication lag metric in the console, then verify connectivity to the replication endpoint from the source. A stream that is merely lagging is different from one that is broken, and the console distinguishes them.
The second failure mode is a cutover instance that launches but does not work. This is almost never an MGN problem — it is a launch template problem. The instance boots but cannot reach its dependencies because the security group is wrong, or it fails to join the domain because the subnet has no route to the domain controllers, or it comes up with the wrong instance type and the application times out under load. The diagnostic move is to compare the test instance's network configuration against the source server's, and to check whether the application has hard-coded references to the source IP address or hostname. Hard-coded IPs are the single most common reason a rehost "works" in test and fails in production.
The third failure mode is a cutover that succeeds technically but is discovered to be incomplete. The source server was still writing when the final sync ran, or a dependent server in the same application group was not cut over at the same time, and now the two halves of the application are talking across a split. This is why the dependency mapping from discovery matters: MGN replicates servers one at a time, and the migration team is responsible for cutting over an application group atomically. The symptom is intermittent errors that appear only under specific request paths, which makes it expensive to diagnose after the fact.
7. The Operational and SRE Angle
From an SRE perspective, an MGN migration is a change-management event with a rollback path, and it should be treated with the same rigor as a production deployment. The metrics that matter during the replication phase are replication lag and the rate of change on the source server. Lag tells you whether the stream is healthy; the change rate tells you whether the link has enough headroom to catch up after a burst. Both should be alarmed, and the alarm should fire before the lag becomes large enough to threaten the cutover window. A migration that discovers a lag problem on cutover night has already lost.
During the cutover itself, the relevant signals are the ones you would monitor for any deployment: application error rate, latency, and dependency health on the new instance, plus the health of the source server as it is drained. The runbook shape is a sequence of gates — confirm replication is current, launch the cutover instance, run smoke tests, stop the source, run the final sync, verify, then finalize. Each gate has a rollback: before the source is stopped, rollback is simply "do nothing and keep the source running." After the source is stopped but before finalize, rollback is "restart the source and re-point traffic." After finalize, rollback means restoring from backup, which is why finalize is the last step and not the first.
The SLO implication is that a rehost migration should not be allowed to consume the application's entire error budget. If the cutover is planned as a maintenance window, the window is the budget. If the business requires zero-downtime cutover, then the migration needs a blue/green or weighted-routing pattern on top of MGN — MGN gets the server into AWS, but it does not do traffic shifting. That is a Route 53 or load-balancer concern, and the exam will sometimes combine the two to see whether you understand where MGN's responsibility ends.
8. Edge Cases and Exam Gotchas
The first gotcha is the assumption that MGN requires downtime. It does not. Replication is continuous and test instances are non-disruptive, so the only downtime is the interval between stopping the source server and confirming the cutover instance is serving traffic. Scenarios that describe a maintenance window measured in hours are usually describing a different tool or a poorly planned cutover, not an MGN limitation. The second gotcha is the assumption that MGN converts the operating system or the application. It does not — it replicates blocks, so the target runs the same OS and the same application, which is precisely why it is the right answer when there is no source code or vendor support.
The third gotcha is confusing MGN with DMS. A scenario that says "migrate the database to Aurora" is a DMS scenario even if the database currently runs on a server that MGN could replicate. The distinction is the target: if the target is a managed database service, the data has to be migrated as data, not as blocks. The fourth gotcha is the staging area. Candidates sometimes assume the staging area is the target environment and try to run production traffic against it. It is not — it is a replication buffer, and the cutover instance is the target. The fifth gotcha is finalize. Finalize is irreversible from MGN's perspective, and the exam will sometimes describe a team that finalized prematurely and then needed to roll back.
The sixth gotcha is licensing and OS activation. A rehosted Windows server may need re-activation, and commercial software with node-locked or hardware-locked licenses may not run on the new instance without vendor intervention. This is not an MGN limitation but it is a migration-planning issue that the exam expects you to raise. The seventh is the agent itself: it needs a supported kernel and outbound connectivity, and servers that cannot meet those requirements are not MGN candidates. The eighth is the launch template's IAM instance profile — a cutover instance that needs to read from S3 or write to CloudWatch will fail silently if the profile is missing, and the failure looks like an application bug rather than a migration bug.
9. MGN vs. the Services It Gets Confused With
The cleanest way to hold this in memory is to ask what unit of work each service moves. MGN moves a server. DMS moves the contents of a database. DataSync moves files and objects. Snowball moves bulk data physically. Storage Gateway keeps data on-premises and presents it to AWS. VMware Cloud on AWS moves a VM without converting it out of the VMware format. Each of these answers a different question, and the exam's distractors are built by describing a workload in a way that makes two of them sound plausible.
The rule that resolves most of these: if the scenario's target is a running EC2 instance that behaves like the source server, pick MGN. If the target is a managed service — RDS, Aurora, S3, EFS, DynamoDB — pick the tool that produces data in that service's format. If the constraint is network capacity rather than application change, pick the offline transfer tool. And if the constraint is that the workload must remain VMware-managed, pick Relocate rather than Rehost.
| Service | Unit moved | Target | Pick it when… |
|---|---|---|---|
| AWS MGN | Whole server (block-level) | EC2 instance from an AMI | The application must arrive unchanged as a running server |
| AWS DMS | Database contents (rows, schema objects) | RDS, Aurora, Redshift, another engine | The target is a managed database service |
| AWS SCT | Schema and procedural code | Converted DDL for a different engine | Source and target engines differ and stored procedures exist |
| AWS DataSync | Files and objects | S3, EFS, FSx | The workload is a file share, not a server or a database |
| Snowball Edge / Snowmobile | Bulk data, offline | S3 (then loaded onward) | The network cannot move the volume inside the window |
| VMware Cloud on AWS | VM, unconverted | VMware SDDC on AWS | The VM must stay VMware-managed |
| Storage Gateway | Ongoing data tiering | S3-backed file/volume/tape | The workload stays on-premises but needs AWS-backed storage |
Hands-on Lab: Replicate, Test, and Cut Over a Server (45 min)
This lab walks the full MGN lifecycle against a single source server. If you do not have an on-premises server available, a Linux EC2 instance in a separate VPC works as a stand-in source — the agent behaves the same way, and the exercise still teaches the launch-template and cutover mechanics. Budget roughly 45 minutes, most of which is waiting for the initial replication to complete.
- Prepare the target account. In the target region, initialize MGN from the console. This creates the service-linked role and the default replication settings. Confirm the staging area subnet you want to use exists and has outbound connectivity to the MGN endpoints.
- Create a launch template. Build an EC2 launch template with the instance type you intend to use, the target subnet, a security group that permits your test traffic, and an IAM instance profile that grants whatever the application needs (for example, CloudWatch Logs write access). Tag it clearly — you will reuse it for both test and cutover.
- Install the replication agent. On the source server, download the agent installer from the MGN console and run it. The installer registers the server with MGN and begins the initial sync. Verify in the console that the server appears with a "Healthy" replication status.
- Watch the initial sync. Monitor the replication progress until the initial sync completes and the server shows a low, steady lag. Note the elapsed time — this is your baseline for how long a similar server would take over the same link, and it is the number that tells you whether a larger server would need an offline transfer instead.
- Launch a test instance. Select the source server, choose "Launch test instance," and pick your launch template. Wait for the instance to reach running state, then connect to it and verify that the application starts and that its dependencies resolve.
- Break something on purpose. Deliberately misconfigure the launch template — remove the security group rule that allows database access, or point it at the wrong subnet — and launch a second test instance. Observe how the failure presents. This is the diagnostic skill the exam assumes you have.
- Fix and re-test. Correct the launch template and launch a third test instance. Confirm the application is healthy. Note that none of this touched the source server or interrupted replication.
- Perform the cutover. Stop the application on the source server (or stop the server itself), then choose "Launch cutover instance." MGN performs a final sync of the last changed blocks and launches the instance from the same template.
- Verify and finalize. Run your smoke tests against the cutover instance. Once satisfied, choose "Finalize cutover" to detach the source server and stop replication. Confirm the source server no longer appears as an active source in the console.
- Clean up. Terminate the test and cutover instances, remove the source server from MGN, and delete the staging area resources if you are not continuing with more servers. Record the total elapsed time from agent install to finalize — that is the realistic per-server cost of a rehost.
Scenario Question Drills (20 min)
Q1. A company needs to rehost 200 on-prem VMs to EC2 as fast as possible with minimal application changes and minimal cutover downtime.
Q2. An application has no source code available and the vendor that wrote it no longer exists. The business needs it running in AWS within 90 days. Which migration strategy is the only viable one?
Q3. A migration team wants to validate that a migrated server boots and serves traffic correctly before committing to a cutover, without interrupting the production server. What does MGN provide for this?
Q4. A cutover instance launches successfully but the application cannot connect to its database. The database is reachable from the source server. What is the most likely cause?
Q5. A company must migrate a 6 TB server over a 200 Mbps link and the migration window is two weeks. The server writes about 15 GB per day. What should the team do?
Q6. What is the difference between performing a cutover and finalizing a cutover in MGN?
Q7. A migration team is planning a wave of 60 servers and wants to standardize the target configuration while still allowing a few servers to differ. What is the recommended approach?
Q8. Replication for a source server has stalled and the "last replicated" timestamp in the console has not advanced for several hours. What is the first diagnostic step?
Q9. A company wants all MGN replication traffic to stay off the public internet. What must be in place?
Q10. A scenario describes migrating a self-managed Oracle database to Amazon Aurora PostgreSQL. Which tool is the primary answer?
Q11. What does the MGN staging area actually do?
Q12. A rehosted Windows server fails to activate after cutover, and a commercial application refuses to start because of a hardware-locked license. What is the correct characterization of this problem?
Q13. A migration wave launches 50 cutover instances simultaneously and several fail with launch errors. What is the most likely cause?
Q14. An application consists of a web tier and an application tier that communicate constantly. The team cuts over the web tier first and leaves the application tier on-premises for a week. What is the likely outcome?
Q15. A team wants a zero-downtime cutover for a customer-facing application. MGN gets the server running in AWS, but what additional capability is required to shift traffic without an outage?
Peek into Tomorrow
Everything in this day assumed the target was another server running the same operating system and the same application. That assumption is what makes block-level replication sufficient — there is no translation step, because nothing about the workload changes. The open question is what happens when the target is not a server at all, but a different database engine entirely. A rehosted Oracle instance on EC2 is still Oracle; the moment the business says "move it to Aurora PostgreSQL," the problem stops being about moving bytes and starts being about translating semantics.
That translation is where the migration gets genuinely hard, and it is not a bandwidth or cutover-window problem. Oracle's procedural language, its data types, its sequences, and its package structure have no one-to-one equivalent in PostgreSQL, and a tool that reports a high automatic conversion rate is still leaving a remainder that a developer has to rewrite by hand. Tomorrow's topic is that remainder: how a conversion-completeness percentage is produced, what kinds of objects typically fall into the unconverted fraction, and why a migration plan that treats a 95% figure as "done" is the plan that fails in production.
Sources
- AWS Application Migration Service — What Is AWS Application Migration Service?
- AWS MGN User Guide — Launching Test and Cutover Instances
- AWS MGN User Guide — Installing the AWS Replication Agent
- AWS MGN User Guide — Network Requirements and Staging Area
- AWS Prescriptive Guidance — Rehost Migration Strategy
- AWS Migration Whitepaper — The 7 Rs of Migration
- AWS Database Migration Service — What Is AWS DMS?
- AWS Well-Architected Framework — Reliability Pillar