- 新しい順
- 投票が多い順
- コメントが多い順
StatusCheckFailed_SystemはAWS側の物理ホストに問題が発生した時にメトリクスが反応するようなものなのでEC2の再起動で影響を受けるようなものではないと思います。
https://dev.classmethod.jp/articles/cloudwatch-metrix-memo-1/
StatusCheckFailed_InstanceはEC2のOSなどの問題で反応するものなので再起動が原因でAlarm状態になることは発生する可能性はあると思います。
AIの回答でメトリクスの欠落データの扱い方について記載されていますが、この設定が欠落データを不正に設定されているとAlarmになります。
例えば再起動によってEC2がうまく立ち上がらずにCloudWatchにメトリクスデータを送れないといった状況になったときに設定によってはAlarmとなります。(欠落データを不正に設定しているとデータがなかった際にAlarmとなると思います)
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data
EC2インスタンスの定期リブートによって、CloudWatch Alarmが一時的にAlarm状態になる可能性があるメトリクスは以下の通りです：
-
StatusCheckFailed_Instance: このメトリクスはインスタンスレベルのステータスチェックを表します。リブート中にこのチェックが失敗する可能性が高いため、閾値が0に設定されている場合、リブート中にAlarm状態になる可能性があります。
-
StatusCheckFailed_System: このメトリクスはシステムレベルのステータスチェックを表します。リブート中にこのチェックも失敗する可能性があるため、閾値が0の場合にAlarm状態になる可能性があります。
StatusCheckFailed_Instance_Insufficientについては、これは標準的なCloudWatchメトリクスではありません。おそらく"StatusCheckFailed_Instance"の誤記か、カスタムメトリクスである可能性があります。
リブート中にこれらのメトリクスが一時的に失敗するのは正常な動作です。ただし、アラームの設定によっては、短時間のリブートでもAlarm状態にならない場合があります。例えば、評価期間（EvaluationPeriods）や、アラームをトリガーするのに必要なデータポイント数（DatapointsToAlarm）を適切に設定することで、短時間の変動を無視することができます。
また、メトリクスの欠落データの扱い方（TreatMissingData）の設定も重要です。リブート中にデータポイントが欠落する可能性があるため、この設定によってアラームの動作が変わる可能性があります。
Sources
Understand your alarm transition state in CloudWatch | AWS re:Post
Elevating Your AWS Observability: Unlocking the Power of Amazon CloudWatch Alarms | AWS Cloud Operations Blog
Create CloudWatch alarms for Amazon EC2 instances that fail status checks - Amazon Elastic Compute Cloud
Period: 60 EvaluationPeriods: 3 DatapointsToAlarm: 3 Threshold: 0
他の値は上記です。