4 of the 10 questions we have for this objective, shown with the answer and the reasoning.
Determine the optimal migration approach for existing workloads
Ardent Genomics must move 400 TB of sequencing data from its data center to Amazon S3 during a migration program that runs from February to March 2027, a period of 60 days. The data center has a 500 Mbps internet connection that is already 60 percent utilized by production traffic. The data must not traverse the public internet, and after the migration the company will keep sending about 2 TB per day of new sequencing output to AWS.
Which approach should the solutions architect recommend?
- AEnable S3 Transfer Acceleration on the target bucket and upload the data over the existing internet connection.Transfer Acceleration improves long-distance throughput through edge locations, but it cannot exceed the roughly 200 Mbps of free local bandwidth, which would take about 185 days for 400 TB, and the traffic would cross the internet.
- BOrder a 10 Gbps AWS Direct Connect connection now, and when it is available run AWS DataSync over it to an S3 bucket by using a DataSync VPC interface endpoint.At about 70 percent of 10 Gbps the link moves roughly 75 TB per day, so 400 TB takes under a week, leaving time for verification. Direct Connect with a private DataSync endpoint keeps data off the internet and also serves the ongoing 2 TB per day.
- CCreate an AWS Site-to-Site VPN over the internet connection and run DataSync through the tunnel.A VPN encrypts traffic but still rides on the same 500 Mbps internet link, so the transfer would take months and the traffic would still traverse the public internet.
- DOrder AWS Snowball Edge devices for the 400 TB and use the internet connection for new output.Snowball Edge is no longer offered to new customers, and AWS ends support for Snowball devices in commercial Regions on December 31, 2026, before this program starts. Sending 2 TB per day of new output over the internet would also use nearly all of the free bandwidth and break the no-internet rule.
Why: Start with the math. 400 TB over 60 days needs a sustained rate of about 620 Mbps, which the 200 Mbps of free internet capacity cannot deliver, and the policy rules out the internet anyway. A dedicated Direct Connect connection solves both the deadline and the privacy constraint, and it is the right long-term path for 2 TB per day of new data. Direct Connect has a lead time of weeks, so it must be ordered well before the program begins; a hosted connection from a Direct Connect partner is an option when lead time is tight. DataSync then provides parallel, verified transfers through a private VPC endpoint.
Determine the optimal migration approach for existing workloads
Quillon Media will rehost 150 servers to Amazon EC2: 90 VMware VMs, 40 Hyper-V VMs, and 20 physical Linux hosts. Each application can be offline for no more than 30 minutes at cutover, and the team wants to launch non-disruptive test instances before each wave.
Which service should the solutions architect use to move the servers?
- AVM Import/ExportVM Import/Export converts an exported disk image into an AMI. It does not continuously replicate changes, so each server would be offline while its image is exported, uploaded, and imported, and it cannot handle the physical hosts.
- BAWS Transform MGN (formerly AWS Application Migration Service)AWS Transform MGN replicates block-level changes continuously from any source, physical or virtual, and supports test launches and a short cutover once replication is current.
- CAWS DataSyncDataSync moves files and objects between storage systems. It does not replicate operating systems or produce bootable EC2 instances.
- DAWS Database Migration ServiceDMS migrates database contents between engines or instances. It does not migrate whole application servers.
Why: AWS Transform MGN is the recommended rehosting service because its agent works at the block level, independent of hypervisor, and keeps the target in sync until cutover. Test launches let teams validate each wave without stopping the source, and cutover time is limited to the final sync and launch. VM Import/Export remains useful for one-off image conversions but has no continuous replication, which is what the 30-minute downtime limit requires.
Determine the optimal migration approach for existing workloads
Breton Games runs a 2 TB MongoDB database for player profiles as a three-member replica set on premises and will move it to Amazon DocumentDB. The game must stay online during the migration, with no more than 5 minutes of write downtime at cutover. A Site-to-Site VPN connects the data center to the target VPC.
Which approach should the solutions architect recommend?
- AUse mongodump to export the database, copy the files to Amazon EC2, and use mongorestore into DocumentDB during a maintenance window.An offline dump and restore requires stopping writes for the full export and import of 2 TB, which far exceeds the 5-minute limit.
- BCreate an AWS DMS task with a MongoDB source endpoint and a DocumentDB target endpoint that performs a full load plus ongoing replication, then cut over when latency is near zero.DMS supports MongoDB as a source and DocumentDB as a target. Because the source is a replica set, DMS can read the oplog for change data capture and keep DocumentDB current until cutover.
- CConvert the schema with AWS DMS Schema Conversion and load the data with a full-load-only task.Schema conversion targets relational engine changes and is not used for MongoDB to DocumentDB, and a full-load-only task does not capture changes made while it runs.
- DAdd a DocumentDB instance to the on-premises replica set as a secondary member and promote it at cutover.DocumentDB is a managed service that implements the MongoDB API. It cannot join a self-managed MongoDB replica set.
Why: Online database migrations combine a bulk copy with change data capture, and the source must support a change mechanism. For MongoDB, AWS DMS uses the oplog, which exists only on replica sets, so the three-member replica set here makes CDC possible. A full load plus ongoing replication task keeps DocumentDB in sync, and cutover needs only a brief pause in writes. Offline dump and restore is simpler but its downtime grows with data size.
Determine the optimal migration approach for existing workloads
Pinehurst Travel runs a 6 TB MySQL 8.0 database on an on-premises Linux server and will move it to Amazon Aurora MySQL-Compatible Edition version 3. The booking site can stop writes for no more than 10 minutes at cutover. A logical export of the database took 19 hours in a recent test, and a Direct Connect link to AWS is in place.
Which two actions should the solutions architect include in the migration plan? Each correct answer presents part of the solution.
- ATake a physical backup with Percona XtraBackup, upload it to Amazon S3, and restore a new Aurora MySQL DB cluster from the S3 backup.Aurora MySQL can create a cluster from a Percona XtraBackup physical backup stored in S3, which is much faster than a logical export and import for a 6 TB database.
- BConfigure the Aurora cluster as a binary log replica of the on-premises MySQL server, starting from the backup's binary log position, and cut over when replica lag is zero.Binary log replication from an external MySQL source applies changes made after the backup, so the cutover only needs a short pause in writes while the last changes replicate.
- CRun mysqldump during the cutover window and import the output into Aurora.A logical export already took 19 hours in testing, which is far beyond the 10-minute write outage.
- DUse AWS DMS Schema Conversion to convert the MySQL schema to Aurora MySQL before loading data.This is a homogeneous migration; Aurora MySQL is compatible with MySQL, so no schema conversion is needed.
- ECreate an Aurora read replica directly from the on-premises MySQL server in the Amazon RDS console and promote it at cutover.The console creates Aurora read replicas only from Amazon RDS for MySQL DB instances, not from an external server. External sources use binary log replication configured on the Aurora cluster.
Why: For a large homogeneous MySQL migration with a tight cutover, the pattern is a fast bulk copy followed by continuous replication. A physical XtraBackup restored from S3 avoids the hours of a logical dump, and binary log replication from the source keeps Aurora current until the switch, so downtime depends only on the final catch-up. AWS DMS with full load and CDC is another valid path for homogeneous moves, but schema conversion tools are meant for heterogeneous engine changes, and Aurora read replicas created from the console require an RDS for MySQL source.