What architectural changes will minimize downtime and reduce the chance of lost data?
Create an Amazon CloudWatch alarm to automatically recover the instance. Create a script that will check and repair the database upon reboot. Subscribe the Operations team to the Amazon SNS message generated by the CloudWatch alarm.
Run the application on m4.xlarge EC2 instances behind an Elastic Load Balancer/Application Load Balancer. Run the EC2 instances in an Auto Scaling group across multiple Availability Zones with a minimum instance count of two. Migrate the database to an Amazon RDS Oracle Multi-AZ DB instance.
Run the application on m4.2xlarge EC2 instances behind an Elastic Load Balancer/Application Load Balancer. Run the EC2 instances in an Auto Scaling group across multiple Availability Zones with a minimum instance count of one. Migrate the database to an Amazon RDS Oracle Multi-AZ DB instance.
Increase the web server instance count to two m4.xlarge instances and use Amazon Route 53 round-robin load balancing to spread the load. Enable Route 53 health checks on the web servers. Migrate the database to an Amazon RDS Oracle Multi-AZ DB instance.
Explanations:
While setting up a CloudWatch alarm and automatic recovery can help with instance availability, it does not address the underlying issue of data loss during downtime. The database repair script could also lead to inconsistencies if not managed properly. This option does not provide a robust solution for minimizing downtime or ensuring data integrity.
This option provides high availability and fault tolerance by using an Auto Scaling group across multiple Availability Zones, which ensures that the application remains accessible during instance failures. Migrating the database to Amazon RDS Oracle Multi-AZ enhances data redundancy and availability, allowing for automatic failover and reducing the risk of data loss.
Although this option includes running EC2 instances in an Auto Scaling group and migrating to Amazon RDS Oracle Multi-AZ, having a minimum instance count of one does not provide true redundancy. If that single instance fails, the application will still experience downtime, which contradicts the goal of minimizing downtime and preventing data loss.
Increasing the web server instance count and using Route 53 for load balancing does provide some level of redundancy, but it lacks the automatic scaling and health checks of an Auto Scaling group. Additionally, it does not address the database management aspect, which is critical for preventing data loss. Migrating to Amazon RDS Oracle Multi-AZ is beneficial but insufficient alone for minimizing downtime in this context.
I surmise that the answer is:
Run the application on m4.xlarge EC2 instances behind an Elastic Load Balancer/Application Load Balancer. Run the EC2 instances in an Auto Scaling group across multiple Availability Zones with a minimum instance count of two. Migrate the database to an Amazon RDS Oracle Multi-AZ DB instance.