Which solution will achieve the company’s goal with the LEAST operational overhead?
Install the AWS Replication Agent on the source servers, including the MySQL servers. Set up replication for all servers. Launch test instances for regular drills. Cut over to the test instances to fail over the workload in the case of a failure event.
Install the AWS Replication Agent on the source servers, including the MySQL servers. Initialize AWS Elastic Disaster Recovery in the target AWS Region. Define the launch settings. Frequently perform failover and fallback from the most recent point in time.
Create AWS Database Migration Service (AWS DMS) replication servers and a target Amazon Aurora MySQL DB cluster to host the database. Create a DMS replication task to copy the existing data to the target DB cluster. Create a local AWS Schema Conversion Tool (AWS SCT) change data capture (CDC) task to keep the data synchronized. Install the rest of the software on EC2 instances by starting with a compatible base AMI.
Deploy an AWS Storage Gateway Volume Gateway on premises. Mount volumes on all on-premises servers. Install the application and the MySQL database on the new volumes. Take regular snapshots. Install all the software on EC2 Instances by starting with a compatible base AMI. Launch a Volume Gateway on an EC2 instance. Restore the volumes from the latest snapshot. Mount the new volumes on the EC2 instances in the case of a failure event.
Explanations:
This option involves installing the AWS Replication Agent on source servers and setting up replication, but it does not leverage AWS Elastic Disaster Recovery, which automates failover and simplifies management. It also requires manual processes for testing and failover, increasing operational overhead.
This option utilizes the AWS Replication Agent and AWS Elastic Disaster Recovery, which allows for automatic replication and simplified failover processes. It minimizes operational overhead by managing failover and fallback procedures effectively, making it a strong choice for business continuity.
This option focuses on migrating the database to Amazon Aurora MySQL and requires setting up replication tasks with AWS DMS and AWS SCT, which involves more complexity and operational overhead. Additionally, it does not directly address the entire application stack’s failover needs.
This option involves deploying an AWS Storage Gateway and requires more manual intervention to set up volumes and restore applications. While it provides backup capabilities, it does not streamline the failover process as effectively as AWS Elastic Disaster Recovery, resulting in higher operational overhead.
I strategize that the answer is:
Install the AWS Replication Agent on the source servers, including the MySQL servers. Initialize AWS Elastic Disaster Recovery in the target AWS Region. Define the launch settings. Frequently perform failover and fallback from the most recent point in time.