What should the solutions architect do to meet these requirements?
Create a read replica of the Aurora Serverless v1 database in the target Region. Use AWS SAM to create a runbook to deploy the solution to the target Region. Promote the read replica to primary in case of disaster.
Change the Aurora Serverless v1 database to a standard Aurora MySQL global database that extends across the source Region and the target Region. Use AWS SAM to create a runbook to deploy the solution to the target Region.
Create an Aurora Serverless v1 DB cluster that has multiple writer instances in the target Region. Launch the solution in the target Region. Configure the two Regional solutions to work in an active-passive configuration.
Change the Aurora Serverless v1 database to a standard Aurora MySQL global database that extends across the source Region and the target Region. Launch the solution in the target Region. Configure the two Regional solutions to work in an active-passive configuration.
Explanations:
Aurora Serverless v1 does not support cross-region read replicas, so creating a read replica in another Region is not possible. Additionally, promoting the read replica would likely require more than 5 minutes, making it unsuitable for the required RTO of 5 minutes.
Aurora Serverless v1 does not support global databases. Only Aurora MySQL and Aurora PostgreSQL standard databases support cross-region replication. This option also requires more than just changing the database to a global setup; it would require re-architecting the solution.
Aurora Serverless v1 cannot be configured with multiple writer instances in different Regions. Aurora Serverless only has a single writer in a given Region, so this approach is not feasible.
Aurora MySQL global database supports cross-region replication, with a low-latency, automatic failover mechanism that can meet the RTO of 5 minutes and RPO of 1 minute. This solution allows for disaster recovery between two Regions with active-passive configurations. Using AWS SAM for deployment automation is appropriate for maintaining consistency across Regions.
I weigh that the answer is:
Change the Aurora Serverless v1 database to a standard Aurora MySQL global database that extends across the source Region and the target Region. Launch the solution in the target Region. Configure the two Regional solutions to work in an active-passive configuration.