💬
[小ネタ]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から派生しているので、同じといえば同じで、設定が若干違うくらいですね。
Discussion