The status checks automatically performed on Amazon EC2 instances are:

• System Status Checks: These check the underlying systems used by the Amazon EC2 instance
• Instance Status Checks: These check the configuration of the specific instance

See documentation: Status Checks for Your Instances

Often, an instance is available and ready to be used before these checks are complete -- this is especially the case for Linux instances because they boot very quickly.

If you receive a 1/2 checks passed message, either wait a little longer or Stop and Start the instance. Performing a Stop/Start will launch the instance on a different host, which will probably fix whatever problem was being experienced.

If the 1/2 checks passed message continues to appear after a Stop/Start, it is probably a misconfiguration of the AMI. I have seen this when the wrong virtualization type was selected for an AMI that was created from a Snapshot.

You might be able to get a hint about the problem by using the Get System Log command in the Actions menu, which shows the log while the instance is booting.

Worst case, launch a new instance from a known-good AMI, attach the non-booting volume as an additional disk and copy files to the new disk. You will still have access to your files even if it will not boot.

Hello. It sounds like you're encountering several issues with your Debian instance, particularly around SSH connectivity, instance status checks, and command execution errors Please follow below steps. **Check System Logs** * Go to the EC2 Console. * Select your instance. * Click on Actions > Monitor and troubleshoot > Get System Log. * Look for any error messages that might indicate what's wrong. **Stop and Start the Instance** * This action will migrate your instance to new hardware and might resolve underlying issues. * In the EC2 Console, select your instance. * Click on Instance State > Stop. * Once stopped, click on Instance State > Start. **Reinstall Basic Packages** * If you can SSH into your instance (even if it's slow), run the following commands to ensure basic utilities are installed ``` sudo apt update sudo apt install --reinstall coreutils ``` **Check PATH Variable** * If you see errors like -bash: id: command not found, it might indicate a problem with your PATH. Run ``` echo $PATH ``` * If it’s incorrect, temporarily fix it with ``` export PATH=$PATH:/usr/bin:/bin ``` **Monitor Resource Utilization** * Use the command top to check CPU and memory usage. * If the instance is overloaded, consider resizing it to a larger instance type. **Create a New Instance** * If the issues persist, consider launching a new instance from a known good AMI (Amazon Machine Image). * Reinstall your necessary software step by step to identify any potential issues. https://repost.aws/knowledge-center/ec2-linux-status-check-failure https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-serial-console.html

When you see an instance failing status checks, try stopping and starting the instance. If the source of the problem was something like the underlying hardware, this approach will typically fix those transient issues. If you see this problem consistently, then it's likely something that you're running inside the instance that is causing it to be unreachable. More details on what the status checks are actually checking here.

Here, you can find a full list of reasons why status checks fail and how can you enable alarms too which can initiate recovery.

https://aws.amazon.com/premiumsupport/knowledge-center/ec2-linux-status-check-failure/

AWS provides excellent documentation on pretty much everything they do.

There are two types of status checks: system status checks and instance status checks.

System Status Checks

Monitor the AWS systems on which your instance runs. These checks detect underlying problems with your instance that require AWS involvement to repair. When a system status check fails, you can choose to wait for AWS to fix the issue, or you can resolve it yourself. For instances backed by Amazon EBS, you can stop and start the instance yourself, which migrates it to a new host computer. For instances backed by instance store, you can terminate and replace the instance.

The following are examples of problems that can cause system status checks to fail:

• Loss of network connectivity
• Loss of system power
• Software issues on the physical host
• Hardware issues on the physical host that impact network reachability

Instance Status Checks

Monitor the software and network configuration of your individual instance. These checks detect problems that require your involvement to repair. When an instance status check fails, typically you will need to address the problem yourself (for example, by rebooting the instance or by making instance configuration changes).

The following are examples of problems that can cause instance status checks to fail:

• Failed system status checks
• Incorrect networking or startup configuration
• Exhausted memory
• Corrupted file system
• Incompatible kernel

I've had this happen as well -- the second health check is network connectivity, and until that gets sorted out SSH is not going to work (obviously). I would suggest

1. A full reboot of the instance from within the AWS console or AWS CLI.
2. You may also want to detach the elastic IP of the instance, wait a few seconds and then re-attach it.

You could also spin up a new EC2 instance in the same AZ, detach the volume from your unhealthy instance, and mount it as a secondary/tertiary volume in the new instance -- either to examine it, or to get out the scripts/files you need.

Sorry I can't give more concrete advice beyond that, but I am wondering if your /local/ partition has become unreadable?

There are 2 status checks performed against an EC2:

• System status checks - These checks are against the underlying physical host, such as a power failure or network failure.
• Instance status checks - These checks are against the VM itself, with issues such as a corrupted file system or failure with the virtual networking.

You can find out more information about the reasons for failure of status checks here.

It is possible to add autorecovery to the instance if it fails a system check, more steps can be found in this tutorial.

There will be individual metrics regarding which of these status checks failed within CloudWatch. The normal solution to resolve this is to stop and instance and then start it again. By doing this hard reboot you will had the instance migrate to another physical host (within the same subnet and AZ).

I would monitor several resources of your EC2 instance.

By default, you can only see CPU. If you install the CloudWatch Agent, you can collect additional metrics like RAM or Disk, which the hypervisor can't directly guess.

Then you can review the metrics around the time your instance fails, to check for some unexpected resource consumption.

I've had some issues in the past, where the lack of freeable RAM resulted in a similar behavior as the one you are describing.