TL

Cloud Service

Amazon EventBridge Scheduler

cron やレート式での定期実行と一度きりの予約実行を、サーバー管理なしで多数の AWS サービスへ直接ディスパッチ。タイムゾーンや実行ウィンドウも扱える専用スケジューラ。

基礎SAA-C03DVA-C02DOP-C02運用上の優秀性信頼性コスト最適化
最終更新: 2026-06-28公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.cron・レート・一度きりの予約で処理を時刻起動する専用サービス。
  • 2.ルールやイベントバスを使わず多数のAWSサービスを直接呼べる。
  • 3.タイムゾーン指定と柔軟な実行ウィンドウで分散起動もできる。

解決する課題

  • 「毎日午前3時にバッチを動かす」といった定期実行をサーバーレスで組みたい
  • 「30分後に1回だけ通知する」ような一度きりの予約実行を大量に作りたい
  • EC2 の cron やデーモンを自前で管理したくない
  • 起動先を Lambda 以外の多数の AWS サービスにも広げたい

主要概念と用語

  • スケジュール: いつ・何を実行するかの定義。1件ごとに独立して作る
  • スケジュール式: 起動タイミングの指定。cron 式・レート式・at() の一度きりの3種類
  • ターゲット: 起動先。Lambda・Step Functions・SQS・SNS など多数のサービスを直接指定できる
  • 柔軟な時間枠(フレキシブルタイムウィンドウ): 指定時刻ちょうどではなく、一定の範囲内に分散して起動させる設定
  • スケジュールグループ: 複数のスケジュールをまとめて管理・タグ付けする単位
  • 実行ロール: スケジューラがターゲットを呼び出すときに引き受ける IAM ロール

仕様・制限・クォータ

  • スケジュール式は **cron 式・レート式・一度きりの予約(at)**の3形式に対応する
  • タイムゾーンを指定でき、夏時間(DST)の切り替わりも考慮した起動ができる
  • 1つのアカウントで大量のスケジュールを作成できるよう設計されており、ユーザーごとに細かいスケジュールを大量発行する用途にも向く
  • 失敗時のリトライと、配信できないペイロードを退避する **DLQ(デッドレターキュー)**を設定できる
  • 一度きりのスケジュールは、実行後に自動で削除する設定にもできる
EventBridge ルールとの違い

従来の EventBridge ルールのスケジュールはイベントバス経由で限られたターゲットを呼びましたが、Scheduler はバスを介さず多数のサービスを直接呼び出せ、タイムゾーンや実行ウィンドウなどスケジュール専用の機能を持ちます。

内部の仕組み

スケジュールを作成すると、Scheduler はその式を評価して次回の起動時刻を内部で管理します。時刻が来ると、指定された実行ロールを引き受けてターゲットの API を直接呼び出し、定義したペイロードを渡します。柔軟な時間枠を有効にすると、指定時刻ちょうどに集中させず一定の範囲内で分散して起動するため、下流サービスへの瞬間的な負荷集中(サンダリングハード)を避けられます。呼び出しに失敗した場合は設定に従ってリトライし、それでも届かないものは DLQ へ送られます。

設計パターン / ベストプラクティス

  • 定期バッチの起動: 夜間のレポート生成やデータ集計を cron 式で定時起動する
  • ユーザー単位の予約実行: 「サインアップから24時間後にフォローアップ」のような一度きりの予約を、ユーザーごとに大量に作る
  • 負荷の平準化: 多数のジョブが同時刻に集中する場合は、柔軟な時間枠で起動を分散させる
  • タイムゾーン基準の運用: 利用者の現地時間に合わせた起動はタイムゾーン指定で表現し、UTC 換算を自前で持たない
  • 失敗の退避: リトライと DLQ を必ず設定し、取りこぼした起動を後から追えるようにする
ペイロードは起動の合図として軽く保つ

ターゲットへ渡すペイロードには上限があります。大きなデータは Scheduler に持たせず、S3 などへの参照だけを渡して、実処理はターゲット側で取得する設計が安全です。

運用・監視

  • スケジュールの起動状況や失敗は CloudWatch メトリクスで監視する(呼び出し数・失敗数など)
  • 起動はされるのにターゲットが動かない場合は、実行ロールの権限とターゲット側の入力フォーマットを確認する
  • 配信に失敗したペイロードは DLQ に残るので、ここを定期的に確認して取りこぼしを検知する
  • 一度きりの予約を大量に使う場合は、自動削除を有効にして不要なスケジュールが残らないようにする

コスト

  • 主にスケジュールの起動回数に応じた課金で、一定の無料利用枠が用意されている
  • サーバーやデーモンを常時動かす必要がないため、待機中のコストが発生しない点が EC2 上の cron との大きな違い
  • 一度きりの予約を実行後に自動削除すれば、不要なリソースを残さずコストと管理負荷を抑えられる
  • 具体的な単価や無料枠の数値は変動しうるため、最新の料金ページで確認する

セキュリティ

  • スケジューラがターゲットを呼ぶ権限は実行ロール(IAM ロール)で与え、必要なアクションだけに最小権限で絞る
  • スケジュールやペイロードは保管時に暗号化され、必要に応じて KMS による管理を組み合わせられる
  • スケジュールグループにタグを付け、IAM ポリシーでグループ単位のアクセス制御を行える
  • 機微なデータはペイロードに直接含めず、参照や Secrets Manager 経由での取得を検討する

関連サービス・比較

観点EventBridge SchedulerEventBridge ルール
主目的時刻起動の予約実行イベントの内容で振り分け
起動契機cron・レート・一度きり到着したイベント
ターゲット多数のサービスを直接バス経由で限定的
独自機能タイムゾーン・実行ウィンドウイベントパターンの照合

ハンズオン / CLI例

# 毎日午前3時(東京時間)にLambdaを実行する定期スケジュール
aws scheduler create-schedule --name nightly-report \
  --schedule-expression "cron(0 3 * * ? *)" \
  --schedule-expression-timezone "Asia/Tokyo" \
  --flexible-time-window '{"Mode":"FLEXIBLE","MaximumWindowInMinutes":15}' \
  --target '{
    "Arn":"arn:aws:lambda:ap-northeast-1:123456789012:function:nightly-report",
    "RoleArn":"arn:aws:iam::123456789012:role/SchedulerExecutionRole"
  }'

# 指定時刻に1回だけSQSへメッセージを送る予約(実行後に自動削除)
aws scheduler create-schedule --name reminder-once \
  --schedule-expression "at(2026-07-01T09:00:00)" \
  --schedule-expression-timezone "Asia/Tokyo" \
  --flexible-time-window '{"Mode":"OFF"}' \
  --action-after-completion "DELETE" \
  --target '{
    "Arn":"arn:aws:sqs:ap-northeast-1:123456789012:reminders",
    "RoleArn":"arn:aws:iam::123456789012:role/SchedulerExecutionRole",
    "Input":"{\"userId\":\"u-1001\"}"
  }'

AWS Service

Amazon EventBridge Schedulerを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

アプリ統合

比較で見る軸

クラウド: AWS / カテゴリ: アプリ統合 / 難易度: basic

導入後に効く点

ルールやイベントバスを使わず多数のAWSサービスを直接呼べる。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
AWS
カテゴリ
アプリ統合
難易度
basic
関連資格
SAA-C03 / DVA-C02 / DOP-C02
設計柱
operational / reliability / cost

判断チェックリスト

  • 自社の用途が「アプリ統合 / operational」に近いか確認する。
  • 強みである「cron・レート・一度きりの予約で処理を時刻起動する専用サービス。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

アプリ統合operationalreliabilitycostSAA-C03