Inside Amazon EC2, there are two types of status check: System Status Checks and Instance Status Checks.
Errors in these will indicate different issues, and you should recover from them differently.
This topic discusses the System and Instance Status Checks and how to recover from these checks.
System Status Checks Failed
The System Status Checks monitor all the AWS systems that your instances run on. So this includes all of the back-end, networking, power, hypervisor, and everything else that you as a customer don’t have access to in the Shared responsibility model.
So some of the reasons that you might see a failure in the System Status Checks are:
Loss of network connectivity
Loss of system power
Software issues on physical host
Hardware issues on the physical host that impact network reachability
If there’s a failure because of a loss of network connectivity, or power, there’s really nothing we can do about it because AWS will have to correct that themselves.
However, we can resolve failures in a couple of ways:
For EBS-Backed instances, we can stop and start instance to obtain new hardware
For instance store-backed instances, we have to terminate and replace the instance to place on new hardware. Remember, we can’t stop instance store volumes so that data will be lost unless you’ve previously backed it up.
Instance Status Checks Failed
For Instance Status Checks, these are the things that we do have control over. It’ll monitor the networking software configuration on an instance, you have to intervene yourself to fix any issues.
And some of the reasons for failures might be:
Failed system status checks
Incorrect networking or startup configuration
Corrupted file system
To resolve any of these issues, you will have to make instance configuration changes or potentially reboot the instance.
EC2 Instance Status Checks on AWS CLI
We can also perform the same status checks from the AWS command line interface (CLI).
Here we can invoke:
aws ec2 describe-instance-status
This will give us a list of all of our EC2 instances within the region including the InstanceId, the InstanceState and the InstanceStatus. If any of the status checks fail, you might see a status such as impaired.
You can also check a particular EC2 instance by adding the InstanceId to the previous command:
aws ec2 describe-instance-status –instance-ids i-0a841fba0a4225f5f
Or apply a filter to these values by the following command:
aws ec2 describe-instance-status –filters Name=instance-status.status,Values=ok
aws ec2 describe-instance-status –filters Name=instance-status.status,Values=impaired
Basically, that’s all you need to know about EC2 Status Checks, just keep in mind that System Status Checks are within AWS control and Instance Status Checks are within your control, and your responsibility to correct.
About VTI Cloud
VTI Cloud is an Advanced Consulting Partner of AWS Vietnam with a team of over 50+ AWS certified solution engineers. With the desire to support customers in the journey of digital transformation and migration to the AWS cloud, VTI Cloud is proud to be a pioneer in consulting solutions, developing software, and deploying AWS infrastructure to customers in Vietnam and Japan.
Building safe, high-performance, flexible, and cost-effective architectures for customers is VTI Cloud’s leading mission in enterprise technology mission.
In addition, VTI Cloud supports building VIET-AWS community. This group is one of the fast-growing AWS User Groups and officially recognized by Amazon in the Asia Pacific (Vietnam) region.
VIET-AWS is a place to connect and exchange support between Solutions Architect, DevOps, SysOps, and budding students with cloud computing services of Amazon Web Services (AWS). Join VTI Cloud to join VIET-AWS: https://www.facebook.com/groups/vietawscommunity