AWS Migration Architecture — Overview
Migration to AWS follows a structured lifecycle: Assess → Mobilize → Migrate → Modernize. AWS provides purpose-built tools for each phase. Domain 4 of SAP-C02 (20% of the exam) focuses entirely on migration strategy selection, tool choice, and modernization decisions.
Discovery Service
Migration Evaluator
(TCO analysis)
Portfolio assessment
Direct Connect
IAM/SSO setup
Migration Factory
Wave planning
Database Migration (DMS)
DataSync / Transfer Family
Snow Family (offline)
VMware Cloud on AWS
Serverless (Lambda)
Managed databases
Event-driven
Microservices
The 7 Rs — Migration Strategy Selection
| Strategy | What | Example | When |
|---|---|---|---|
| Rehost (Lift & Shift) | Move as-is to EC2 | On-prem VM → EC2 instance | Speed priority, no app changes, large-scale migrations |
| Replatform (Lift & Reshape) | Minor optimizations during move | MySQL → RDS MySQL, self-managed → managed | Quick wins without refactoring (managed DB, Elastic Beanstalk) |
| Refactor (Re-architect) | Redesign for cloud-native | Monolith → microservices on ECS/Lambda | Business need for agility, scale, or cloud-native features |
| Repurchase | Move to SaaS | On-prem CRM → Salesforce, Email → SES | Commercial product is better than self-managed |
| Relocate | Move VMware to AWS without changes | VMware vSphere → VMware Cloud on AWS | VMware investment, need speed, keep same operations |
| Retain | Keep on-premises (not ready yet) | Mainframe with 1000+ dependencies | Too complex, regulatory, or not cost-justified to move now |
| Retire | Decommission | Legacy app with 5 users | No longer needed, redundant, or being replaced |
Discovery & Assessment Tools
| Tool | How It Works | Data Collected |
|---|---|---|
| Agentless Collector (OVA) | Deploy virtual appliance in VMware vCenter | VM inventory, CPU/RAM utilization, disk allocation (no network/process data) |
| Discovery Agent | Install on each server (Windows/Linux) | CPU, RAM, disk, network connections, running processes — full detail |
| Migration Hub | Central dashboard for all migration tracking | Server grouping, application mapping, migration status per tool |
| Migration Evaluator | TCO analysis and business case | Cost comparison: on-prem vs AWS for your specific workloads |
Exam tip: Agentless Collector = VMware only, less detailed. Discovery Agent = any OS, full detail (processes, network connections). Use Agent when you need network dependency mapping to group servers into applications.
Migration Tools — Which to Use When
| Tool | Migrates | How | Best For |
|---|---|---|---|
| Application Migration Service (MGN) | Entire servers (OS + apps + data) | Continuous block-level replication → launch EC2 on cutover | Rehost (lift & shift) of physical/virtual servers |
| Database Migration Service (DMS) | Databases | Full load + CDC (ongoing changes) | Database migration with minimal downtime |
| AWS DataSync | Files / NFS / SMB / HDFS / object storage | Agent-based, scheduled or one-time transfer | NAS migration, file server to S3/EFS/FSx, ongoing sync |
| Snow Family | Large data (TBs to PBs) | Physical device shipped, load data → ship to AWS | Limited bandwidth, 10TB+, edge computing |
| Transfer Family | Files via SFTP/FTPS/FTP | Managed SFTP endpoint → S3/EFS | Partners using legacy file transfer protocols |
| VMware Cloud on AWS | VMware workloads | vMotion or HCX (live migration) | Relocate strategy — keep VMware operations as-is |
Large-Scale Migration Patterns
Wave Planning
Group servers into migration waves based on dependencies and priority:
- Wave 1: Simple, independent apps (prove the process)
- Wave 2-N: Increasingly complex apps, grouped by dependency
- Final wave: Most critical/complex applications
Migration Factory
Standardized, repeatable migration process for large-scale (100+ servers):
- Playbooks — Step-by-step runbooks per application type
- Automation — CloudFormation/CDK for landing zone, MGN for replication, SSM for post-migration config
- Testing — Non-disruptive test launches from MGN before cutover
- Cutover windows — Scheduled maintenance windows with rollback plan
Zero-Downtime Server Migration (MGN)
- Install replication agent on source servers → continuous block replication to AWS staging area
- Test launches — Launch test EC2 instances from replicated data. Validate. Terminate test instances.
- Cutover — Stop source server → Final sync (seconds) → Launch production EC2 → Update DNS/LB
- Downtime — Only during final sync + DNS switch (minutes)
Data Transfer Decision Guide
| Data Size | Available Bandwidth | Recommended Tool |
|---|---|---|
| <10 TB | Internet / Direct Connect | DataSync (over network) |
| 10-80 TB | Limited (<100 Mbps) | Snowball Edge |
| 80 TB – PB | Any | Snowball Edge (multiple) or Snowmobile |
| Ongoing sync | Direct Connect / VPN | DataSync (scheduled) or DMS CDC (for databases) |
Rule of thumb: If transfer over network takes >1 week, consider Snow Family. Formula: Data(TB) × 1024 × 8 / Bandwidth(Mbps) / 86400 = days.
Post-Migration Modernization Path
- Rehost first, then modernize: Get to AWS fast (lift & shift), then iteratively improve
- Database: EC2-hosted DB → RDS (managed) → Aurora Serverless (auto-scale) → DynamoDB (if key-value)
- Compute: EC2 → Containers (ECS/Fargate) → Serverless (Lambda) where appropriate
- Decouple: Monolith → Extract services using SQS/SNS/EventBridge for async communication
- Storage: Block (EBS) → Object (S3) for unstructured data, shared file (EFS/FSx) for lift-and-shift NAS
Exam Tips
| Exam | Key Points |
|---|---|
| SAP-C02 | “Lift and shift servers” → Application Migration Service (MGN). “Migrate database with minimal downtime” → DMS + CDC. “Migrate file servers” → DataSync. “50TB+ limited bandwidth” → Snow Family. “VMware to AWS without changes” → VMware Cloud on AWS (Relocate). “Understand dependencies” → Discovery Agent (not Agentless). “Track all migrations” → Migration Hub. “Minimize code changes” = Rehost/Replatform. “Cloud-native benefits” = Refactor. |
AWS Certification Exam Practice Questions
Question 1:
A company needs to migrate 500 on-premises VMs to AWS with minimal downtime. They want to replicate servers continuously and perform non-disruptive test launches before the actual cutover. Which service provides this?
- AWS DataSync with scheduled replication
- AWS Application Migration Service (MGN) with continuous replication and test mode
- VM Import/Export to create AMIs from each VM
- AWS Database Migration Service with full load
Show Answer
Answer: B — Application Migration Service (MGN) continuously replicates server block storage to AWS. You can launch test instances at any time without affecting the source servers (non-disruptive testing). At cutover, it performs a final sync and launches production instances. This is the standard tool for rehost (lift-and-shift) migrations at scale. DataSync is for files/NFS. VM Import creates static AMIs (no continuous replication).
Question 2:
A company has 80TB of file data on an on-premises NAS (NFS). Their internet bandwidth is 200 Mbps. They need the data in S3 within 2 weeks and want ongoing daily synchronization after the initial transfer. What approach is MOST efficient?
- AWS DataSync over the internet for initial + ongoing sync
- AWS Snowball Edge for initial bulk load + DataSync for ongoing daily sync
- S3 Transfer Acceleration for initial upload + S3 replication for ongoing
- Direct Connect provisioning + DataSync over Direct Connect
Show Answer
Answer: B — At 200 Mbps, transferring 80TB over network would take: 80,000 GB × 8 / 200 Mbps / 86,400 = ~37 days. Exceeds the 2-week deadline. Snowball Edge (80TB capacity) handles the initial bulk load in ~1 week (load + ship + import). Once initial data is in S3, DataSync handles ongoing daily incremental sync over the 200 Mbps link (only new/changed files). Direct Connect takes weeks to provision — won’t help the deadline.
Question 3:
A company is planning migration of 1,000 servers across 50 applications. They need to understand server dependencies (which servers communicate with which) to group them into migration waves. Their infrastructure is a mix of physical servers and VMware VMs. Which discovery approach provides this information?
- Deploy the Agentless Collector virtual appliance in VMware vCenter
- Deploy the AWS Application Discovery Agent on each server
- Use AWS Migration Hub import template with manually gathered data
- Run AWS Config in the on-premises environment
Show Answer
Answer: B — The Discovery Agent collects network connections (which servers talk to which, on which ports), running processes, CPU, RAM, and disk details. This network dependency data is essential for grouping servers into applications for wave planning. The Agentless Collector only works for VMware VMs (not physical servers) and doesn’t capture network connections or processes. The company has physical servers too.
Question 4:
A company runs 200 VMware VMs on-premises. Their operations team is heavily invested in VMware tools (vCenter, NSX, vSAN). They want to move to AWS quickly without retraining the team or changing their operational model. Which migration strategy and service fits?
- Rehost — Use Application Migration Service to migrate each VM to EC2
- Relocate — Use VMware Cloud on AWS with HCX for live migration
- Replatform — Convert VMs to containers on ECS Fargate
- Refactor — Rebuild applications as serverless on Lambda
Show Answer
Answer: B — Relocate strategy uses VMware Cloud on AWS, which runs the full VMware stack (vCenter, NSX, vSAN) on dedicated AWS hardware. HCX enables live migration (vMotion) of VMs with zero downtime. The ops team continues using the same VMware tools — no retraining. Application Migration Service (Rehost) would move to EC2 instances, changing the operational model away from VMware.
Question 5:
After migrating a monolithic web application to EC2 (rehost), a company wants to modernize it incrementally. The application has a tightly coupled order processing module that causes cascading failures. What is the recommended FIRST modernization step?
- Rewrite the entire application as Lambda functions
- Extract the order processing module into a separate service, decouple with SQS
- Move the entire application to EKS with microservices
- Replace the application with a SaaS solution
Show Answer
Answer: B — The Strangler Fig pattern: extract one service at a time from the monolith, starting with the one causing the most problems. Decoupling with SQS prevents cascading failures (if order processing is slow/down, the main app continues — orders queue). This is incremental modernization without the risk of a full rewrite. Complete rewrites (A, C) are high-risk and unnecessary when you can modernize incrementally.
Related Posts
- Database Migration Architecture (DMS & SCT)
- Hybrid Cloud Networking
- Multi-Account Architecture (Landing Zone)
- Container Platform Architecture
- Serverless API Architecture
References
- Large Migration Guide — AWS Prescriptive Guidance
- 6 Strategies for Migrating to the Cloud — AWS Blog
- Application Migration Service User Guide
- Automating Large-Scale Migrations with Migration Hub — AWS Blog
Frequently Asked Questions
What is the difference between Application Migration Service and DMS?
Application Migration Service (MGN) migrates entire servers (OS, applications, data) by replicating block storage — the result is an EC2 instance running the same workload. DMS migrates only database data between database engines with optional schema conversion. Use MGN for server migration (lift-and-shift). Use DMS for database-specific migration with schema conversion or engine change.
When should I use Snowball vs DataSync?
Use DataSync when your network can transfer the data within your timeframe (typically <10TB or adequate bandwidth). Use Snowball when network transfer would take too long (>1 week at available bandwidth) or when you have 10TB+ with limited connectivity. The break-even point depends on your bandwidth — calculate transfer time first.
How do I start a migration to AWS?
Follow the migration lifecycle: (1) Assess — Deploy Discovery Agent/Agentless Collector, gather data in Migration Hub, evaluate TCO with Migration Evaluator. (2) Decide strategy — Apply 7Rs per application (most will be Rehost initially). (3) Set up landing zone — Control Tower for multi-account, networking, security baseline. (4) Pilot — Migrate 2-3 simple apps to validate process. (5) Scale — Migration Factory for remaining waves.