A. Use AWS SMS to replicate the database to AWS and create an Amazon EC2 instance. Replicate the client VMs into AWS using AWS SMS. Place the EC2 instances behind an Application Load Balancer (ALB).
B. Use AWS DMS to migrate the database to Amazon RedShift. Migrate the Java-based web application to an AWS Elastic Beanstalk environment behind an Application Load Balancer (ALB).
C. Use AWS SMS to replicate the database to AWS and create an Amazon EC2 instance. Migrate the Java-based web application to an AWS Elastic Beanstalk environment behind an Application Load Balancer (ALB).
D. Use AWS DMS to migrate the database to Amazon RDS. Replicate the client VMs into AWS using AWS SMS. Create Route 53 Alias records for each client VM.
Solution
Explanation
The client VMs these can be migrated using AWS Server Migration Service (DMS) which will replicate the existing operating systems into AWS. Amazon EC2 instances can then be created from the AMIs that SMS creates. This solution ensures that the stored procedures and query results in the file system is not lost and this will reduce the operational burden on staff after the migration. The client instances should not be behind a ELB as they have different configurations therefore Route 53 Alias records can be created to connect directly to each instance. Oracle Data Warehouses can be migrated to RedShift using DMS and the Schema Conversion Tool (SCT). The question does not explicitly state that this is a data warehouse nor that the SCT should be used. The client EC2 instances should not be behind an ALB as they each have different configurations. To lower operational overhead on the DB it can be migrated to RDS.
A. Launch an Amazon RDS Aurora MySQL DB instance and use AWS DMS to migrate the on-premises database.
B. Launch an RDS Aurora MySQL DB instance and load the database data from the Snowball export. Configure replication from the on-premises database to the RDS Aurora instance using the VPN.
C. Export the data from the database using database-native tools and import the data to AWS using AWS Snowball.
D. Use AWS SMS to import the on-premises database into AWS and then use AWS DMS to synchronize the database with an Amazon Aurora MySQL DB instance.
E. When the RDS Aurora MySQL database is fully synchronized, change the DNS entry to point to the Aurora DB instance and stop replication.
F. Launch an AWS DMS instance and configure it with the on-premises and Aurora DB instance information. Replicate using AWS DMS over the VPN connection.
Solution
Explanation
“Launch an AWS DMS instance and configure it with the on-premises and Aurora DB instance information. Replicate using AWS DMS over the VPN connection” is incorrect. It would take far too long to migrate the entire 25 TB database over a 50 Mbps internet connection. The internet connection is too slow to migrate this database within the 2 week timeframe. Therefore, another method must be used that migrates it within the timeframe whilst avoiding downtime as much as possible. The best approach to this situation is to use a database export and migrate the exported data to AWS using AWS Snowball. Once migrated into the AWS Cloud, the data can be loaded into a newly launched Amazon Aurora MySQL DB instance. Native SQL replication can then be used to synchronize the databases with any changes. Once the Aurora DB instance is in sync with the on-premises DB instance the DNS entry can be changed to point to the Aurora DB instance and the application will start to use the Aurora DB instance.
References
1. https://aws.amazon.com/snowball/