AWS CloudWatch の標準メトリックであるStatusCheckFailed_System, StatusCheckFailed_Instance の違いに関して説明します。場合によってはPING 監視の代替とすることも可能です。ある意味"システムステータスチェック"と"インスタンスステータスチェック"違いとも言えるでしょう。
比較は以下の表の通りとなります。
| 比較表 | StatusCheckFailed_System | StatusCheckFailed_Instance | StatusCheckFailed |
| 概要 | 物理ホストで問題が発生 AWS側の問題であり、利用者側の問題でない可能性が高い。 ただしEC2インスタンスを利用者がシャットダウンした場合は発生する。 | インスタンスのシステム的な問題。 （ネットワークの設定誤り、ソフトウェアの設定誤り、メモリ不足、ファイルシステムの破損、カーネルの問題） 利用者側の問題であり、AWS側の問題でない可能性が高い。 | StatusCheckFailed あるいは StatusCheckFailed_Instance のどちらかで問題が発生した場合にカウントされる。通常は両方のメトリックを監視するので、このメトリックだけを監視すればよい。 |
| 一言でいうと | システムステータスチェック | インスタンスステータスチェック | - |
| 例： | ・AWS側 でネットワーク障害や電源障害などが発生した。 ・インスタンスが停止している。 | 例：Windows では ipconfig /release で IPアドレスを解放するとこのアラートが発生する。 OSを再起動するとIPが DHCP サーバより再度アサインされるので復帰される。 （この手の実験するときは十分に注意してください。スナップショットを取得してから実験するのが確実です。疑似障害はAWS 管理コンソールから再起動して復帰できる範囲が必要です。ネットワークの設定を変更して再起動でももとに戻らない場合はリモートデスクトップやcliからも修正できなくなり 元に戻らない可能性があります。） | - |