EC2 での高解像度メトリクスアラーム利用時、意図しないアラームが発生する原因を教えてください

困っていること

高解像度メトリクスアラームを利用して、EC2 の CPUUtilization を 10 秒単位で監視をはじめたところ、意図しないアラームが発生しました。
EC2 での高解像度メトリクスアラーム利用時、意図しないアラームが発生する原因を教えてください。
※ 設定例

• 統計: 平均
• 期間: 10 秒
• アラームを実行するデータポイント: 3/4
• 欠落データの処理: 「欠落データを不正（しきい値を超えている）として処理。」

どう対応すればいいの?

高解像度メトリクスアラームはカスタムメトリクスに対して有効な設定方法であるため、CPUUtilization を対象にすることは叶いません。

AWS のサービスによって生成されたメトリクスは、デフォルトで標準解像度になります。カスタムメトリクスを発行するときは、標準解像度または高解像度のいずれかとして定義できます。高分解能のメトリクスをパブリッシュすると、CloudWatch はそれを 1 秒の分解能で保存します。ユーザーは、1 秒、5 秒、10 秒、30 秒、または 60 秒の倍数の期間でメトリクスを読み取り、取得できます。

また、CPUUtilization など EC2 が提供するメトリックスの最小粒度 (出力) は 1 分です。
高解像度メトリクスアラームの作成は可能であるものの、EC2 が提供するメトリクスの最小粒度 (出力) よりも短い期間を CloudWatch アラームに設定した場合、アラーム状態の評価において意図しない評価になる可能性がございます。
そのため、EC2 インスタンスの CPUUtilization メトリクスに対して高解像度メトリクスアラームを作成することはお勧めしません。
インスタンスの詳細モニタリングを有効 にして、期間には 1 分を指定し、アラームを実行するデータポイントは、3/3 など標準アラームでの利用をご検討ください

注意事項[最小]、[最大]、[平均] の統計では、EC2 が提供するメトリクスの最小粒度は 1 分であることに注意します。

アラーム期間が正しく設定されていない
必要な頻度でデータポイントを取得するようにアラームを設定できます。しかし、アラームが、サービス (またはソース) がデータポイントをメトリクスに送信するために使用する期間よりも短期間を使用する場合、望ましくない状態になる可能性があります。

確認してみた

意図していない評価になるか確認してみました。前途の設定例でやってみます。

• 統計: 平均
• 期間: 10 秒
• アラームを実行するデータポイント: 3/4
• 欠落データの処理: 「欠落データを不正（しきい値を超えている）として処理。」

対象 EC2 に負荷を掛けるため、yes コマンドを実行。

$ yes >/dev/null

CPUUtilization が 55 %以上になっていないものの、CloudWatch アラーム履歴より、2024-04-02 07:30:57 に OK からアラーム状態に更新したことを確認。

履歴データを見てみます。

概要
OKからアラーム状態に更新したアラーム。
データ
{
  "alarmName": "Test",
  "alarmType": "MetricAlarm",
  "timestamp": "2024-04-02T07:30:57.850Z",
  "historyItemType": "StateUpdate",
  "historySummary": "Alarm updated from OK to ALARM",
  "historyData": {
    "version": "1.0",
    "oldState": {
      "stateValue": "OK",
      "stateReason": "Threshold Crossed: 1 out of the last 3 datapoints [14.924999999999999 (02/04/24 07:28:00)] was not greater than or equal to the threshold (55.0) and 2 missing datapoints were treated as [Breaching] (minimum 1 datapoint for ALARM -> OK transition).",
      "stateReasonData": {
        "version": "1.0",
        "queryDate": "2024-04-02T07:28:47.847+0000",
        "startDate": "2024-04-02T07:28:00.000+0000",
        "statistic": "Average",
        "period": 10,
        "recentDatapoints": [
          14.924999999999999
        ],
        "threshold": 55,
        "evaluatedDatapoints": [
          {
            "timestamp": "2024-04-02T07:28:00.000+0000",
            "sampleCount": 1,
            "value": 14.924999999999999
          }
        ]
      }
    },
    "newState": {
      "stateValue": "ALARM",
      "stateReason": "Threshold Crossed: no datapoints were received for 3 periods and 3 missing datapoints were treated as [Breaching].",
      "stateReasonData": {
        "version": "1.0",
        "queryDate": "2024-04-02T07:30:57.846+0000",
        "statistic": "Average",
        "period": 10,
        "recentDatapoints": [],
        "threshold": 55,
        "evaluatedDatapoints": [
          {
            "timestamp": "2024-04-02T07:30:30.000+0000"
          },
          {
            "timestamp": "2024-04-02T07:30:20.000+0000"
          },
          {
            "timestamp": "2024-04-02T07:30:10.000+0000"
          }
        ]
      }
    }
  }
}

CloudWatch アラーム作成後すぐに 誤報が確認されました。データポイントの値を取得できておらず、欠損データとして処理されていることを確認できました。
※ breaching: 「欠落データを不正（しきい値を超えている）として処理。」 が 3 回記録され発報されています。

参考資料

• Amazon CloudWatch における高解像度メトリクスとアラーム | Amazon Web Services ブログ
• インスタンスの利用可能な CloudWatch メトリクスのリスト表示 - Amazon Elastic Compute Cloud
• カスタムメトリクスをパブリッシュする - Amazon CloudWatch
• CloudWatch エージェントにより収集されるメトリクス - Amazon CloudWatch
• CloudWatch アラームの状態が INSUFFICIENT_DATA になっているのはなぜですか?
• インスタンスの詳細モニタリングを有効または無効にする - Amazon Elastic Compute Cloud