はじめに
クラウドネイティブな開発が進む中、定期実行タスクの実装方法も変化しています。従来の EC2 インスタンス上の crontab から、ECS や Lambda を使ったサーバーレスな実行基盤への移行が加速しており、バッチ処理やデータ集約といったワークロードをコンテナで定期実行するケースが増えています。
しかし、いざ ECS で定期実行を実装しようとすると、「どの方法を使えばいいのか？」「自分のユースケースに最適な選択肢は何か？」と迷うことも多いでしょう。 AWS には複数の実装方法があり、それぞれに特徴と適したシーンがあります。
本記事では、ECS タスクの定期実行を実現する主要な実装方法を整理し、ユースケース別の選び方を解説します。すでに ECS の基本を理解している方が、次のステップとして定期実行を実装する際の実践的なガイドとしてお役立てください。
ECS タスク定期実行の 3 つの実装方法
ECS タスクの定期実行には以下の 3 つの主要な実装方法があります。
- EventBridge Scheduler
- EventBridge Rules
- Step Functions連携
本章では、これら 3 つの方法の概要と位置づけを整理し、どのようなケースで使い分けるかの指針を示します。
各実装方法の位置づけ
EventBridge Scheduler（推奨）
タイムゾーン対応や柔軟なリトライ設定、DLQ サポートなど最も機能が充実した新しい実装方法です。
2022 年 11 月にリリースされ、2025 年現在、シンプルな定期実行なら最も推奨される方法です。
EventBridge Rules（従来方式）
以前から使われている方法で、UTC 固定でのスケジューリング方式です。
新規での採用理由は少ないものの、既存システムの維持や特定の要件がある場合に選択肢となります。
Step Functions連携
複数の ECS タスクを順次実行する、タスクの同時実行を防ぐ、実行結果に応じて処理を分岐するなど複雑なワークフローが必要な場合の選択肢となります。
追加コストが発生するためシンプルなケースでは過剰です。
選択の基本方針
EventBridge Scheduler
概要と特徴
EventBridge Scheduler は、2022 年 11 月にリリースされた AWS のサーバーレススケジューラーサービスです。
ECS タスクをはじめ、Lambda、Step Functions など 200 以上の AWS サービスを対象に柔軟なスケジューリングを実現します。
主な特徴
- タイムゾーン対応：日本時間（Asia/Tokyo）などを指定可能
- 柔軟なリトライ設定：最大 185 回のリトライ、最大 24 時間の保持期間を設定可能
- Dead Letter Queue 対応：失敗したイベントを SQS や SNS に送信
- ワンタイムスケジュール：特定日時の 1 回だけの実行も可能
- スケーラビリティ：数千万のスケジュールを管理可能
従来の EventBridge Rules と比較して、設定の自由度の高さや運用のしやさが最大の利点です。
メリット・デメリット
メリット
- タイムゾーン対応で JST での実行が簡単
- リトライと DLQ で障害時の対応が容易
- スケジュール管理が一元化できる
- 月 14 M invocations まで無料
デメリット
- 無料枠を超えると従来方式より若干コストが高い
- ECS コンソールからの直接作成には非対応
料金
EventBridge Scheduler の料金は 100 万 invocations あたり $ 1.00 です。（東京リージョン）
コスト例
- 毎日 1 回実行（月 30 回）：$ 0.0000375
- 1 時間ごとに実行（月 720 回）：$ 0.0009
月 14,000,000 invocations までの無料利用枠があるため、一般的なユースケースでは実質無料で運用できます。
EventBridge Rules
概要と特徴
EventBridge Rules（旧 CloudWatch Events）は、以前からあるスケジューリング方法です。
cron 式や rate 式を使って定期的に ECS タスクを起動できます。
主な特徴
- UTC 固定：タイムゾーン指定ができず、常に UTC で実行される
- シンプルな設定：基本的な cron 式または rate 式のみ対応
- 無料：AWS 管理イベントとして課金されない
EventBridge Scheduler との比較
| 項目 | EventBridge Scheduler | EventBridge Rules |
|---|---|---|
| タイムゾーン | 指定可能（JST 等） | UTC 固定 |
| リトライ設定 | 最大 185 回、細かく設定可能 | 基本的にサポートなし |
| DLQ | ネイティブサポート | 手動設定 |
| 料金 | $ 1.25 / M invocations | 無料 |
メリット/デメリット
メリット
- 完全無料で利用可能
- シンプルで理解しやすい
- 既存システムで広く利用されている実績
デメリット
- UTC 固定のため、日本時間で実行する場合は時差計算が必要
- リトライや DLQ の設定が複雑
料金
EventBridge Rules による cron / rate ベースのスケジュールは、AWS 管理イベントとして完全無料です。
実行回数に関わらず課金されません。
Step Functions 連携
概要と特徴
Step Functions と EventBridge（Scheduler または Rules）を組み合わせることで、複雑なワークフローを持つ定期実行タスクを実現できます。
Step Functions がワークフローの制御を担当し、EventBridge がそのワークフローを定期的に起動します。
主な特徴
- 複数タスクの順次実行：タスク A の完了後にタスク B を実行、といった制御が可能
- 排他制御：DynamoDB などを使ったロック機構で、同時実行を防止できる
- 条件分岐：タスクの実行結果に応じて次のアクションを変更
- エラーハンドリング：Catch / Retry による柔軟なエラー処理
- タイムアウト制御：タスクごとに最大実行時間を設定可能
単純な定期実行にはオーバースペックですが、複雑な要件がある場合は強力な選択肢となります。
メリット・デメリット
メリット
- 複雑なワークフローを視覚的に設計・管理できる
- 柔軟なエラーハンドリングとリトライ制御
- 実行履歴が詳細に記録される
- タスク間のデータ受け渡しが容易
デメリット
- Step Functions 自体のコストが追加で発生
- 設定が複雑で学習コストが高い
- シンプルなユースケースには過剰
料金
Step Functions には Standard Workflows と Express Workflows の 2 種類があり、料金体系が異なります。
Standard Workflows
Standard Workflows の料金は状態遷移 1,000 回あたり $ 0.025 です。（東京リージョン）
Express Workflows
Express Workflows はリクエスト数と期間に基づいて課金されます。
- 100 万件のリクエストあたり $ 1.00
- GB-秒あたり $ 0.00001667
ECS の定期実行では、実行履歴が残る Standard Workflows を使用するケースが一般的です。
EventBridge Scheduler または Rules の料金も別途発生する点には注意が必要です。
3 つの実装方法の比較
詳細比較
| 項目 | EventBridge Scheduler | EventBridge Rules | Step Functions 連携 |
|---|---|---|---|
| 料金 | $ 1.00 / M invocations | 無料 | Standard: $ 0.025 / 1 K transitions |
| タイムゾーン | 指定可能（JST 等） | UTC 固定 | Scheduler に依存 |
| リトライ | 最大 185 回 | サポートなし | Catch / Retry による柔軟な設定 |
| DLQ | ネイティブサポート | 手動設定 | ネイティブサポート |
| 複雑なワークフロー | 不可 | 不可 | 可能 |
| 設定の複雑さ | 低 | 低 | 高 |
| 推奨度 | ◎ | △ | 特定ケースのみ |
コスト面での比較
実際の運用コストを比較すると、一般的な定期実行タスクではほぼ差がありません。
月 1 回実行
- EventBridge Scheduler: $ 0（無料枠内）
- EventBridge Rules: $ 0
- Step Functions（ECS RunTask → 待機 → 通知の 3 ステップ）: $ 0.0001 未満
1 時間ごとに実行（月 720 回）
- EventBridge Scheduler: $ 0（無料枠内）
- EventBridge Rules: $ 0
- Step Functions（ECS RunTask → 待機 → 通知の 3 ステップ）: $ 0.05
EventBridge Scheduler の無料枠（14 M invocations / 月）は非常に大きく、1 分ごとに実行しても 43,200 回 / 月で無料枠内に収まります。
コストを理由に Rules を選ぶ必要性は低いと言えます。
運用面での比較
EventBridge Scheduler の運用メリット
- タイムゾーン設定により、サマータイム切り替え時の対応が不要
- リトライ設定が容易で、一時的な障害に強い
- DLQ 設定により、失敗イベントの追跡が簡単
EventBridge Rules を継続するケース
- 既に安定稼働しており、移行のメリットが薄い
- UTC 固定で問題なく、設定変更のリスクを避けたい
Step Functions 連携が必要なケース
- 前のタスクの出力を次のタスクの入力として使う
- タスクの実行時間が不定で、完了を待ってから次を実行したい
- 複数のタスクを並列実行し、すべて完了後に次の処理を行いたい
移行を検討すべきタイミング
既存の EventBridge Rules からの移行は、以下の場合に検討する価値があります。
- タイムゾーン対応が必要になった（海外展開、サマータイム対応）
- リトライや DLQ など、障害対応の仕組みを強化したい
- 新しいタスク定義リビジョンへの自動追従が必要
現状の Rules で問題なく動作しているなら、無理に移行する必要はありません。
まとめ
本記事では、ECS タスクの定期実行を実現する3つの実装方法を比較し、ユースケース別の選び方を解説しました。
- EventBridge Scheduler：タイムゾーン対応、リトライ設定など機能が充実した推奨方法
- EventBridge Rules：UTC固定だが完全無料の従来方式
- Step Functions 連携：複雑なワークフローが必要な場合の選択肢
2025 年現在、新規で ECS の定期実行を構築するなら、EventBridge Scheduler が最適です。
日本時間での実行が簡単で、リトライや DLQ など実用的な機能が揃っています。
また、無料枠も大きく一般的なユースケースでは実質無料で運用できます。
既に EventBridge Rules で安定稼働しているシステムにおいては無理に移行する必要はありません。
複数タスクの順次実行や排他制御が必要な場合のみ、Step Functions 連携を検討してください。
参考リンク
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/tasks-scheduled-eventbridge-scheduler.html
https://docs.aws.amazon.com/scheduler/latest/UserGuide/what-is-scheduler.html