こんにちは、上野です。
Amazon EventBridge Schedulerと呼ばれる、従来からあるEventBridgeルール（スケジュール）のパワーアップ版のような機能が発表されました。機能概要はAWSさんのブログがわかりやすいです。
従来のEventBridgeルールからのパワーアップしたポイントとしてあるのが、Targetsの数が大きく増えたことです。新しいEventBridge Schedulerでは、270以上のサービスの6,000以上のAPIに対応しています。AWSが用意しているAPIはほぼすべてTargetsとして指定し実行できるということですね。
これがあれば、EC2の停止処理（もちろん起動も）EventBridge Schedulerだけで実装できます。やり方を見ていきます。
従来のEC2自動停止/起動方法
Instance Schedulerが有名かと思います。こちらはAWS公式で提供されているソリューションであり、以下アーキテクチャ図のとおり、LambdaとEventBridgeルール（旧CloudWatch Event）を組み合わせた仕組みになっています。
私もこの仕組みや、この仕組みを参考に独自でLambdaを実装したりして停止運用をしていました。
Lambdaのランタイムが古くなった場合のバージョンアップや、Lambdaコードの管理が必要となります。 （ソリューションを使えば大きな負荷にはならないですが）
EventBridge Schedulerでの実装
こんなアーキテクチャになります。めちゃくちゃシンプルですね！！アイコンも2つです。
作ってみる
やっていきます。基本はポチポチやるだけで簡単に実装できます。
対象のEC2を準備しておきます。実行中です。
1. 実行用のIAMロールを作成
IAMの画面からロールを作成していきます。
信頼関係は以下のとおりEventBridge Schedulerから実行できるようカスタム信頼ポリシーで記載します。ドキュメントでもポリシーは紹介されています。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "scheduler.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
付与する許可ポリシーについては、今回はEC2の停止のみを実行する処理なのでActionにec2:StopInstancesを許可したものを用意してIAMロールに追加します。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "ec2Stop", "Effect": "Allow", "Action": "ec2:StopInstances", "Resource": "*" } ] }
任意の名前を付けてIAMロールを作成します。今回は「SchedulerEC2Stop」にしました。
2. EventBridge Schedulerの設定
本題です。定期停止処理を設定していきます。
EventBridgeのページから、いつもの見慣れたルールではなく、スケジュールのページから「スケジュールを作成」を選択します。
任意のスケジュール名を入力します。
cronベースのスケジュールを設定します。今回は検証用途なので、直近で動きそうな時刻を設定します。 フレックスウィンドウ（実行時刻に余裕を持たせるか）はオフにしておきます。
タイムゾーンと開始日時、終了日時も指定できます。今回は検証用途で開始時刻や終了日時を指定する必要は無いので空欄でいきます。
APIの種類としてEC2を選択します。
StopInstancesを選択します。
ターゲットの入力欄が表示されるので、InstanceIDを入力します。JSONフォーマットは自動入力されるので、InstanceIDだけ入力すればOKです。なお、今回は1台のEC2インスタンスを指定しますが、カンマ区切りで複数インスタンスの指定も可能です。
設定ページでは、色々と設定項目がありますが単純に実行するだけであれば一番下のアクセス許可で作成したIAMロールを指定すればOKです。
内容を確認してスケジュールを作成します。
スケジュールが作成されました。
3. EC2の停止を見守る
後は停止するEC2を見届けるだけです。時刻になると停止中⇒停止済みとになりました。
あっという間に実装できました！
EventBridge Schedulerの補足
細かい設定は手順の際に省略したので少し補足していきます。
cronの設定例いくつか
ドキュメントも参考にしてください。
- 毎日夜21:00
- 平日朝10:00
- 毎年年始9:00
予定実行1発のみも設定できる
以下のように1回だけ実行したい場合の設定も可能です。
フレックスタイムウィンドウ
この設定を追加すると実行時間が柔軟に変更されます。たとえば毎日9:00起動、フレックスタイムウィンドウを30分に設定すると、毎日9:00～9:30という範囲内の時刻で、設定したTargetsのタスクが実行されます。
AWS公式ブログでは以下のとおり、柔軟性を持たせることでサービスリミットの回避につながるという説明もありました。
if you choose a time window, EventBridge Scheduler invokes the task within that timeframe. This setting helps to distribute the invocations across time and manage the downstream service limits.
再試行ポリシーとデッドレターキュー (DLQ)
Targetsのエラー時の再試行回数と、失敗時の待機（経過）時間を設定できます。また、失敗したイベントをデッドレターキューとしてSQSに保存可能です。デフォルトのオプションは以下のとおりです。
KMSキーで暗号化も可能
デフォルト状態でもAWSマネージドのデフォルトキーで暗号化されますが、ユーザーが作成したKMSキーを指定することも可能です。
結局従来のEventBridgeルールと何が変わったの？
AWS公式ブログの表がわかりやすいのでそのまま記載します。
| Amazon EventBridge Scheduler | Amazon EventBridge rules | |
|---|---|---|
| Quota on schedules | 1 million per account | 300 rule limit per account per Region |
| Event invocation throughput | Able to support throughput in 1,000s of TPS | Because of the schedule limit, you can only have 300 1-minute schedules for max throughput of 5 TPS |
| Targets | Over 270 services and over 6,000 API Actions with AWS SDK targets | 20+ targets supported by EventBridge |
| Time expression and time-zones | at(), cron(), rate() All time-zones and DST |
cron(), rate(), UTC No support for DST |
| One-time schedules | Yes | No |
| Time window schedules | Yes | No |
| Event bus support | No event bus is needed | Default bus only |
| Rule quota consumption | No. 1 million schedules soft limit | Yes, consumes from 2,000 rules per bus |
ざっと以下のようなパワーアップ具合です。
- スケジュール数や実行数のクォータが大幅にあがった
（アプリケーション処理で対象にスケジュール作成＆実行といったアーキテクチャも可能） - 多くのAWSサービスAPIに対応するようになった
- タイムゾーンも設定でき時刻設定がわかりやすい
- 1回のみ実行もできるように
料金
気になる料金について。月あたり14,000,000回は無料です。それ以上になると$1.25/100万回。大規模に利用しない限りは無料ですね。詳細は料金ページを確認してください。（現時点では英語にしないとScheduler部分が表示されません）
まとめ
人によって嬉しいポイントは異なると思いますが、私としてはTargetsに指定できるAPIの種類が大幅に増えた点が嬉しいです。今回はEC2の停止を例に紹介しましたが、ECSのRun TaskやCloudWatchのアラーム無効など、他にも運用に役立ちそうな処理がEventBridge Schedulerだけで実装できそうです。
re:Invent前にたくさんのアップデートが出ていますね。re:Invent本番も楽しみです！
