- 최신
- 최다 투표
- 가장 많은 댓글
Thanks for your response. I have now created CloudWatch Alarms for each of the failing instances and selected Reboot as the associated Action (because there was no option to Stop and then Start an instance). But I am not sure that Reboot will work when the instance freezes. I have also had to associate Elastic IP addresses with these two instances because the Public IP address of each instance changes whenever I Stop and then Start an instance. Is it normal for the Public IP address of an instance to be changed like this after Stop/ Start, or is this peculiar to specific Availabilty Zones/ Regions?
Unfortunately, from time to time, an EC2 instance will fail - and sometimes more than one at once, if there is an incident that impacts an entire rack of servers or more.
There are multiple strategies for performing automated recovery of failed EC2 instances that are discussed in our documentation. Simplified automatic recovery works in many - but not all - circumstances. We recommend configuring CloudWatch Alarms to detect and recover when system status checks fail.
If you have not terminated the failed instance - or if you have terminated it, but opted to preserve the EBS volumes associated with it when you created it - you may be able to locate the original EBS volume and attach it to an instance to examine the logs for troubleshooting purposes.
Public IP addresses associated with an instance that are not Elastic IPs are recycled when the instance stops. If you want a persistent public IP address to be associated with an instance, you must create an EIP and associate it with the instance's network interface after starting it.
In general, I recommend using EC2 Auto Scaling instead of CloudWatch alarms to manage instance health. You can create an Auto Scaling Group with a fixed size (for example, 2 in your case) and the service will automatically terminate and relaunch failed instances.