Which solution will meet these requirements?
Add the instance to an EC2 Auto Scaling group with the minimum, maximum, and desired capacity set to 1.
Add the instance to an EC2 Auto Scaling group with a lifecycle hook to detach the EBS volume when the EC2 instance shuts down or terminates.
Create an Amazon CloudWatch alarm for the StatusCheckFailed_System metric and select the EC2 action to recover the instance.
Create an Amazon CloudWatch alarm for the StatusCheckFailed_Instance metric and select the EC2 action to reboot the instance.
Explanations:
While adding the instance to an Auto Scaling group allows for quick recovery, simply setting the capacity to 1 does not provide redundancy or rapid recovery from network or power issues. It does not automatically replace the instance or minimize data loss effectively.
Adding a lifecycle hook to detach the EBS volume when the EC2 instance shuts down or terminates does not address quick recovery from connectivity or power failures. It could complicate recovery processes by requiring manual intervention to reattach the volume to a new instance.
Creating a CloudWatch alarm for the StatusCheckFailed_System metric and using the EC2 action to recover the instance is the best solution. This setup enables automatic recovery of the instance if it fails due to underlying system issues, thus minimizing downtime and data loss.
A CloudWatch alarm for the StatusCheckFailed_Instance metric and rebooting the instance may not address all issues, especially if the problem is due to underlying system failures rather than the instance itself. This solution may not guarantee a quick recovery with minimal data loss.
If I had to guess, I’d say the answer is:
Create an Amazon CloudWatch alarm for the StatusCheckFailed_System metric and select the EC2 action to recover the instance.