【EventBridge Scheduler】EC2の自動停止・起動。および通知の無効化が簡単に!

こんにちは、直近で激アツな新機能がリリースされましたので記事にします。
Amazon EventBridge Scheduler です。
https://aws.amazon.com/jp/blogs/compute/introducing-amazon-eventbridge-scheduler/

今回はこれを用いたEC2インスタンスの自動停止・自動起動を紹介します。
この動作を実装するにあたっては、Lambdaであったり、Systems Managerというのが今まで一般的だったと思います。

なんとこのEventBridge Schedulerでは、6,000 を超える APIが使用できるので、AWSコンソール上で出来る操作はかなり自動化可能です。

従来のEventBridge ルールを利用した場合は、「1回のみの実行」ができなかったのでそれができるというのも嬉しいところです。
詳しいUpdate内容に関しては、↑のAWS公式Blogをご確認ください。

もちろんその6,000APIの中には、EC2の操作やCloudWatch Alertに関してもありましたので、それをお伝えします。

IAMロールの作成

まずは、Schedulerを動作させるためのIAMロールを作成します。(執筆時点で、マネージドロールが無かったため作成しますが、この記事をご覧になっている際にはあるかもしれません!)

作り方に関しては、公式ドキュメントに記載があります。
https://docs.aws.amazon.com/ja_jp/scheduler/latest/UserGuide/setting-up.html#setting-up-execution-role

公式ではCLIを用いてロール追加しているので、ここではマネジメントコンソールからの操作を行います。

IAMロールの作成画面で、[カスタム信頼ポリシー]を選んでから、次のポリシーに変更します。
(6~8行目のサービスが追加されます)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "scheduler.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

編集できたら、画面下の[次へ]を押して次の画面に行きます。
続いては、何の権限を付与するかが選択できます。ここでは、AmazonSSMAutomationRole を検索して選択します。

ロール名を適当に入れて、ステップ1とステップ2の設定内容が合っているか確認しましょう。

[作成]を押せば下ごしらえは完了です。

EC2の自動起動・自動停止

IAMロールが作成できたら、EventBridge Schedulerの設定を行います。
マネジメントコンソールの検索欄から[EventBridge]を開いて、[Schedule]を選択します。

それでは早速、[スケジュールを作成]をクリックしてみます。
スケジュール名と説明を入力します。
スケジュールグループという項目は、お試しで使うならdefaultで問題ありません。

続いて、スケジュールのパターンを入力します。
これまでcronベースのスケジュールでは、UTCで入力することになっていましたが、今回からJSTで書けるようになりました!嬉しい!

フレックスタイムウインドウを選択することで、決められた時間幅での実行を計画できます。
正直今のところ何に使うか分かっていませんが、トラフィック流量の都合で「一斉に起動・停止されたら困る」システムを時間的にバラすくらいの用途でしょうか。

”フレックスタイムウインドウ”も新しい概念のひとつです

次に、時間枠を設定します。
「開始日時」「終了日時」がある場合は入力します。期間を無制限とする場合は記入なしでOKです。
「xx月xx日まではAの時間帯で動作、その日以降はBの時間帯で動作!」といった使い方ですね。

さて[次へ]をクリックすると、APIの一覧が出現します。なにせ6,000あるようなので、何でもできそうな気がしてきます。
お勧めAPIが表示されますが、執筆時点ではここにEC2を起動させるものが無かったので、[すべてのAPI]から探していきます。

検索欄に"EC2"と入力して、サービスを選択します。

起動する場合は"StartInstances"、停止する場合は"StopInstances"をそれぞれ探します。
ここで、入力パラメータが必要になります。今回の2APIに関しては、インスタンスIDが求められるので、これを入力します。(カンマで区切れば、複数台管理できます!)

設定できたら、[次へ]をクリックします。
最後のステップでは、スケジュールの設定を行います。
スケジュールの状態という項目はデフォルト有効ですが、無効にすれば、スケジュールが動作しない状態で作成できます。
再試行ポリシーは有効にしていれば、指定した時間・回数の再試行が発生しますが、今回は意図しないタイミングで停止して欲しくなかったので無効化します。

暗号化の設定が必要な場合は、チェックを入れてKMSキーを選択します。
アクセス許可は、先の手順で作成したロールを選択します。

設定に関しては以上です! インスタンスIDが正しく設定されていれば、動作するはずです。

再起動に関しては、ゲストOSの"last reboot"やイベントログで確認するか、CWメトリクスなどで見るといいと思います。

通知を無効化

CloudWatch Alertを仕掛けている場合は、EC2インスタンスを停止した時点でメールやその他通知が来るようになっている環境も多いのではないでしょうか。

そんなお悩みも解決できるのが、Amazon EventBridge Scheduler です。(2回目)

やり方はEC2の自動起動・停止で紹介した手順とほぼ一緒です。
APIの一覧から、"CloudWatch" > "AlarmActions"を検索すれば目当てのAPIが出てくると思います。
"EnableAlarmActions"はCW Alarmのアクションを有効化するAPIで、
"DisableAlarmActions"はCW Alarmのアクションを無効化するAPIです。

アクションを無効化している時間帯は、AutoScalingアクションやEC2アクション、SSMアクションも無効化されるため、設定されている場合は、無効化に注意が必要です。

CloudWatchのAPIは、CLIを使っている方であれば馴染みがあると思いますがアラーム名での操作になります。
"MyData"と記載のあるところに、該当するCloudWatch Alarm名を入れましょう。

アラームアクションの無効化が行われます。(SNSトピックへの通知が行かない)
この仕組みを自動停止の前後に入れておけば、毎晩通知が来ることもなくなりますね!

あとがき

今までLambdaを使ってゴリゴリに書いていたところが、このAmazon EventBridge Scheduler を使えば、簡単に自動化できちゃいますね!
ちなみに料金は、毎月1400万回まで無料で、それ以降は100万回あたり1.25ドルです。
東京リージョンはちょっとだけ高い・・・