[小ネタ]CloudWatch AlarmからEventBridge / SNS でALARMだけを通知するときの違い

動機

CloudWatch AlarmがALARMになったときに、Lambdaを呼びたいことがありました。CloudWatchから直接呼べるのはSNSだけなので、特に何も考えずにSNSからLambdaを呼んでいましたが、EventBridgeも使えるのだなというので調べました。

CloudWatch Alarm

• 状態にはOK、ALARM、INSUFFICIENT_DATAの3つ
• コンソールでデフォルトで作ると、宛先のSNSトピックを設定
  • ALARM状態になったときSNSから通知

アラームの情報見るために、このコマンドを使って、

aws cloudwatch describe-alarms --alarm-names <alarm_name>

AlarmActionsには呼ばれるSNSのARNが入っていることが確認できます。OKActions、InsufficientDataActionsは空です。

{
    "MetricAlarms": [
        {
            "AlarmName": "<alarm_name>",
	    ...
            "OKActions": [],
            "AlarmActions": [
                "arn:aws:sns:ap-northeast-1:111122223333:trigger-lambda"
            ],
            "InsufficientDataActions": [],

必要であれば、OKActions、InsufficientDataActionsを追加すればよさそうです。

EventBridge

コンソールでEventBridgeでRuleを作ってEvent PatternとしてCloudWatchを選択したときは、こうなりますが・・・

このとき、全てのState Changeに対してEventBridgeのトリガーがかかります。私の場合、これは嬉しくありませんのでALARMだけにします。

ALARMだけにするには、下記のようにdetail項目を追加します。

{
  "source": ["aws.cloudwatch"],
  "detail-type": ["CloudWatch Alarm State Change"],
  "detail": {
    "state": {
      "value": ["ALARM"]
    }
  }
}

["OK", "INSUFFICIENT_DATA"] といった複数項目の書き方も可能です。

参考:stateを変えるCLIコマンド

state-valueはOK、ALARM、INSUFFICIENT_DATAが入ります。

aws cloudwatch set-alarm-state \
  --alarm-name <alarm_name> \
  --state-value ALARM \
  --state-reason "test"

まとめ

CloudWatch Alarmの状態遷移による他リソースへのアクションに関して、SNSとEventBridgeの比較を行いました。

もともとEventBridgeはCloudWatch Eventから派生しているので、同じといえば同じで、設定が若干違うくらいですね。