Study guide
Technical reference and lesson notes
Purpose of This Lesson
AWS migration and transfer questions typically test service selection. The key decisions are whether you are moving servers, databases, files, or very large datasets—and whether the transfer should occur online, offline, continuously, or with processing at the edge.
This guide covers the migration patterns associated with AWS Server Migration Service (SMS), AWS Database Migration Service (AWS DMS), AWS DataSync, and the AWS Snow Family.
> Current-service note: AWS Server Migration Service is a legacy service. For new server-migration designs, evaluate AWS Application Migration Service (AWS MGN) first. Older exam material and scenarios may still refer to SMS concepts such as agentless VM replication and AMI-based migration.
Key Concepts
Server migration with AWS SMS and AWS MGN
The legacy AWS Server Migration Service (SMS) was designed to migrate on-premises or cloud-hosted virtual machines to AWS without installing an agent inside each guest operating system. It supported source environments such as:
- VMware
- Microsoft Hyper-V
- Microsoft Azure
A connector was installed in the source virtualization environment. Server volumes were replicated securely, converted into Amazon Machine Images (AMIs), and used to launch Amazon EC2 instances. Replication was incremental after the initial copy, reducing the amount of data transferred during subsequent cycles.
SMS also supported grouping related servers and launching them through an AWS CloudFormation stack. This was useful when an application consisted of multiple coordinated servers rather than a single independent VM.
For current architectures, AWS MGN is the service to investigate for lift-and-shift server migration. MGN uses replication infrastructure and supports continuous replication, test launches, and cutover workflows. The precise capabilities and quotas of legacy SMS should not be assumed to apply to MGN.
Database migration with AWS DMS
AWS Database Migration Service (AWS DMS) migrates databases while the source application remains online. It performs an initial load and can continuously replicate ongoing changes, allowing a cutover with substantially less downtime than an offline export and import.
DMS can migrate databases from environments such as:
- On-premises databases
- Databases hosted on Amazon EC2
- Amazon RDS databases
- Other supported cloud database environments
DMS supports both:
- Homogeneous migrations: Oracle to Oracle, MySQL to MySQL, or PostgreSQL to PostgreSQL
- Heterogeneous migrations: Oracle to PostgreSQL, Oracle to Amazon Aurora PostgreSQL-Compatible, or SQL Server to MySQL
For heterogeneous migrations, AWS Schema Conversion Tool (AWS SCT) may be required to convert database schemas, stored procedures, views, and other engine-specific objects. DMS handles data movement and replication; SCT addresses schema and code compatibility.
Common DMS patterns include:
- On-premises to AWS database migration
- Amazon EC2 to Amazon RDS
- RDS to RDS
- RDS to Amazon Aurora
- Database consolidation from multiple sources into one target
- Continuous replication for disaster recovery or development and test
- One source to multiple targets, where supported by the design
- Multiple sources consolidated into one target
DMS pricing is based primarily on the replication instance and related storage or data-transfer considerations. Select replication capacity based on workload size, change rate, migration duration, and target requirements.
File and object transfer with AWS DataSync
AWS DataSync is intended for moving file-based data between on-premises storage and AWS. A DataSync agent connects to storage such as a Network Attached Storage (NAS) system using:
- NFS
- SMB
DataSync transfers data over the network using encrypted connections and can run on a schedule or as an automated recurring task. Typical AWS destinations include:
- Amazon S3
- Amazon EFS
- Amazon FSx for Windows File Server
DataSync is a strong fit when the source is file storage and the organization needs managed, repeatable transfers rather than writing a custom copy application. It can preserve file permissions and metadata when the selected source and destination combination supports those attributes.
DataSync is charged based on the amount of data transferred. Network connectivity, available bandwidth, file count, and small-file overhead affect practical performance.
Snow Family for physical transfer and edge processing
The AWS Snow Family provides secure physical devices for moving data when network transfer is too slow, too expensive, or unavailable. Snow devices can also process and store data at remote or disconnected locations.
#### Snowball Edge
Snowball Edge devices provide local storage and computing capabilities. Depending on the configuration, they can provide:
- S3-compatible object storage
- Block storage
- Local compute
- Optional GPU capabilities on appropriate configurations
Typical uses include:
- Large-scale data transfer
- Data collection at remote sites
- Machine learning inference or preprocessing at the edge
- Manufacturing and industrial workloads
- Processing in environments with intermittent connectivity
Snowball Edge configurations are commonly described as Storage Optimized or Compute Optimized. Always verify current device capacities and supported features in AWS documentation because device models, capacity limits, and naming evolve.
#### Snowcone
AWS Snowcone is a smaller, portable device for edge storage, lightweight compute, and data transfer. Data can be transferred online or offline. For online transfer, the AWS DataSync agent can be used with the device.
Snowcone is better suited to smaller datasets and constrained remote environments than Snowball Edge.
#### Snowmobile
AWS Snowmobile is designed for extremely large migrations—typically exabyte-scale projects. It is a secure shipping container brought to the customer site for transferring massive data volumes. It is not the normal choice for a departmental or ordinary enterprise migration.
Snow Family security and transfer workflow
Snow devices are designed for secure physical transport. The general workflow is:
- Order the appropriate device.
- Receive and connect it at the source location.
- Use Snow client software or supported interfaces to identify and copy data.
- Compress and encrypt data as appropriate.
- Ship the device back to AWS.
- AWS imports the data into the configured destination.
Security features include encryption, tamper-resistant hardware, and hardware security protections such as a Trusted Platform Module. AWS KMS keys can be used for encryption-key management. The exact key-management options depend on the Snow device and job configuration.
Improving Snowball transfer performance
For high-throughput transfers:
- Use the latest compatible Snow client.
- Copy multiple files concurrently.
- Use multiple workstations when appropriate.
- Copy directories rather than issuing a separate operation for every file.
- Bundle small files where practical because small-file overhead can reduce throughput.
- Preprocess, compress, tag, or filter data before shipment when this reduces the required transfer volume.
Exam-Relevant Takeaways
- Choose AWS DMS when the workload is a database and the source must remain online during migration.
- Choose AWS SCT when database-engine differences require schema or code conversion. SCT and DMS solve different parts of a heterogeneous migration.
- Choose AWS DataSync for scheduled or recurring online movement of file data between NFS/SMB storage and S3, EFS, or FSx for Windows File Server.
- Choose Snowball Edge when the dataset is large, network connectivity is limited, or local edge processing is required.
- Choose Snowcone for smaller, portable edge deployments or remote sites with constrained connectivity.
- Choose Snowmobile for extremely large, exabyte-scale data transfers.
- A physical device is not automatically the best answer. Compare the time and cost of network transfer against device shipping and operational handling.
- For server migration, distinguish legacy SMS from the current AWS MGN service in modern designs.
- DMS performs initial data loading plus change replication; it is not simply a one-time database backup utility.
- DataSync is not a general-purpose database replication service. Use DMS for database-aware migration and replication.
Architecture Decision Guide
| Requirement | Best-fit service or approach | Why |
|---|---|---|
| Migrate VMware, Hyper-V, or Azure VMs with a legacy agentless workflow | AWS SMS conceptually; evaluate AWS MGN for current implementations | Replicates server volumes and supports EC2 migration workflows |
| Lift and shift servers with ongoing replication and controlled cutover | AWS MGN | Purpose-built for application migration to AWS |
| Migrate an online database with minimal downtime | AWS DMS | Performs initial load and ongoing change replication |
| Convert Oracle database structures for PostgreSQL or Aurora PostgreSQL-Compatible | AWS SCT plus AWS DMS | SCT converts schema/code; DMS moves and replicates data |
| Copy NAS data over the network to Amazon S3 | AWS DataSync | Managed, automated file transfer from NFS/SMB storage |
| Copy files to Amazon EFS or FSx for Windows File Server | AWS DataSync | Supports recurring transfers to AWS file services |
| Move a large dataset from a site with poor connectivity | Snowball Edge | Physical transfer avoids a long network upload |
| Collect and process data at a disconnected factory or remote site | Snowball Edge or Snowcone | Provides local storage and edge capabilities |
| Move a smaller dataset from a remote location | Snowcone | Portable device designed for smaller edge scenarios |
| Move an extraordinarily large, exabyte-scale dataset | Snowmobile | High-capacity physical transfer infrastructure |
Common Exam Traps
- Confusing DMS with SCT: DMS moves and replicates data. SCT helps convert schemas and database code between engines.
- Using DataSync for database replication: DataSync is for file and object transfer, not transactionally aware database migration.
- Assuming all Snow devices have the same features: Storage capacity, compute, GPU support, and interface options vary by device and configuration.
- Choosing Snowball for every large transfer: If the network is fast and the dataset is moderate, online transfer may be simpler. Perform a transfer-time and cost analysis.
- Ignoring change data: A one-time database dump may create significant downtime. DMS ongoing replication supports a lower-downtime cutover.
- Treating NFS and SMB as interchangeable: The source protocol and target service determine whether permissions and metadata can be preserved.
- Overlooking small-file performance: Millions of small files can make transfers much slower than the aggregate data size suggests.
- Using legacy SMS as the default current answer: For new server-migration scenarios, assess AWS MGN and verify service availability and capabilities.
- Assuming physical transfer eliminates security requirements: Data still needs encryption, access control, key management, secure handling, and chain-of-custody procedures.
Real-World Engineer Notes
- Plan migration around the change rate, not only the total dataset size. A database with a high transaction rate may require more DMS replication capacity and a carefully timed cutover.
- Test DMS target behavior before production migration, especially indexes, constraints, triggers, sequences, stored procedures, and unsupported data types.
- For heterogeneous database migrations, estimate the manual remediation effort after SCT conversion. Automated conversion does not guarantee application compatibility.
- For DataSync, measure file count and directory structure in addition to total bytes. A large number of small files can dominate migration time.
- Establish network connectivity, routing, firewall rules, and IAM permissions before starting a migration task. Migration tools do not remove the need for source-to-target connectivity.
- Use a staged process for Snow devices: inventory, classify, encrypt, copy, validate, ship, and verify the imported data.
- Edge use cases may require local processing before data is sent to AWS. This can reduce bandwidth consumption and protect sensitive raw data.
- Confirm current Snow Family capacities, regional availability, supported interfaces, and encryption options before committing to a design.
Quick Reference Summary
- Servers: AWS MGN for current lift-and-shift migrations; legacy SMS used agentless VM replication and AMI-based launches.
- Databases: AWS DMS for initial load plus ongoing change replication.
- Schema conversion: AWS SCT for heterogeneous database migrations.
- Files: AWS DataSync for automated NFS/SMB transfers to S3, EFS, or FSx for Windows File Server.
- Large offline transfer: Snowball Edge.
- Small remote or edge device: Snowcone.
- Massive, exabyte-scale transfer: Snowmobile.
- Edge processing: Snowball Edge or Snowcone, depending on capacity and compute requirements.
Flashcards
- Q: What is the primary purpose of AWS DMS?
A: To migrate and continuously replicate databases with minimal application downtime.
- Q: What is the difference between homogeneous and heterogeneous database migration?
A: Homogeneous migration uses the same database engine on source and target; heterogeneous migration changes the engine.
- Q: Which AWS service helps convert an Oracle schema for PostgreSQL?
A: AWS Schema Conversion Tool, usually used together with AWS DMS for data movement.
- Q: What type of source storage is AWS DataSync designed to connect to?
A: File storage such as NFS or SMB-based NAS systems.
- Q: Name three common AWS DataSync destinations.
A: Amazon S3, Amazon EFS, and FSx for Windows File Server.
- Q: When is Snowball Edge preferable to an online transfer?
A: When the dataset is large and network bandwidth, connectivity, cost, or transfer time makes online migration impractical.
- Q: Which Snow Family device is intended for smaller portable edge deployments?
A: Snowcone.
- Q: Which Snow Family service targets exabyte-scale migrations?
A: Snowmobile.
- Q: What type of processing can Snowball Edge support at the edge?
A: Local data collection, preprocessing, analytics, and selected machine learning workloads.
- Q: Why can small files reduce Snowball transfer performance?
A: Per-file metadata and operation overhead can limit throughput even when the total byte volume is not large.
- Q: What did legacy AWS SMS produce from replicated server volumes?
A: AMIs that could be used to launch EC2 instances.
- Q: What is the modern AWS service to evaluate for server lift-and-shift migration?
A: AWS Application Migration Service, also called AWS MGN.
Practice Questions
Question 1
A company must migrate an Oracle database to Amazon Aurora PostgreSQL-Compatible. The source application must remain available during the migration, and the final outage must be limited to a short cutover window. Which approach is best?
A. Use AWS DataSync to copy the Oracle database files to Aurora
B. Use AWS SCT to convert the schema and AWS DMS to perform the initial load and ongoing replication
C. Use Snowball Edge to copy database files and restore them directly into Aurora
D. Use AWS Backup to create an Oracle backup and restore it to Aurora
Correct answer: B
Explanation: This is a heterogeneous, low-downtime database migration. AWS SCT assists with schema and code conversion, while AWS DMS performs data migration and change replication. DataSync and Snowball are not database-aware migration solutions, and an Oracle backup cannot simply be restored into Aurora PostgreSQL-Compatible.
Question 2
A research site has 500 TB of files on an on-premises NFS appliance. The site has intermittent connectivity and needs to transfer the data to Amazon S3. Which solution is most appropriate?
A. AWS DMS
B. AWS DataSync over the existing unreliable network only
C. Snowball Edge, with local copying and physical shipment to AWS
D. AWS SCT
Correct answer: C
Explanation: A large file dataset combined with intermittent connectivity is a strong Snowball Edge use case. DataSync is appropriate for online file transfer, but the connectivity constraint makes a physical transfer more reliable.
Question 3
An enterprise wants to synchronize an on-premises SMB file share with Amazon FSx for Windows File Server every night. Which service should be selected?
A. AWS DataSync
B. AWS DMS
C. AWS MGN
D. Snowmobile
Correct answer: A
Explanation: DataSync supports automated, scheduled transfers between SMB or NFS storage and AWS storage services such as FSx for Windows File Server. DMS is for databases, MGN is for server migration, and Snowmobile is excessive for a recurring file synchronization requirement.
Question 4
A company is migrating a multi-tier application from VMware to EC2. The application has several related servers that must be launched together, and the migration team wants incremental replication before cutover. Which legacy SMS capability addresses this requirement?
A. Database schema conversion
B. Application grouping and CloudFormation-based launch
C. NAS file synchronization
D. S3 multipart upload only
Correct answer: B
Explanation: Legacy SMS supported application groupings and could launch migrated servers through a CloudFormation stack. Incremental replication reduced repeated transfer requirements. For a current implementation, the organization should evaluate AWS MGN rather than relying on legacy SMS.
Question 5
A manufacturer collects sensor data at a factory with limited WAN bandwidth. It must filter and preprocess the data locally, then periodically send selected results to AWS. Which solution best fits?
A. Snowball Edge or Snowcone, selected according to capacity and compute needs
B. AWS DMS using a database replication instance
C. AWS SCT with an RDS target
D. DataSync without any local storage or processing component
Correct answer: A
Explanation: Snow Family devices support local storage and edge processing. Snowball Edge is appropriate for higher capacity or more demanding compute requirements; Snowcone is suitable for smaller, portable deployments. DMS and SCT are database migration tools, while DataSync alone does not provide the required edge-processing platform.