Amazon EventBridgeの料金｜無料になる条件と64KB課金の落とし穴

Amazon EventBridgeの料金は、公式の料金表を眺めても「結局いくらかかるのか」が掴みにくい。理由は、課金されるのがイベントの取り込み（ingest）だけで、多くの人が課金対象だと思っている部分——ルールの作成、cronでの定期実行、AWSサービスが出すイベント——がすべて無料だからだ。この記事では、2026年7月時点の公式料金表をもとに、課金される要素とされない要素を切り分け、64KBごとに1イベントとして請求される課金単位、ケース別の月額試算、請求が跳ねたときに疑う原因、そしてSQS・SNSではなくEventBridgeを選ぶ判断基準までを整理する。

まとめ：EventBridgeの料金で押さえるべき7点

• 課金対象はイベントの取り込みのみ。カスタムイベントは100万件あたり1.00 USD。無料枠は無い。
• AWSサービスが発行するイベントの取り込みは無料。EC2の状態変化やS3の更新に、同一アカウント内で反応させる構成なら、EventBridge本体の料金は0のまま。
• ルール（cron/rate）の定期実行にも課金されない。「EventBridgeで毎朝バッチを起動する」だけならEventBridge料金は発生せず、コストは呼び出されるLambda等のターゲット側にだけ乗る。
• 課金単位は64KB。1件のペイロードが128KBなら2イベント、256KBなら4イベントとして請求される。件数だけ見ていると請求額が合わない。
• EventBridge Schedulerは月1,400万回まで無料（全リージョン合算・恒久）。超過分は100万回あたり1.00 USD。5分間隔の定期実行（月約8,600回）は無料枠に収まる。
• 請求が跳ねるのは5パターン：カスタムイベントの大量発行、64KB超の大きなペイロード、クロスアカウント配信、Pipes／API送信先、アーカイブとリプレイ。
• 宛先が1つで分岐が要らない高頻度メッセージにEventBridgeは割高。ルーティングとフィルタリングに払う金額なので、それが不要ならSQS/SNSを直結したほうがよい。

EventBridgeで課金されるもの・されないもの

EventBridgeは3つの部品でできている。イベントの通り道であるイベントバス、届いたイベントを条件で振り分けるルール、そして転送先のターゲット（LambdaやSQSなど）だ。料金が発生するのはこのうちイベントバスへの取り込みだけで、ルールもターゲットへの配信もEventBridge側では無料になる。この線引きから入ると理解が早い。

課金されるのはイベントの取り込みだけ

課金対象になるのは、次の3種類の取り込みだ。単価はいずれも公式料金表（2026年7月時点）の値で、東京リージョンを含む商用リージョンで共通している（中国リージョンとGovCloudは別体系）。

• カスタムイベント：自社アプリケーションが PutEvents で発行するイベント。100万件あたり1.00 USD。
• パートナー(SaaS)イベント：ZendeskやDatadogなどのSaaSパートナーイベントソースから届くイベント。100万件あたり1.00 USD。
• クロスアカウント配信：別アカウントのイベントバスへ転送した分。カスタムイベントは100万件あたり1.00 USD、パートナーイベントは100万件あたり0.05 USD。発行元アカウントでの取り込みと合わせると、カスタムイベントは実質2.00 USD／100万件になる。

無料になるもの：AWSサービス発のイベント、ルール、スケジュール実行

ここが最も誤解されている。EventBridgeの請求書が薄い（あるいは0円の）構成は珍しくない。

• AWSサービスが発行するイベントの取り込み：EC2のインスタンス状態変化、CodePipelineのステージ遷移、S3のオブジェクト作成といったAWS管理イベントは、デフォルトイベントバスへ無料で取り込まれる。250を超えるAWSサービスが対象で、件数が何百万件になっても取り込み料金は0。
• ルールそのもの：ルールを何本作っても、保持しても課金されない。「ルールを増やすと高くなる」は誤り。
• スケジュールルール（cron/rate）の実行：EventBridgeルールによるcron実行には、イベント取り込み料金がかからない。定期実行の費用は、起動されるLambdaやECSタスクといったターゲット側にだけ発生する。
• スキーマレジストリ：レジストリの利用は無料。スキーマ検出（Schema Discovery）も月500万イベントまで無料枠がある（こちらは8KBごとに1イベント換算）。

ターゲットへの配信そのものにもEventBridgeの追加料金はかからない。ただし呼び出されたLambda、SQS、Step Functionsの料金は各サービス側で発生する。EventBridgeの請求だけを見て安心し、Lambdaの実行料金を見落とすのが典型的な計算ミスだ。関数側のコストはAWS Lambda関数のモニタリングで実行回数と実行時間を可視化しておくと切り分けやすい。

機能別の単価と64KB課金単位

単価一覧（2026年7月時点・公式料金表）

Pipesの0.40 USDはフィルタを通過したリクエストだけが対象で、フィルタで落ちた分は課金されない。アーカイブは保存料金（0.023 USD/GB・月）だけでなく、書き込み時のアーカイブ処理（0.10 USD/GB）が別に発生する点に注意する。単価は変更されうるため、見積もりの最終確認はAWS公式のEventBridge料金ページで行うこと。

64KBごとに1イベント：ペイロード肥大がそのまま請求額になる

公式料金表は「ペイロードは64KBごとにまとめて1件のイベントとして請求されます」と明記している。つまり請求されるイベント数は、発行した件数ではなく64KBチャンクの総数だ。

2KBでも64KBでも料金は同じなので、64KBに収まっている限りペイロードの節約に意味はない。問題は64KBを超えたときで、そこから先は線形に増える。イベントに巨大なJSONやBase64エンコードしたファイルを載せている構成は、まずここを疑う。AWSも1エントリが256KBを超える場合はS3にアップロードしてオブジェクトURLをイベントに載せるよう案内している。実データをS3に置き、イベントには参照キーだけを載せれば（claim-check パターン）、課金イベント数は1件に戻る。

月額料金の試算：3つのケース

実際の構成に当てはめると、EventBridge本体の料金がどれだけ小さいかが見える。以下はいずれも東京リージョン・2026年7月の単価による概算で、ターゲット側（Lambda等）の料金は含まない。

ケース1：AWSサービスのイベントに反応させる（EventBridge料金 0 USD）

EC2インスタンスの停止を検知してLambdaで通知する、CodePipelineの失敗をSlackへ流す、といった構成。イベント発行元がAWSサービスなので、取り込みは何件でも無料。ルールも無料。同一アカウント内で完結する限り、月間何百万イベントでもEventBridgeの請求は0 USDで、コストはLambdaの実行分だけになる。EventBridgeが「安い」と言われる実体はこれだ。ただし別アカウントのイベントバスへ集約する構成にすると、AWSサービス発のイベントでもクロスアカウント配信として100万件あたり1.00 USDが発生する。

ケース2：カスタムイベントを月1,000万件発行する（10 USD＋α）

マイクロサービス間の連携で、注文確定や在庫更新を自社アプリからPutEventsで発行する構成。ペイロードが64KB以内なら 1,000万 ÷ 100万 × 1.00 = 10.00 USD/月。ここに、外部SaaSへ飛ばすAPI送信先（1,000万イベントで2.00 USD）や、アーカイブのコストが乗る。アーカイブは保存だけでなく書き込み処理にも課金されるため、1件6KBのイベントを月200万件保存するなら処理が約1.14 USD、保存が約0.26 USD/月という内訳になる。それでも月十数ドルの規模で、ルーティングを自前実装する工数と比べれば安い。

ケース3：Schedulerで5分間隔のバッチを回す（0 USD）

5分間隔は月に約8,640回。EventBridge Schedulerの無料枠は月1,400万回なので、桁が3つ以上足りない。無料枠に収まり0 USD。スケジュールの最小粒度である1分間隔で回しても月約43,200回で、無料枠の0.3%にしかならない。スケジューラの料金を心配して自前のcronサーバーを立てるのは、EC2代のぶんだけ確実に損をする。

EventBridge Schedulerの料金とルール（cron）の使い分け

定期実行の手段が2つあり、料金体系も違うため混乱しやすい。整理するとこうなる。

料金だけならルールが無料で有利だが、その差は現実的にはほぼ意味を持たない。1,400万回の無料枠を使い切るには5分間隔のスケジュールを1,600本以上動かす必要があり、一般的な業務システムでそこに届くことはまず無い。新規に作るならSchedulerを選ぶべきだ。AWS自身がスケジュールルールを「レガシー」と位置づけ、スケジュール実行にはSchedulerの利用を推奨している。JSTでの実行時刻指定と一度限りの予約実行が使え、大量のスケジュールが同時刻に集中してターゲットを詰まらせる事故もフレックスタイムウィンドウで避けられる。UTC換算のcron式を手で書いて夏時間でずれる、という無駄な事故を避けるだけでも移行の価値がある。

料金が想定より高いときに疑う5つの原因

EventBridgeの請求は本来小さい。想定より大きいなら、次のどれかが起きている。ルールやターゲットの設計を含むEventBridge全体の仕組みと、SQS・SNS・Step Functionsとの使い分けはAmazon EventBridgeとはで解説しています。

• カスタムイベントの大量発行：AWSサービス発のイベントと違い、カスタムイベントには無料枠が一切ない。デバッグ用に全アクションをイベント化していないか確認する。
• 64KB超のペイロード：件数は変わらないのに請求が2倍、4倍になっているケース。1件が何チャンクに分割されているかを確認する。
• クロスアカウント配信：発行元アカウントでの取り込みと、転送先への配信で二重に課金される（カスタムイベントで実質2.00 USD／100万件）。マルチアカウント構成で監査イベントを集約している場合に効いてくる。
• PipesとAPI送信先：それぞれ100万あたり0.40 USD、0.20 USDの別課金。イベントバスの料金だけを見ていると漏れる。
• アーカイブとリプレイ：保存は0.023 USD/GB・月と安いが、書き込み時のアーカイブ処理に0.10 USD/GBがかかり、さらにリプレイでは再生したイベント数ぶん（100万件あたり1.00 USD）が新たに課金される。障害調査で全期間をリプレイすると、その月だけ請求が跳ねる。

原因の特定は、Cost Explorerで使用タイプ別に請求を分解するのが先だ。イベントバスの取り込みなのか、Pipesなのか、アーカイブなのかがそこで切れる。取り込みだと分かったら、CloudWatchのEventBridgeメトリクス（TriggeredRules、Invocations）をルール単位で見て、どのルールが件数を稼いでいるかを絞り込む。イベントパターンを広く書きすぎて意図しないイベントまで拾っている、というのがよくある落ちどころだ。

削減の打ち手は3つに集約される。イベントパターンを絞る（発行側で不要なカスタムイベントを止めるのが最も効く）、64KBを超えるペイロードをS3参照方式へ切り替える、アーカイブの保持期間を必要な日数まで短縮する。いずれも設計変更を伴わずに効き、EventBridgeの請求の大半はこの3つで説明がつく。

SQS・SNSではなくEventBridgeを選ぶ判断基準

ここは上位の解説記事がほとんど触れないが、料金を検討している段階でいちばん効く論点だ。EventBridgeに払っているのはルーティングとフィルタリングの対価であって、メッセージを運ぶこと自体の対価ではない。したがって判断はこうなる。

EventBridgeが割高になる条件

次の2つが当てはまるなら、EventBridgeは選ばないほうがよい。

• 宛先が1つに固定されている：条件分岐が不要なら、ルールとイベントパターンという仕組みそのものが遊ぶ。払っている対価に見合う機能を使っていない。
• カスタムイベントを高頻度で発行する：EventBridgeのカスタムイベントには無料枠が無く、1件目から課金される。一方でSQSには月100万リクエストの無料枠があり（公式）、小〜中規模のワークロードなら請求が0のまま収まる。

単純なキューイングにEventBridgeを挟むのは、無料枠の有無だけを見ても不利になる。SQSを直結し、宛先が増えて分岐が必要になった段階でEventBridgeを前段に足せばよい。なお、ペイロードが大きい場合の課金増は乗り換えでは解決しない。EventBridge・SQS・SNSはいずれも64KBごとに1件として課金するため、サービスを替えるより先にS3参照方式へ設計を変えるほうが効く。

EventBridgeを選んで正解になる条件

• AWSサービスのイベントに反応する：取り込みが無料になるうえ、他の手段（CloudTrail＋Lambdaのポーリング等）より確実に安く簡単だ。
• 1つのイベントを複数の宛先へ、条件付きで配る：イベントパターンによるフィルタリングをアプリ側で書かずに済む。分岐が3つ4つと増えるほど、100万件あたり1.00 USDは安く感じる。
• 定期実行が要る：ルールは無料、Schedulerも実質無料枠内で収まる。ここでコストを気にする理由は無い。

設計全体をどう組むかはサーバーレスアーキテクチャの構成パターンと併せて検討すると判断しやすい。イベントバスやルールをコードで管理するなら、AWS SAMやServerless Frameworkでテンプレート化しておくと、ルールの増減とコストの変化を追跡できる。

よくある質問

Amazon EventBridgeに無料枠はありますか？

カスタムイベントの取り込みには無料枠が無く、1件目から100万件あたり1.00 USDで課金されます。一方、AWSサービスが発行するイベントの取り込み、ルールの作成と利用、ターゲットへの配信は無料です。EventBridge Schedulerには月1,400万回の呼び出し無料枠があります。AWSサービスのイベントに同一アカウント内で反応させるだけの構成なら、EventBridgeの料金は0 USDに収まります。

EventBridgeのcron（スケジュールされたルール）は課金されますか？

課金されません。EventBridgeルールによるスケジュール実行にはイベント取り込み料金がかからず、ルールを何本作っても料金は増えません。ただし、起動されるLambda関数やECSタスクの実行料金は各サービス側で発生します。

EventBridge SchedulerとEventBridgeルールの違いは何ですか？

Schedulerは定期実行に特化した新しい機能で、任意のタイムゾーン指定、一度限りの実行、フレックスタイムウィンドウによる実行分散に対応します。料金は月1,400万回まで無料、超過分は100万回あたり1.00 USDです。ルールのスケジュールはUTCのみで一度限りの実行ができない代わりに完全無料ですが、無料枠の大きさから新規構築ではSchedulerを推奨します。

イベントバスを複数作ると料金は増えますか？

イベントバスの作成・保持自体は無料で、本数では増えません。料金はそのバスに取り込まれたカスタムイベント／パートナーイベントの件数で決まります。ただし、あるバスから別アカウントのバスへイベントを転送すると、クロスアカウント配信として100万件あたり1.00 USD（パートナーイベントは0.05 USD）が追加で発生します。

EventBridgeの料金が急に増えました。原因はどう調べますか？

まずCost Explorerで使用タイプ別に分解し、イベントバスの取り込み、Pipes、API送信先、アーカイブ・リプレイのどれが増えたかを切り分けます。取り込みが原因なら、CloudWatchの TriggeredRules と Invocations をルール単位で確認し、件数を稼いでいるルールを特定します。イベントパターンが広すぎる、64KBを超えるペイロードで1件が複数イベントに分割されている、の2つが典型的な原因です。関連する内容として、AWS SQS・SNS・SESもご覧ください。

関連記事

• サーバーレスアーキテクチャとは？構成パターン・AWS実装・採用判断を実装者目線で解説
• Serverless Frameworkとは？v4の料金・使い方・無料の代替まで【2026年最新】
• AWS SAMとは？サーバーレスアプリケーション開発における役割とメリット
• AWS Lambda関数のモニタリングに必要な基礎知識と概要
• Lambda SnapStartの概要とその基本的な特徴とは