今回はLambdaの関数をEventBridgeを使って定期実行されるように設定する方法についてまとめていきます。
前提条件
下記の記事で作成したLambdaの関数を定期実行する様にしていきます。(Lambdaの関数は動けばとりあえず何でもいいです。)
構成図
構築
-
トリガーを追加
定期実行したいLambda関数の画面上部にある「関数の概要」から [トリガーを追加] をクリックします。

-
EventBridgeのルールを設定
トリガーの設定でEventBridgeを選択、Create a new ruleを指定して、任意の名前と説明を入力してください。
Rule TypeはSchedule expressionにしてください。
Schedule expressionにはいつ実行するかを記載します。今回は5分ごとに実行されるようにrate(5 minutes) と入力します。

時間を指定することもできます
cron(0 18 * * ? *) と入力すると、毎日 日本時間の午前3時 に実行されるようになります。
※AWSのスケジュールはUTC(協定世界時)で指定するため、日本時間(JST)から9時間引いた時間を入力する必要があります。
まとめ
Lambdaの関数をEventBridgeを使って定期実行できるようにしました。
今回はテストで5分間隔だったのですが、高頻度のバッチ処理の場合はLambdaでの処理はあまりお勧めではありません。
Lambdaは「実行時間 × 割り当てメモリ」の従量課金です。5分ごと(1日288回)やそれ以上の超高頻度で、かつ1回の処理が数分かかるようなバッチの場合、ECSなどを常時起動させておくよりもコストが高くなるケースがあります。
もし「高頻度」「長時間」「大量データ」のバッチ処理をAWSで実装する場合は、以下のような構成を検討してみてください。
- Amazon ECS (Fargate) + EventBridge
EventBridgeをトリガーに、ECSタスクを立ち上げてバッチを回す構成です。15分の壁がなくなり、重い処理も安全に実行できます。 - AWS Batch
より本格的なバッチ管理サービスです。リソースの動的なプロビジョニングや、ジョブのキューイング(順番待ち)を自動で最適化してくれます。
最後に
とはいえ、「1日に数回、数MB程度のデータをサクッと転送する」といった用途において、Lambdaは手軽でコストパフォーマンスの良い選択肢です。
システムの規模やデータの成長速度に合わせて、最適なアーキテクチャを選定しましょう。


