EventBridge SchedulerでCWアラームのオンオフ

# シナリオ
開発環境のアラームは日中は鳴ってても誰か対応するし、夜間に何かあっても翌日対応すればいいから夜間はアラーム止めておきたい。みたいな時に、業務が終わる時間に開発環境用のアラームを無効にして、出勤したら有効化するスケジュールを組むことを想定してみました。


## 前置き

### EventBridge Scheduler用のIAMロール

[公式ドキュメント](https://docs.aws.amazon.com/scheduler/latest/UserGuide/setting-up.html#setting-up-execution-role)に沿って作っておく

### CWアラーム

こんな感じで開発環境用のアラームっぽいのが2つあるとします。

![スクリーンショット 0004-11-17 14.12.42.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/3bceb6ae-3067-7311-fb5a-5a93c2f575ff.png)

### CloudTrail Lake

ログ確認のため有効化しておく。CloudTrailのログが見れれば別な方法でも構わない。EventBridge Scheduler側にはログ確認手段がなさそう。

### 用語

* Schedule： スケジュールされる実行単位。ジョブとかタスクのような意味合い。
* スケジュールグループ：作成するScheduleをただまとめる論理的なグループ。環境とかクラスタとか任意の単位でグルーピング。デフォルトではDefaultがある。今回は事前に"test-group"という名前で作成したのでそれを選択。
* ターゲット
  * テンプレート化されたターゲット(今回は使わない)(以前からある)：SQS、Lambda、Step Functionsなどのコア AWS サービスのグループ全体で共通の API 操作のセットです。たとえば、関数 ARN を提供することで Lambda の Invoke API オペレーションをターゲットにするか、ターゲットのキュー ARN を使用して Amazon SQS の SendMessage オペレーションをターゲットにすることができます
  * ユニバーサル ターゲット(今回使う)(New)：多くの AWS サービスに対してより幅広い API 操作を呼び出すことができる、カスタマイズ可能な一連のパラメータです。たとえば、EventBridge スケジューラのユニバーサル ターゲット パラメータ (UTP) を使用して、CreateQueue オペレーションを使用して新しいSQS キューを作成できます。[ユニバーサルターゲットのドキュメント](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html)

# Let's try EventBridge Scheduler

## Scheduleの作成

### 1つ目のSchedule"alarm-disable-test"を作成

EventBridgeの左メニューから"スケジュール"をクリックして、右下辺りの[スケジュールを作成]をクリック

![スクリーンショット 0004-11-17 14.23.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/44e35f7c-c885-ee18-8a27-885eb5bafabf.png)

次に以下を入力し、入力したら[次へ]をクリック

スケジュール名：Alarm-disable-test
スケジュールグループ:test-group
フレックスタイムウインドウ：15分

![スクリーンショット 0004-11-17 14.25.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/26290a93-761e-56f2-48bb-513dca2729bc.png)

テストなので毎時10分で設定しました。

![スクリーンショット 0004-11-17 15.49.11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/8437eab1-3f3c-1713-bc38-a59d7a8e3f64.png)

#### ターゲットの選択

"すべてのAPI"にチェックを入れて、検索窓に"Cloudwath"と入れて、下に出てきた「CloudWatch」をクリック

![スクリーンショット 0004-11-17 14.57.54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/5b2a1f7a-786b-3b06-ad53-0e28e02d207c.png)

"DisableAlarmActions"にチェック

![スクリーンショット 0004-11-17 14.59.26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/e3c8c5ca-0f45-222e-cae8-dfb7d9934ccd.png)

下部に以下の値を入れて、[次へ]をクリック
※2つのアラーム名をdev-*でやってみたけどダメでしたので、ベタ書きしました

```json:
{
  "AlarmNames": [
    "dev-rds-alarm","dev-ec2-alarm"
  ]
}
```

![スクリーンショット 0004-11-17 15.21.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/77a3abab-17da-571a-6954-1b0feca83c69.png)

#### 作成したスケジュールを確認

![68747470733a2f2f71696974612d696d6167652d73746f72652e73332e61702d6e6f727468656173742d312e616d617a6f6e6177732e636f6d2f302f32373933322f34383562306265332d383161372d333339372d663362662d6439613935633738646333642e706e67 (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/bb3ca9a3-9082-3abd-af2a-6c95f347742a.png)


![スクリーンショット 0004-11-17 15.24.26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/eaf42a4b-4e06-4091-8fe1-e2561ec9477f.png)


![スクリーンショット 0004-11-17 15.43.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/504a2fc8-42f3-2c84-cfa2-dc7d3e65ebb3.png)

### 同じ手順で2つ目のSchedule"alarm-enable-test"を作成

スケジュール名をalarm-enable-test
毎事30分で設定しました。

## 実行確認

### CWアラームの確認

10分過ぎに2つのアラーム共にDisableになりました。

![スクリーンショット 0004-11-17 16.17.10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/9f1a89ff-a14b-2c29-5680-ecac355d50ff.png)

30分過ぎに2つのアラーム共にEnableになりました。

![スクリーンショット 0004-11-17 16.38.25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/3bf0ea99-3638-0a71-eb3e-2b7705c2f5f8.png)


### EventBridge Schedulerの実行結果をCloudTrail確認

"eventSource"や"EventName"にEventBridge Schedulerと分かる文字列が入ってこないので、"userAgent"に入ってくる「AmazonEventBridgeScheduler, aws-sdk-java/2.18.9 Linux/4.14.294-2・・・」の文字列で引っ掛けました。

CloudTrailのログからもスケジュールが実行されAPIコールされたことが確認出来ます。
alarm-disable-testは、毎時10分で、14分に実行
alarm-enable-testは、毎時30分で、37分に実行
フレックスウインドウで15分を設定したので、15分以内に実行されました。

```sql:
SELECT eventID,eventTime, eventType,eventSource,EventName,userAgent,requestParameters FROM xxxxxxxxxxxxxxxxxxxxx WHERE  eventTime > '2022-11-17 02:00:00' AND eventTime < '2022-11-17 08:00:00'  AND userAgent like 'AmazonEventBridgeScheduler%' order by eventTime desc;
```

![スクリーンショット 0004-11-17 16.48.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/832e7029-31d8-4ac2-9181-0c63271f984b.png)


![スクリーンショット 0004-11-17 16.40.42.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/96e3f3e6-3ac7-e892-c8a7-ae7877728b79.png)



### その他

* Schedule自体の有効無効も出来ます。
* レートベースのスケジュールって面白いですね。
    * レートベースのスケジュールは、スケジュールに指定した開始日以降に開始され、スケジュールの終了日まで定義した通常のレートで実行されます。 レートベースのスケジュールを使用して、最も一般的な繰り返しスケジュールのユース ケースを設定できます。 たとえば、ターゲットを 15 分ごと、2 時間ごと、または 5 日に 1 回呼び出すスケジュールが必要な場合は、レートベースのスケジュールを使用してこれを実現できます。 レート式を使用して、レートベースのスケジュールを構成します。
* リトライポリシーとDLQ対応してるので信頼性強
* 公式ドキュメントは[こちら](https://docs.aws.amazon.com/scheduler/latest/UserGuide/what-is-scheduler.html)
* その他アイデアがありそう
    * [EC2の定期起動停止](https://tech.nri-net.com/entry/easy_implementation_with_eventbridge_scheduler)
    * Redshiftの定期起動停止とか
    * RDSからS3への定期エクスポートとか
    * CWLをS3に定期ダンプとか

#### 感想

* 設定はめちゃ簡単。なんかSystems Manager感あるw
* AWSの多くのAPIが叩けるのでPrimitiveだけどパワフル！。夢がMoriMori。ここは大っきいメリット
* ログはCloudTrailで確認する仕様は、AWSのAPIを叩いた結果を見る意味だと分かるけど、ジョブスケジューラ(と呼んじゃうけど)側で見れないのは不便。個人的にジョブスケジューラはログが見やすいことが一番大事だと思ってる。ジョブスケジューラで凝ったことしたり作り込むにしてもそれは一時だけど、運用は日々行われて、ジョブスケジューラの運用の大半が平和の確認と失敗時の迅速な把握。それがCloudTrailでログでの確認だと、ログが生々しいので、そのジョブの実行結果の概要が分かるくらいの抽象度で見たい。さらに、ジョブスケジューラを使う人は運用者やアプリ開発者などもいるので、ログをCloudTrailで確認となると彼らにもCloudTrailへの閲覧権限が必要になる。ログの閲覧もジョブスケジューラ利用者の同一権限内に収まるような結合度が欲しい。逆に言うと、既に権限含めてCloudTrailのログを見やすく出来てるなら問題ないけど。
* 贅沢をいれば実行の履歴やトレンドも見れるといい(Jenkinsみたいに..)。