EventBridge SchedulerのAPI｜cron式・手動実行・上限と料金の実装ガイド

Amazon EventBridge Schedulerは、cron式やrate式で指定した時刻にAWSのAPIを直接呼び出すフルマネージドのスケジューラです。AWSは従来のスケジュールされたルールを「EventBridgeのレガシー機能」と明記し、定時起動にはSchedulerの利用を推奨しています。この記事では、CreateScheduleを中心とする12のAPI操作、cron式とタイムゾーンの評価規則、即時実行のAPIが存在しない前提での手動実行の手順、CloudFormation・Terraform・CDKでの定義、リージョン別のクォータと料金を、AWS公式ドキュメントの記載値に沿って整理します。

まとめ

• Scheduler APIの操作は12個だけです。スケジュール5操作、スケジュールグループ4操作、タグ3操作で構成され、スケジュールを即時実行する操作は存在しません。
• 手動実行は、1〜2分後を指す at 式の単発スケジュールを ActionAfterCompletion=DELETE 付きで作るのが正攻法です。ターゲットのAPIを直接叩く方法では、実行ロールの権限もスケジュール式も検証できません。
• cron式は6フィールド（分 時 日 月 曜日 年）です。日フィールドと曜日フィールドの両方に * は指定できず、片方は ? にします。
• タイムゾーンはIANAのTime Zone Databaseで指定でき、サマータイムは自動調整されます。春の時刻前進で存在しない時刻に当たる回はスキップ、秋の時刻巻き戻しでは1回だけの実行になります。
• フレックスタイムウィンドウは Mode が必須で OFF か FLEXIBLE、幅は1〜1440分です。時刻精度が要る処理では使いません。
• クォータはリージョンで異なります。ap-northeast-1（東京）はスケジュール数1,000万件、CreateSchedule 5,000 TPS、呼び出しスロットル1,000 TPSで、いずれも引き上げ申請が可能です。
• 料金は月間14,000,000回の呼び出しまで無料、それ以降は100万回あたり1.00 USDです。

EventBridge SchedulerとEventBridgeルールの使い分け

EventBridge Schedulerは、EventBridge本体（イベントバスとルール）とは別のAPIエンドポイントとサービス名前空間を持つコンポーネントです。エンドポイントは scheduler、リソースARNは arn:aws:scheduler:... で、IAMのアクションも scheduler:CreateSchedule のように分かれています。EventBridge本体の役割分担についてはAmazon EventBridgeとは｜イベント駆動連携の仕組み・料金・実装と採用判断を解説を参照してください。

上限とターゲット数の構造差

ルール数の上限300には例外があり、af-south-1 と eu-south-1 は100です。東京リージョンの呼び出しスロットルはEventBridgeルール側（2,250 TPS）のほうが高い点も見落としがちですが、Scheduler側の1,000 TPSは引き上げ申請の対象で、AWSは数万TPSまで調整可能と明記しています。

選択の判断基準

時刻起動が目的なら、新規構築ではSchedulerを選びます。AWS公式のスケジュールされたルールの解説ページには「Scheduled rules are a legacy feature of EventBridge.」という注記があり、「We recommend that you use Scheduler to invoke targets on a schedule.」と推奨先まで明示されているためです。ルール数300という上限も、テナントごとやユーザーごとにスケジュールを発行する設計では早期に枯渇します。

EventBridgeルールを選ぶ理由が残るのは2つの場合だけです。1つは、1回の起動で最大5つのターゲットへ同時に配信したい場合。もう1つは、時刻起動ではなくS3やCodePipelineなどが発行するイベントのパターンマッチングが目的の場合です。この2つに当てはまらないのにルールを使い続けている構成は、上限に達してから移行するより先に移しておくほうが安全でしょう。

Step Functionsとの役割分担

Schedulerとよく比較されるAWS Step Functionsは、競合ではなく接続先です。Schedulerが担うのは「いつ起動するか」だけで、起動後の分岐・リトライ・待機・並列実行といったワークフロー制御はStep Functions側の役割になります。

両者を組み合わせるときは、Schedulerのテンプレートターゲット StartExecution にステートマシンのARNを渡します。逆に、複数ステップの処理をSchedulerだけで組もうとしてスケジュールを時刻でつなぐ設計は避けてください。前段の処理が遅延しても後段は予定時刻に走るため、依存関係が壊れます。ステートマシンの構成はAWS Step Functionsとは？ステートマシンの仕組み・料金と2種のワークフロー・採用判断を実装者目線で解説で確認できます。

スケジュール式の3タイプとタイムゾーン・サマータイムの評価規則

すべてのスケジュールタイプは60秒精度で動作します。1:00に設定した場合、フレックスタイムウィンドウを使わなければ 1:00:00 から 1:00:59 の間にターゲットのAPIが呼ばれます。秒単位の起動保証はありません。

rate式による一定間隔の起動

構文は rate(値 単位) で、値は正の整数、単位はAPIリファレンス上 minute／minutes／hour／hours／day／days が有効です。StartDate を指定しない場合、スケジュールを作成して有効化した直後から起動が始まります。

サマータイムを採用する地域でも、rate(1 days) は「時計上の24時間」ではなく前回起動から24時間後として評価されます。日が23時間や25時間になる日をまたぐと、起動時刻が1時間ずれる点に注意が必要です。日次バッチで時刻を固定したいならrate式ではなくcron式を使います。

cron式の6フィールドとワイルドカード

構文は cron(分 時 日 月 曜日 年) の6フィールドです。UNIXのcronは5フィールドなので、年フィールドを忘れると ValidationException になります。

日フィールドと曜日フィールドの両方に * を指定することはできません。片方に * を使うなら、もう片方は「任意」を意味する ? にします。L は月末または週末、W は指定日に最も近い平日を表し、曜日フィールドの # は月内の何番目かを指定します。たとえば 3#2 は第2火曜日です。# を使うときは曜日フィールドに式を1つしか書けず、3#1,6#3 は2つの式と解釈されて無効になります。

# 毎日9時（指定タイムゾーン）
cron(0 9 * * ? *)

# 毎月最終金曜日の10:15、2026年から2027年まで
cron(15 10 ? * 6L 2026-2027)

# 平日の毎時0分と30分
cron(0,30 * ? * MON-FRI *)

at式による単発起動と実行後の後始末

構文は at(yyyy-mm-ddThh:mm:ss) です。単発スケジュールでは StartDate と EndDate は無視されます。

ここが運用上の落とし穴です。実行済みの単発スケジュールも、削除するまでリージョンのスケジュール数クォータを消費し続けます。AWSはクォータ表の注記で「We recommend configuring your schedules to automatically delete after completion using the ActionAfterCompletion feature.」と自動削除を推奨しており、値は NONE（既定）か DELETE の2つです。単発スケジュールを動的に発行する設計では、作成時に DELETE を必ず指定してください。

cron式やrate式の定期スケジュールに DELETE を付ける場合は条件が1つ増えます。公式ドキュメントは「If you configure a schedule with automatic deletion but do not specify a value for EndDate, EventBridge Scheduler does not automatically delete the schedule.」と述べており、EndDate を指定しない定期スケジュールは DELETE を設定しても削除されません。削除の起点は最終起動、つまり EndDate に最も近い起動だからです。

タイムゾーンとサマータイムの挙動

タイムゾーンはIANAのTime Zone Databaseに基づき ScheduleExpressionTimezone（CLIでは --schedule-expression-timezone）で指定します。Asia/Tokyo のようなIANA名を渡します。

サマータイムは自動調整されます。America/Los_Angelesで cron(30 2 * * ? *)（毎日2:30）を設定した場合の挙動は次のとおりです。

• 春の時刻前進（1:59から3:00へ）: その日の起動はスキップされ、翌日から通常どおり再開します。
• 秋の時刻巻き戻し（2:59から2:00へ）: 巻き戻し前の2:30に1回だけ実行され、巻き戻し後の2:30には再実行されません。

日本標準時はサマータイムを採用しないため、Asia/Tokyo ではこの調整は発生しません。UTC指定のスケジュールも同様に対象外です。海外拠点の業務時間に合わせるスケジュールを組むときだけ、上の2つの挙動が意味を持ちます。

フレックスタイムウィンドウの設定値と使いどころ

FlexibleTimeWindow はCreateScheduleの必須パラメータです。省略はできず、使わない場合も {"Mode":"OFF"} を明示する必要があります。

FLEXIBLE にすると、指定時刻を起点とする最大1440分（24時間）のウィンドウ内でEventBridge Schedulerが起動タイミングを決めます。数千件のスケジュールを同じ時刻に集中させた場合の詰まりどころは、ターゲット側（Lambdaの同時実行数、RDSの接続数、外部APIのレート制限）です。ウィンドウを15分から60分程度取れば、その山を平坦化できます。

逆に、締め処理や外部システムとの時刻合わせなど、実行時刻そのものが要件になっている処理にFLEXIBLEを使ってはいけません。起動時刻はウィンドウ内のどこになるか制御できず、ログ上の実行時刻から「遅延」と「仕様どおり」を区別できなくなります。この用途では OFF を選び、代わりにスケジュール自体の時刻を数分ずつずらして分散させます。

ターゲット指定の2方式と実行ロール

1つのスケジュールに指定できるターゲットは1つで、テンプレートターゲットかユニバーサルターゲットのいずれかを選びます。どちらの方式でも、ターゲットのAPIを呼ぶ権限を持つ実行ロール（RoleArn）が必須です。

テンプレートターゲットの対応サービス

主要サービスの代表的なAPI操作は、リソースのARNを渡すだけで呼び出せます。ただし一部のターゲットは追加の必須パラメータを伴います。対応は次の12種です。

EventBridgeのPutEventsをテンプレートターゲットにする場合、クロスリージョン配信はできません。別リージョンのイベントバスへ送るには、送信先リージョン側にスケジュールを作る必要があります。

ユニバーサルターゲットのARN形式と非対応API

テンプレートに無いAPIは、270を超えるサービス・6,000を超えるAPI操作を対象とするユニバーサルターゲットで呼び出します。ARNの形式は arn:aws:scheduler:::aws-sdk:サービス:APIアクション です。

この形式には2つの罠があります。1つ目、サービス はエンドポイントのプレフィックスではなくAWS SDKのサービス識別子です。Amazon Cognito Identity Providerは cognito-idp ではなく cognitoidentityprovider を指定します。2つ目、APIアクション は先頭が小文字のcamelCaseです。SendCommand ではなく arn:aws:scheduler:::aws-sdk:ssm:sendCommand と書きます。ARNの形は正しいのに呼び出しが失敗する原因の多くが、このどちらかです。

さらに、EventBridge Schedulerは読み取り系のAPIをターゲットにできません。次のプレフィックスで始まる操作はすべて非対応です。

get, describe, list, poll, receive, search, scan, query, select,
read, lookup, discover, validate, batchGet, batchDescribe, batchRead,
transactGet, adminGet, adminList, testMigration, retrieve,
testConnection, translateDocument, isAuthorized, invokeModel

たとえばSQSの GetQueueUrl は get 始まりなので指定できず、Amazon MQの ListBrokers も list 始まりのため使えません。定期的にデータを取得したい要件は、取得APIを直接ターゲットにするのではなく、取得処理を書いたLambda関数（AWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説）をターゲットにする形へ組み替えます。

コンテキスト属性によるメタデータ受け渡し

ターゲットへ渡す Input（最大256KB）に次のキーワードを書くと、起動時に実際の値へ置換されます。

実務で効くのは scheduled-time と execution-id の組み合わせです。前者を処理対象日として渡せば、リトライで遅れて実行された処理も本来の対象日で動きます。後者はログの相関IDに向き、リトライ分を含めて1回の起動を追跡できます。attempt-number をペイロードに含めておけば、リトライ時だけ通知を抑制するといった分岐も書けるでしょう。

Scheduler APIとSDKによるスケジュール操作

APIの全12操作

UpdateScheduleは部分更新ではなく全項目の置き換えです。省略したフィールドは既定値に戻ってしまうため、GetScheduleで現在の定義を取得し、変更点だけ差し替えてから渡す実装にします。

AWS CLIでのスケジュール作成

aws scheduler create-schedule \
  --name nightly-batch \
  --group-name default \
  --schedule-expression "cron(0 9 * * ? *)" \
  --schedule-expression-timezone "Asia/Tokyo" \
  --flexible-time-window '{"Mode":"FLEXIBLE","MaximumWindowInMinutes":15}' \
  --target '{
    "RoleArn": "arn:aws:iam::123456789012:role/scheduler-exec-role",
    "Arn": "arn:aws:lambda:ap-northeast-1:123456789012:function:nightly-batch",
    "Input": "{\"scheduledTime\":\"<aws.scheduler.scheduled-time>\"}",
    "RetryPolicy": {"MaximumRetryAttempts":3,"MaximumEventAgeInSeconds":3600},
    "DeadLetterConfig": {"Arn":"arn:aws:sqs:ap-northeast-1:123456789012:scheduler-dlq"}
  }'

RetryPolicy の指定可能範囲は、MaximumRetryAttempts が0〜185回、MaximumEventAgeInSeconds が60〜86400秒です。リトライは指数バックオフで行われ、回数の上限か経過時間の上限のどちらかに達した時点で打ち切られます。打ち切られた分を捨てたくない場合は DeadLetterConfig にSQSキューを指定してください。指定しない限り、失敗した起動はどこにも残りません。

boto3での操作

import json
import boto3

# サービス名は "events" ではなく "scheduler"
scheduler = boto3.client("scheduler", region_name="ap-northeast-1")

resp = scheduler.create_schedule(
    Name="nightly-batch",
    ScheduleExpression="cron(0 9 * * ? *)",
    ScheduleExpressionTimezone="Asia/Tokyo",
    FlexibleTimeWindow={"Mode": "FLEXIBLE", "MaximumWindowInMinutes": 15},
    Target={
        "RoleArn": "arn:aws:iam::123456789012:role/scheduler-exec-role",
        # テンプレートターゲット: Lambda関数のARNをそのまま渡す
        "Arn": "arn:aws:lambda:ap-northeast-1:123456789012:function:nightly-batch",
        "Input": json.dumps({"scheduledTime": "<aws.scheduler.scheduled-time>"}),
        "RetryPolicy": {"MaximumRetryAttempts": 3, "MaximumEventAgeInSeconds": 3600},
    },
)
print(resp["ScheduleArn"])

boto3で最も多い誤りが boto3.client("events") を使ってしまうことです。events はEventBridge本体のクライアントで、create_schedule は生えていません。EventBridge Schedulerのクライアント名は scheduler です。

命名にも制約があります。スケジュール名は1〜64文字で、使える文字は [0-9a-zA-Z-_.] のみです。テナントIDやメールアドレスをそのまま名前にすると、記号でValidationExceptionになります。同名のスケジュールを二重作成しないためには ClientToken（1〜64文字）を渡しますが、こちらの許容文字は [a-zA-Z0-9-_] でドットが使えません。スケジュール名用の命名規則をそのまま流用すると、ドットを含む値で落ちます。

スケジュールの手動実行と動作確認

「作ったスケジュールを今すぐ1回動かして確認したい」という要件に対し、EventBridge Schedulerには専用のAPIがありません。前掲の12操作のとおり、即時実行やテスト起動に相当する操作は定義されていないためです。実務ではat式による正攻法と、ターゲット直接呼び出しによるデバッグ用の手段を使い分けます。

at式の単発スケジュールによる実行（推奨）

1〜2分後を指す単発スケジュールを作り、実行後に自動削除させます。本番と同じ実行ロール・同じターゲット定義・同じ入力を通るので、権限不足やInput形式の誤りをそのまま検出できます。

# 2分後に1回だけ実行し、完了後にスケジュールを自動削除する
aws scheduler create-schedule \
  --name nightly-batch-manual-test \
  --schedule-expression "at($(date -u -v+2M '+%Y-%m-%dT%H:%M:%S'))" \
  --action-after-completion DELETE \
  --flexible-time-window '{"Mode":"OFF"}' \
  --target '{
    "RoleArn": "arn:aws:iam::123456789012:role/scheduler-exec-role",
    "Arn": "arn:aws:lambda:ap-northeast-1:123456789012:function:nightly-batch",
    "Input": "{\"scheduledTime\":\"<aws.scheduler.scheduled-time>\"}"
  }'

at式のタイムスタンプにタイムゾーンは含められないため、--schedule-expression-timezone を指定しない場合はUTCで解釈されます。上のコマンドは date -u でUTCの2分後を生成しています（GNU coreutilsの環境では date -u -d '+2 minutes' '+%Y-%m-%dT%H:%M:%S' に読み替えてください）。--action-after-completion DELETE を付け忘れると、テスト用のスケジュールがリージョンのクォータを消費したまま残ります。

ターゲットAPIの直接呼び出しと検証範囲の限界

aws lambda invoke \
  --function-name nightly-batch \
  --payload '{"scheduledTime":"2026-08-05T00:00:00Z"}' \
  --cli-binary-format raw-in-base64-out \
  /tmp/out.json

この方法で確認できるのは関数側のロジックだけです。スケジュール式の解釈も、実行ロールの権限も、Inputの受け渡しも検証していません。「手で叩けば動くのに定時に動かない」という障害の大半は、この差分（実行ロールに lambda:InvokeFunction が無い、Inputが期待するJSONになっていない）が原因です。関数のデバッグ中はこちらで回し、結合確認は前項のat式で行う、という切り分けが実務的でしょう。

補足：移行元のEventBridgeルールを試すとき

移行前の構成がEventBridgeルールで、イベントパターンのマッチングを確認したい場合は、put-events でテストイベントを流します。スケジュールされたルールにはこの方法が使えないため、その場合はターゲットを直接呼ぶことになります。

aws events put-events --entries '[{
  "Source": "com.example.batch",
  "DetailType": "manual-test",
  "Detail": "{\"reason\":\"pattern check\"}"
}]'

IaCでの定義（CloudFormation・Terraform・CDK）

CloudFormation（AWS::Scheduler::Schedule）

Resources:
  NightlyBatchSchedule:
    Type: AWS::Scheduler::Schedule
    Properties:
      Name: nightly-batch
      GroupName: default
      State: ENABLED
      ScheduleExpression: cron(0 9 * * ? *)
      ScheduleExpressionTimezone: Asia/Tokyo
      FlexibleTimeWindow:
        Mode: FLEXIBLE
        MaximumWindowInMinutes: 15
      Target:
        Arn: !GetAtt NightlyBatchFunction.Arn
        RoleArn: !GetAtt SchedulerExecutionRole.Arn
        RetryPolicy:
          MaximumRetryAttempts: 3
          MaximumEventAgeInSeconds: 3600

スケジュールグループは AWS::Scheduler::ScheduleGroup で別リソースとして定義します。グループ名を省略すると default グループに入るため、環境やテナントごとにタグやIAMポリシーで分離できなくなります。権限を分ける前提があるなら、最初からグループを切っておくほうが後の分離が楽です。テンプレートの基本構文はAWS CloudFormationとは？テンプレートの書き方から使い方までわかりやすく解説で確認できます。

Terraform（aws_scheduler_schedule）

resource "aws_scheduler_schedule" "nightly_batch" {
  name       = "nightly-batch"
  group_name = "default"

  schedule_expression          = "cron(0 9 * * ? *)"
  schedule_expression_timezone = "Asia/Tokyo"
  action_after_completion      = "DELETE"
  state                        = "ENABLED"
  end_date                     = "2027-01-01T00:00:00Z"

  flexible_time_window {
    mode                      = "FLEXIBLE"
    maximum_window_in_minutes = 15
  }

  target {
    arn      = aws_lambda_function.nightly_batch.arn
    role_arn = aws_iam_role.scheduler_exec.arn

    retry_policy {
      maximum_retry_attempts       = 3
      maximum_event_age_in_seconds = 3600
    }

    dead_letter_config {
      arn = aws_sqs_queue.scheduler_dlq.arn
    }
  }
}

flexible_time_window と target は必須ブロックです。action_after_completion はAWS provider 6.14.0（2025年9月18日リリース）で追加された引数で、それ以前のバージョンでは Unsupported argument になります。上の例のように定期スケジュールへ DELETE を指定する場合は、前述のとおり end_date の併記が必要です。

name は省略できますが、省略するとTerraformが terraform- で始まるランダムな名前を割り当てます。name と group_name はいずれも変更時にリソースの再作成が走る属性なので、命名規則は最初に固めておきましょう。

AWS CDK（aws-cdk-lib/aws-scheduler）

CDKのSchedulerモジュールは長らくalpha扱いでしたが、@aws-cdk/aws-scheduler-alpha は 2.186.0-alpha.0（2025年3月27日公開）を最後に「安定化してaws-cdk-libへ移動した」として非推奨になりました。現在は aws-cdk-lib/aws-scheduler と aws-cdk-lib/aws-scheduler-targets を直接importします（aws-cdk-lib 2.263.0で確認）。

import { Duration, TimeZone } from 'aws-cdk-lib';
import { Schedule, ScheduleExpression, TimeWindow } from 'aws-cdk-lib/aws-scheduler';
import { LambdaInvoke } from 'aws-cdk-lib/aws-scheduler-targets';

// Stackのコンストラクタ内。nightlyBatchFn は lambda.IFunction、schedulerDlq は sqs.IQueue
new Schedule(this, 'NightlyBatch', {
  scheduleName: 'nightly-batch',
  schedule: ScheduleExpression.cron({
    minute: '0',
    hour: '9',
    timeZone: TimeZone.ASIA_TOKYO,
  }),
  target: new LambdaInvoke(nightlyBatchFn, {
    retryAttempts: 3,
    maxEventAge: Duration.hours(1),
    deadLetterQueue: schedulerDlq,
  }),
  timeWindow: TimeWindow.flexible(Duration.minutes(15)),
});

alpha時代のコードを移行する場合、importパスの変更だけで済むことがほとんどです。ただし依存関係に @aws-cdk/aws-scheduler-alpha を残したまま両方からimportして混在させると、同名クラスが別の型として扱われ型エラーになります。移行時はimport元をaws-cdk-libへ寄せきってください。CDK全体の位置づけはAWS CDK（cdk）とは？仕組み・使い方とCloudFormation・Terraformとの違いを参照してください。

クォータ・スループットと料金の見積もり

リージョンで変わるクォータ

クォータはリージョン単位で、しかも主要リージョンとそれ以外で値が違います。次はap-northeast-1（東京）を含む主要11リージョンの既定値です。

主要リージョンは us-east-1、us-east-2、us-west-2、ap-northeast-1、ap-south-1、ap-southeast-1、ap-southeast-2、eu-central-1、eu-west-1、eu-west-2、sa-east-1 です。大阪リージョン（ap-northeast-3）はこの一覧に含まれないため、CreateScheduleが250 TPSになります。数万件のスケジュールを一括投入する初期移行では、この差が所要時間に直結するでしょう。

呼び出しスロットルの超過は、他のAPIスロットリングと挙動が異なります。リクエストが拒否されるのではなく、起動が遅延します。エラーとして観測されないため、同時刻に大量のスケジュールを集中させている構成では「原因不明の実行遅れ」として現れるのが厄介な点です。フレックスタイムウィンドウで分散させるか、上限引き上げを申請してください。

TagResourceとUntagResourceの1 TPSも見落としやすい制約です。スケジュールを大量に作りながらタグを付ける処理は、作成側（5,000 TPS）ではなく書き込み系のタグAPIで詰まります。読み取りの ListTagsForResource は10 TPSで、書き込みとは別の値です。

料金

EventBridge Schedulerは月間14,000,000回の呼び出しまで無料で、それ以降は100万回あたり1.00 USDです。1分ごとに起動するスケジュールは月あたり約43,200回なので、無料枠だけで300本強を賄える計算になります。スケジュールを保持しているだけでは課金されず、課金対象は起動回数です。

EventBridge本体（イベントバス）の課金体系は別で、カスタムイベントは100万件あたり1.00 USD、ペイロードは64KBごとに1件として計上されます。両者を混同した見積もりになりやすいため、内訳はAmazon EventBridgeの料金｜無料になる条件と64KB課金の落とし穴で確認してください。

よくある質問

EventBridge Schedulerのスケジュールを手動実行できますか

即時実行のAPIはありません。Scheduler APIの操作は12個で、そこに実行系の操作が含まれないためです。実務では、1〜2分後を指すat式の単発スケジュールを ActionAfterCompletion=DELETE 付きで作成する方法を使います。ターゲットのAPIを直接呼ぶ方法では、実行ロールの権限やInputの受け渡しを検証できません。

EventBridgeのスケジュールされたルールとの違いは何ですか

上限とターゲット数、時刻表現の3点が違います。ルールはイベントバスあたり300件・1ルールに最大5ターゲット・UTC固定です。Schedulerはリージョンあたり1,000万件・1スケジュールに1ターゲット・IANAタイムゾーン指定とサマータイム自動調整に対応します。AWSはスケジュールされたルールをレガシー機能と位置づけ、定時起動にはSchedulerを推奨しています。1回の起動で複数ターゲットへ配信したい場合とイベントパターンでのマッチングが必要な場合だけ、ルール側に理由が残ります。

Step FunctionsとEventBridge Schedulerはどう使い分けますか

Schedulerは起動トリガー、Step Functionsは起動後のワークフロー制御という分担です。分岐・リトライ・待機・並列実行が必要ならステートマシンを組み、その起動をSchedulerのテンプレートターゲット StartExecution に任せます。複数ステップを時刻でつないでSchedulerだけで組むと、前段の遅延が後段に伝わらず処理が壊れます。

boto3でEventBridge Schedulerを操作するクライアント名は何ですか

boto3.client("scheduler") です。boto3.client("events") はEventBridge本体のクライアントで create_schedule を持ちません。CLIも同様に aws scheduler と aws events でコマンド体系が分かれています。

EventBridge Schedulerの料金はいくらですか

月間14,000,000回の呼び出しまで無料、それ以降は100万回あたり1.00 USDです。課金対象は起動回数で、スケジュールの保持数では課金されません。EventBridge本体のカスタムイベント（100万件あたり1.00 USD、64KBごとに1件換算）とは別枠です。

関連記事

• Amazon EventBridgeとは｜イベント駆動連携の仕組み・料金・実装と採用判断を解説
• Amazon EventBridgeの料金｜無料になる条件と64KB課金の落とし穴
• AWS Step Functionsとは？ステートマシンの仕組み・料金と2種のワークフロー・採用判断を実装者目線で解説
• AWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説
• Cloud Schedulerとは？GCPのフルマネージドcronの仕組み・3つのターゲットとリトライ・料金、Cloud Tasksとの違いを実装者目線で解説