Cross-Cloud VM Migration: GCP → AWS Using AWS Application Migration Service (MGN)
Cross-cloud VM migration is not a disk copy task.
It is:
An access model transformation
A replication lifecycle management exercise
A downtime control operation
A cost boundary decision
We executed a production-grade migration from Google Compute Engine to Amazon EC2 using AWS Application Migration Service (MGN) under strict operational constraints:
Target RPO ≈ 0 at cutover (achieved through application write freeze, replication validation, and successful final synchronization)
Downtime < 30 minutes
No SSH/RDP lockout
Controlled replication cost
Preserved rollback capability
This article documents a technically precise, enterprise-review-safe execution model.
1. Why We Chose AWS MGN
We evaluated:
Manual snapshot export/import
Image-based migration
Backup/restore workflows
Application rebuild
We selected AWS MGN because:
Continuous block-level replication minimizes downtime
Test migrations do not impact production
Cutover is controlled and repeatable
No application redesign required (pure rehost model)
This was lift-and-shift, not modernization.
2. What AWS MGN Actually Does
AWS MGN is an agent-based block-level replication service.
It:
Installs a replication agent on the source VM
Reads disk blocks at the operating system level
Continuously replicates encrypted data to AWS
Uses staging replication servers and EBS volumes
Launches test and cutover EC2 instances
Critical Clarification
MGN replicates disk state.
It migrates:
Local OS users stored on disk
SSH configuration files stored on disk
Application binaries
System configuration
It does not migrate:
GCP OS Login (IAM-based access)
Metadata-injected SSH keys
DNS records
Load balancers
Managed services (Cloud SQL, etc.)
IAM identities
Any identity mechanism tied to GCP metadata or IAM must be replaced with persistent OS-level users or SSM-based access prior to cutover.
3. Migration Architecture
GCP VM
↓
MGN Replication Agent
↓
Encrypted TLS Transfer
↓
AWS Staging Replication Server
↓
EBS Replication Volumes
↓
Launch Template
↓
Test EC2 Instance
↓
Cutover EC2 Instance
Replication continues until cutover.
Data encrypted in transit (TLS)
EBS encryption configurable at rest
Replication throughput depends on bandwidth, write churn, and staging configuration
4. MGN Lifecycle States (Operational Meaning)
Not Ready
Initial full replication in progress.
Ready for Testing
Initial synchronization complete. Continuous delta replication active.
Test in Progress
Test EC2 launched. Source VM continues running.
Ready for Cutover
Replication functioning correctly with minimal lag.
Production Cutover Gate
Proceed only if:
Migration lifecycle = Ready for cutover
Replication status = Healthy
Replication lag is negligible or zero
Never execute cutover if replication is not Healthy.
Cutover in Progress
Final synchronization executing and EC2 launching.
Cutover Complete
AWS EC2 becomes the active production workload.
5. Primary Risk: Access Model Mismatch
Default GCP access model:
OS Login (IAM-based)
Metadata-injected SSH
Console SSH
Default AWS access model:
OS-level local users
SSH key pairs
SSM Session Manager
These models are incompatible.
If a VM relies exclusively on GCP OS Login or metadata-based SSH, administrative access will be lost after migration.
6. Mandatory Pre-Migration Access Preparation
Linux
Create a persistent administrative user:
sudo useradd awsadmin
sudo mkdir -p /home/awsadmin/.ssh
sudo chmod 700 /home/awsadmin/.ssh
sudo nano /home/awsadmin/.ssh/authorized_keys
sudo chmod 600 /home/awsadmin/.ssh/authorized_keys
sudo chown -R awsadmin:awsadmin /home/awsadmin
sudo usermod -aG sudo awsadmin
Validate SSH access before migration.
Attach IAM role:
AmazonSSMManagedInstanceCore
This ensures emergency fallback access via Session Manager.
Windows
Enable local Administrator
Enable RDP
Allow TCP 3389
Validate login before migration
7. Network Requirements
On GCP VM (Outbound Required)
Port | Protocol | Purpose |
|---|---|---|
443 | TCP | AWS control plane communication |
1500 | TCP | Replication data channel |
53 | TCP/UDP | DNS (system prerequisite) |
123 | UDP | NTP (system prerequisite) |
No inbound firewall rules are required on the source VM for MGN.
On AWS
If staging and target instances reside in private subnets, outbound connectivity must be provided via:
NAT Gateway
VPC Endpoints
Direct Connect
VPN
NAT is required only if no internet access or VPC endpoints are configured.
8. Replication Consistency Model
AWS MGN provides crash-consistent replication.
To achieve near-zero RPO:
Freeze application writes
Confirm replication status = Healthy
Confirm replication lag ≈ 0
Execute cutover
For database workloads, application quiescing is mandatory.
MGN does not provide automatic application-consistent snapshots.
9. Replication Timing Reality
Initial synchronization depends on:
Disk size
Network bandwidth
IOPS
Write churn
Example (environment dependent):
50 GB → 20–40 minutes
200 GB → 1–2 hours
1 TB → Dependent on available bandwidth
Downtime is not determined by disk size.
Downtime = write freeze duration + final synchronization time.
10. Cutover Execution Model
Validated production sequence:
Freeze application writes
Confirm replication status = Healthy
Confirm lag negligible
Launch cutover instance
Stop GCP VM
Update DNS or routing
Observed downtime: 5–30 minutes.
11. Rollback Strategy
If validation fails:
Do not delete source VM
Restore DNS to GCP
Maintain replication configuration
Reattempt cutover
Never decommission the source environment until fully validated.
12. Cost and Scale Considerations
AWS Costs
Staging replication servers
EBS volumes
Snapshots
NAT (if used)
Data transfer
GCP Cost
- Network egress (primary cost driver)
Large parallel migrations may:
Increase staging cost
Increase EBS consumption
Saturate bandwidth
Trigger API throttling
Recommendation: Execute migrations in controlled waves.
13. When This Approach Makes Sense
Suitable for:
Lift-and-shift
Data center exit
Legacy workload relocation
Time-constrained transitions
Not suitable for:
Cloud-native redesign
Container migrations
Managed database modernization
Application refactoring
Final Engineering Conclusion
AWS Application Migration Service is predictable when:
Access models are reconciled
OS compatibility is validated
Replication health and lag are monitored
Cutover is controlled
Rollback capability is preserved
Most migration failures are not replication failures.
They are planning failures.
Cross-cloud VM migration is an operational engineering discipline — not a file transfer task.
