Which data transfer strategy meets these requirements with the LEAST amount of application downtime?
Take the application offline. Create a local backup of the database. Transmit the database backup file over the existing connection to an Amazon S3 bucket. Use native database tools to restore the backup onto the new database and to set up replication to capture any changes since the backup. Modify the database connection string, and bring the application online.
Install the Server Migration Connector VM in the local data center. Use the AWS Server Migration Service (AWS SMS) console to replicate the on-premises database to the new database. Modify DNS records to point to the new database.
Create a local backup of the database, and copy the backup onto an AWS Snowcone device. Activate the AWS DataSync agent on the device, and configure the agent to copy the backup and ongoing changes to an Amazon S3 bucket. Use AWS Backup to restore the backup onto the new database and to apply the changes. Modify DNS records to point to the new database.
Use AWS Database Migration Service (AWS DMS) to launch a replication instance in a connected VPC. Use the AWS Schema Conversion Tool to extract the data locally and to move the data to an AWS Snowball Edge Storage Optimized device. Ship the device to AWS, and use an AWS DMS task to complete the transfer to the target database. For the migration type, choose the option to migrate existing data and replicate ongoing changes. Modify DNS records to point to the new database.
Explanations:
This option requires taking the application offline for the initial backup, which leads to application downtime. Although it suggests restoring the backup and setting up replication, the downtime during the backup process can be significant given the large database size (50 TB) and the daily growth rate (5 GB), making this option less suitable for minimizing downtime.
AWS Server Migration Service (AWS SMS) is primarily used for server migrations, not for database migrations. Additionally, it doesn’t provide a means to minimize downtime effectively, as it may not support the continuous data replication needed to keep the application online during the transfer process.
While using AWS Snowcone for data transfer minimizes the amount of data sent over the network, the process still requires creating a backup and can lead to downtime during the initial backup. The need for ongoing changes to be applied after the backup also complicates the process, increasing downtime.
This option uses AWS Database Migration Service (AWS DMS), which allows for minimal downtime during the migration. By shipping an AWS Snowball Edge device to transfer the initial data and using DMS to handle ongoing changes, this option effectively minimizes application downtime and meets the requirement to complete the migration within 21 days.
I strategize that the answer is:
Use AWS Database Migration Service (AWS DMS) to launch a replication instance in a connected VPC. Use the AWS Schema Conversion Tool to extract the data locally and to move the data to an AWS Snowball Edge Storage Optimized device. Ship the device to AWS, and use an AWS DMS task to complete the transfer to the target database. For the migration type, choose the option to migrate existing data and replicate ongoing changes. Modify DNS records to point to the new database.