A company runs a global web application on Amazon EC2 instances behind an Application Load Balancer. The application stores data in Amazon Aurora. The company needs to create a disaster recovery solution and can tolerate up to 30 minutes of downtime and potential data loss. The solution does not need to handle the load when the primary infrastructure is healthy.
What should a solutions architect do to meet these requirements?
A. Deploy the application with the required infrastructure elements in place. Use Amazon Route 53 to configure active-passive failover. Create an Aurora Replica in a second AWS Region.
B. Host a scaled-down deployment of the application in a second AWS Region. Use Amazon Route 53 to configure active-active failover. Create an Aurora Replica in the second Region.
C. Replicate the primary infrastructure in a second AWS Region. Use Amazon Route 53 to configure active-active failover. Create an Aurora database that is restored from the latest snapshot.
D. Back up data with AWS Backup. Use the backup to create the required infrastructure in a second AWS Region. Use Amazon Route 53 to configure active-passive failover. Create an Aurora second primary instance in the second Region.
The correct answer is A. Deploy the application with the required infrastructure elements in place. Use Amazon Route 53 to configure active-passive failover. Create an Aurora Replica in a second AWS Region.
This solution meets the company’s requirements for a disaster recovery solution that can tolerate up to 30 minutes of downtime and potential data loss, and does not need to handle the load when the primary infrastructure is healthy. The active-passive failover configuration with Amazon Route 53 ensures that traffic is only routed to the secondary (disaster recovery) site if the primary site becomes unavailable. The Aurora Replica in a second AWS Region provides a standby database that can be promoted to a primary in the event of a disaster. This setup provides a balance between cost efficiency and recovery time objectives.
A scaled-down deployment of an application refers to a version of the application that is designed to run with fewer resources than the full-scale version. This could mean running on fewer servers, using less storage, or handling a smaller number of requests per second.
The purpose of a scaled-down deployment is often to save costs while still maintaining a functional version of the application. This can be useful in scenarios such as disaster recovery, where the scaled-down version can take over if the primary application fails, or for testing and development purposes, where a full-scale deployment might not be necessary.
However, it’s important to note that a scaled-down deployment may not be able to handle the same level of traffic or provide the same performance as the full-scale version. Therefore, it’s crucial to consider the specific needs and constraints of your application when deciding whether a scaled-down deployment is appropriate.