Amazon EventBridgeとは｜仕組み・料金と他サービスの使い分け

Amazon EventBridgeとは｜イベントを振り分けるサーバーレスの仲介役

EventBridgeは、イベントを使ってアプリケーション同士をつなぐサーバーレスサービスです。AWS公式のAmazon EventBridgeユーザーガイドは、スケーラブルなイベント駆動型アプリケーションを簡単に構築するためのサービスと定義しています。

重要なのは、EventBridgeが処理そのものをしないことです。やるのは受け取り、絞り込み、変換、配達の4つだけ。実際の処理はターゲット側のLambdaやStep Functionsが担います。

EventBridgeが解決する課題

サービスAが終わったらサービスBを呼ぶ。この連携をAのコードに直接書くと、Bが増えるたびにAを修正することになります。呼び出し先が5つに増えれば、Aは5つの相手を知っている状態です。

EventBridgeを挟むと、Aは「注文が確定した」とだけ言い放てば済みます。誰が聞いているかはAの関心事から外れる。受け取る側は自分でルールを書いて、必要なイベントだけ拾います。

この疎結合のメリットが効くのは、チームやサービスが分かれている環境です。単一チームの小さなアプリなら、直接呼び出しのほうが見通しがよいケースもあります。考え方の整理はマイクロサービスとは｜モノリスとの違い・採用判断・案件動向を解説も参考になります。

押さえておく4つの用語

イベントパターンは、イベントのJSON構造と同じ形で条件を書きます。たとえば発生元がS3で、かつバケット名が特定の値のものだけを拾う、といった絞り込みです。値は配列で複数指定でき、前方一致や数値比較、ワイルドカードも使えます。

ここでの設計の勘所は、パターンを細かく書くほどターゲット側が楽になることです。粗いパターンで拾って関数の中で捨てる作りにすると、呼び出し回数ぶんの課金と実行時間が無駄になります。

CloudWatch Eventsとの関係

EventBridgeは、もともとCloudWatch Eventsという名前で提供されていた機能を拡張したものです。そのため古い記事やTerraformのリソース名には、いまもCloudWatch Events由来の名称が残っています。

APIレベルでは互換性が保たれており、CloudWatch Eventsで作ったルールはEventBridgeのコンソールからそのまま見えます。新規で作るならEventBridge側の用語で考えて問題ありません。

ミニFAQ：EventBridgeを使うとアプリの改修は必須ですか？

必須ではありません。AWSサービスが自動で出すイベント（EC2の状態変化、S3へのファイル到着など）を拾うだけなら、アプリ側の改修なしでルールを作るだけで動きます。自作アプリのイベントを流したい場合に限り、PutEvents APIの呼び出しを組み込みます。

EventBridgeの3つの機能｜イベントバス・Pipes・スケジューラ

EventBridgeという名前は、実際には3つの機能の総称です。公式ガイドはイベントバスとパイプを「イベントを処理し配信する2つの方法」とし、これにスケジューラが加わる構成を示しています。ここを混同すると設計を誤るため、役割を分けて理解してください。

イベントバス｜多対多のルーティング

複数のソースから来たイベントを、複数のターゲットへ配る仕組みです。1つのイベントを3つのターゲットへ同時に流す、といった扇形の配信（ファンアウト）が得意です。

Classicのバスでは、1つのルールに対してターゲットを最大5つまで紐づけられます。それ以上に配りたいときはルールを分けます。

EventBridge Pipes｜1対1のポイントツーポイント連携

Pipesは、1つのソースから受け取って、1つのターゲットへ届ける専用の仕組みです。バスのような分岐はしません。

代わりにエンリッチメントという段階を挟めます。受け取ったイベントの情報が足りないとき、途中でLambdaやAPIを呼んで情報を足してからターゲットへ渡せる、という流れです。DynamoDB StreamsやKinesis、SQSなど、バスでは直接ソースにできないものを起点にできるのも違いです。

PipesとバスはAWS公式も併用を推奨しています。Pipesでストリームを受けてバスへ流し、そこから複数ターゲットへ配る構成が典型です。

EventBridge スケジューラ｜cron実行の置き換え

決まった時刻や間隔で処理を起動する、サーバーレスのスケジューラです。cron式とrate式に加え、1回限りの実行も設定できます。

EC2上でcronを回している処理をここへ寄せると、サーバの管理が不要になります。無料枠が月1,400万回の呼び出しと大きく、超過分は100万回あたり1.00 USD。実行の揺らぎを許容する時間枠（フレキシブルタイムウィンドウ）や、失敗時の再試行上限も設定できます。

3機能の使い分け早見表

2026年9月に刷新されたカスタムイベントバス｜Classicとの違い

ここは比較的新しい情報のため、他の解説記事ではまだ反映されていないことがあります。初めてEventBridgeを学ぶ段階なら、まず「イベントを受け取り、条件で振り分ける」という基本概念（＝Classicの考え方）を押さえれば十分です。本節は、順序保証や保持が要件になったときに読み返してください。

AWSは2026年9月24日、カスタムイベントバスのリローンチを発表しました。従来のカスタムイベントバスは「カスタムイベントバス - Classic」へ改称され、これまでどおり動作します。既存のAPIに変更はありません。

東京リージョンを含む14リージョンで提供が始まっています。

新バスで追加された機能

Classicのバスには、実務で困る制約がいくつかありました。イベントを保持しない、順序を保証しない、重複排除がない、の3つです。新バスはここに手を入れています。

• 保持：バス自体が1〜365日の範囲でイベントを保持します。Classicでは別途アーカイブを作る必要がありました。

• 順序保証：イベントグループ単位で、サブスクライバーごとにFIFO配信ができます。

• 重複排除：発行時点で、内容ベースまたは指定したキーで重複を除けます。ウィンドウは300秒固定です。

• 開始位置の指定：新しく作ったサブスクライバーが過去のイベントから読み始められます。停止したものを再開しても取りこぼしません。

• クロスアカウント共有：AWS RAMでバスを共有し、各アカウントが自分でサブスクライバーを付けます。バスの所有者が他チームのルーティングを書く必要がなくなります。

• JSON以外のペイロード：PutRawEvents APIでAvro、Protobuf、生バイト列を扱えます。

ルールとターゲットという組み合わせは、新バスではサブスクライバーという1つのリソースに置き換わりました。1サブスクライバーにつきターゲットは1つです。複数へ配りたい場合はサブスクライバーを複数作ります。

新旧比較表

AWS公式のカスタムイベントバス解説ページが示す差分を整理すると、次のようになります。

料金モデルも変わりました。新バスはイベント数ではなく転送データ量での課金が導入されています。規模が大きくなるほど単価が下がる設計です。

どちらを選ぶか

公式ガイドは「新しいアプリケーションの場合はカスタムイベントバスから始める」としています。ただし提供開始から日が浅く、対応リージョンやIaC・SDKの対応状況も動いている時期です。採用を決める前に、自分の要件・利用リージョン・使っている周辺ツール（Terraformプロバイダやフレームワーク）が新バスに対応しているかを確認してください。

そのうえで、実務では次の整理が目安になります。

既存資産の移行を検討する場合、ルールとターゲットがサブスクライバーに置き換わるため、設定の読み替えが必要です。APIもeventsv2系の別系統になります。稼働中のシステムで移行を急ぐ理由は薄いので、新規の部分から試すのが安全です。

ミニFAQ：Classicのバスはいつか廃止されますか？

執筆時点で廃止の告知は出ていません。AWSは「引き続き利用可能」とし、既存APIも変更なしと明記しています。ただし新機能が新バス側に寄っていく可能性はあるため、新規設計では新バスを検討する価値があります。

EventBridgeの使い方｜最小構成の考え方

最初に動かすなら、AWSサービスのイベントをLambdaへ流す構成が手数も少なく確実です。

Classicバスでの基本手順

1. どのイベントを拾うかを決める（例：EC2インスタンスの状態がstoppedになったとき）

2. EventBridgeコンソールでルールを作成し、イベントパターンを設定する

3. ターゲットにLambda関数を指定する

4. テスト用にイベントを発生させ、CloudWatch Logsで関数の起動を確認する

5. 失敗時の受け皿としてデッドレターキュー（SQS）を設定する

5番目を飛ばしがちですが、ここは最初から入れてください。配信に失敗したイベントはただちに消えるわけではなく、まず再試行されます。それでも成功せず再試行の上限（Classicでは最大24時間）に達したとき、デッドレターキューが未設定であれば破棄されます。

イベントパターンの設計で気をつけること

イベントパターンは、イベントのJSONと同じ階層構造で条件を書きます。拾いたいフィールドだけを書けばよく、書かなかったフィールドは何でも一致します。

Classicのイベントパターンは最大2,048文字です。条件が膨らんだらルールを分割します。

新バスでのサブスクライバー作成

新バスでは、ルールとターゲットを作る代わりにCreateSubscriber APIでサブスクライバーを1つ作ります。フィルタ条件、変換、配達先を1つのリソースにまとめて書く形です。

変換にはJSONataが使えます。式の長さは8,192文字まで。フィルタは1つのサブスクライバーにつき最大3つ、合計4,096バイトという制限があります。

なお、サブスクライバーのフィルタ変更には24時間あたり24回という回数制限があります。設定を試行錯誤しながら詰めるときに引っかかるポイントです。

料金の仕組みと試算｜64KB課金の落とし穴

EventBridgeの料金は従量課金で、初期費用や最低利用料はありません。ただし「何が課金対象か」を取り違えると見積もりが外れます。

課金対象と無料になるもの

課金体系は機能ごとに別建てです。下表は2026年11月時点の公式料金ページで確認した値で、イベント数ベースの行はClassicのバス（および全体共通の機能）に適用されるものです。新カスタムバスは後述のとおり転送データ量ベースの別体系になります。

同一アカウント内の配信が無料という点は重要です。1つのイベントを5つのターゲットへ配っても、取り込み1件ぶんの課金で済みます。ファンアウトのコストを過大に見積もる必要はありません。

最新の正確な料率はAmazon EventBridgeの料金ページで確認してください。リージョンや時期で改定される可能性があります。

64KB刻みで課金される

見落としやすいのがここです。公式料金ページは「ペイロードの64KBごとのチャンクが1イベントとして課金される」と明記しています。

つまり1件のイベントが常に1件ぶんの課金とは限りません。

イベントの中に大きなJSONを詰め込む設計にすると、件数は変わらないのに請求が数倍になります。

対策はクレームチェックパターンです。本体のデータはS3に置き、イベントにはその場所を指す情報だけを載せます。受け取った側がS3から取りに行く形にすれば、イベントは小さく保てます。S3の基本はAWS S3とは｜オブジェクトストレージの仕組み・料金・案件単価をフリーランスエンジニア視点で解説で整理しています。

そもそもイベントの最大サイズは256KBです。メタデータも含めた合計なので、大きなデータを載せる設計は上限にも当たります。

月間コストの試算例

Classicのバスを使い、自作アプリから月1,000万件のカスタムイベントを流し、各イベントは10KB、同一アカウント内の3つのLambdaへ配信する想定で計算します。

• 取り込み：1,000万件 ÷ 100万 × 1.00 USD ＝ 10.00 USD

• 配信：同一アカウント内のため 0 USD

• 合計：約10.00 USD/月

イベントサイズが80KBだった場合、64KBを超えるため2チャンク換算になり、取り込みは約20.00 USDへ倍増します。サイズ設計がそのままコストに効く構造です。

なお新カスタムバスは転送データ量での課金になるため、この計算式はそのまま当てはまりません。新バスで見積もる場合は公式料金ページで別途確認してください。

ミニFAQ：開発環境で流しっぱなしにすると高額になりますか？

ルールが一致しないイベントも取り込み料金の対象です。ただし単価が100万件あたり1.00 USDのため、テスト規模で問題になることは稀です。注意すべきはむしろスケジューラの短間隔設定で、1分間隔なら月約4.3万回と無料枠の内側に収まります。

SQS・SNS・Step Functions・Kafkaとの使い分け

「EventBridgeとSNSは何が違うのか」は設計レビューで必ず出る論点です。

比較表

SNSとの違いを一言でいえば、フィルタの賢さと連携先の広さです。SNSにもメッセージフィルタリングはありますが、EventBridgeのイベントパターンのほうが表現力が高く、AWSサービスが自動で出すイベントを直接拾える点が決定的に違います。

一方でスループット重視の単純なファンアウトなら、SNSのほうがレイテンシ面で有利なケースがあります。

迷ったときの判断の順番

1. 時刻起動したいだけか → スケジューラ

2. 処理の順序・分岐・リトライを制御したいか → Step Functions（詳細はAWS Step Functionsとは｜使い方・料金とLambdaとの違い）

3. 受け手の処理速度が追いつかず溜めたいか → SQS

4. 中身の条件で振り分けて複数先に配りたいか → EventBridge

5. 秒間数十万件規模を保持して何度も再処理したいか → Kafka（Apache Kafkaとは｜分散イベントストリーミング基盤の仕組み・用途・案件単価を解説）

実務では併用が普通です。EventBridgeで受けてSQSに溜め、Lambdaが処理し、複雑な部分はStep Functionsへ渡す。こうした組み合わせが一般的な構成になります。Lambdaそのものの挙動はAWS Lambdaとは？特徴・できること・料金・フリーランス案件の単価をエンジニア視点で解説を参照してください。

実務で詰まりやすいポイントとクォータ

東京リージョンのクォータ

数値はリージョンで大きく変わります。次の表はClassicのバスを対象に、東京リージョン（ap-northeast-1）の値を2026年11月時点の公式クォータページで確認したものです。新カスタムバスは別枠のクォータ（1アカウント5バス、1バスあたりサブスクライバー1万、毎秒50万イベントなど）が適用されます。

クォータは引き上げ申請や仕様改定で変わります。設計の根拠に使う場合は、必ず公式ページで最新値を確認してください。

バージニア北部やオレゴンはPutEventsが毎秒10,000と8倍以上あります。検証を米国リージョンで行い、本番を東京に置くと性能特性が変わるため、負荷試験は本番と同じリージョンで実施してください。詳細はEventBridgeのクォータ一覧で確認できます。

配信保証は「最低1回」

EventBridgeの配信保証はat-least-once、つまり最低1回です。同じイベントが2回届く可能性があります。

配信に失敗した場合は指数バックオフで再試行され、Classicでは最大24時間・最大185回まで試みます。24時間を過ぎると配信を諦め、CloudWatchにFailedInvocationsメトリクスが出ます。

ここから導かれる実装上の要件は1つです。ターゲット側の処理を冪等にすること。同じイベントを2回処理しても結果が変わらないよう、イベントIDを記録して重複を弾く設計にします。記録先にはDynamoDBがよく使われます（DynamoDBとは｜AWSのNoSQL DBの特徴・RDSとの違い・案件単価）。

新バスでは発行時の重複排除が使えますが、ウィンドウは300秒です。これを超えた重複は防げないため、冪等性の設計自体は依然として必要になります。

デバッグがしづらい

イベント駆動の構成は、処理が複数サービスにまたがるため追跡が難しくなります。「イベントが届かない」ときの切り分け手順を決めておくと時間を節約できます。

1. ルールのメトリクス（TriggeredRules）で、そもそもパターンに一致したかを見る

2. 一致していなければイベントパターンの記述を疑う

3. 一致しているのに動かないなら、ターゲットのIAM権限を疑う

4. FailedInvocationsが出ていればターゲット側のエラー

5. デッドレターキューに溜まっていれば中身のイベントを確認する

一致しない原因の大半は、イベントのJSON構造とパターンの階層のずれです。実際のイベントをCloudWatch Logsへ一度流して、構造を目で見てからパターンを書くと早く解決します。

コンテナやストレージとの連携

ターゲットにはECSタスクも指定できます。スケジューラと組み合わせて定期バッチをFargateで動かす構成は定番です（AWS ECS・Fargateとは｜仕組み・EKSとの違い・案件単価を解説）。

フリーランス案件でEventBridgeはどう問われるか

EventBridge単体を指名する案件は多くありません。実際には「サーバーレス構成の設計・実装」「AWSでのシステム連携」といった括りの中で、要素技術の1つとして登場します。

求められやすい周辺スキル

• Lambdaの実装経験（EventBridgeのターゲットとして最頻出）

• IAMのロールとポリシー設計（権限不足が最大のつまずき所）

• IaC（CloudFormation、Terraform、AWS CDKのいずれか）での構成管理

• CloudWatchでの監視・アラート設計

• イベント駆動設計の勘所（冪等性、デッドレターキュー、リトライ設計）

コンソールでルールを作れることより、IaCで再現可能な形に落とせることが評価されやすい領域です。運用フェーズの案件では、既存の大量のルールを棚卸しして整理する作業も発生します。

資格で体系的に押さえるなら、AWS認定資格一覧【2026年最新】全12種の難易度・受験料とおすすめ取得順で取得順を確認できます。

案件の探し方と単価の目安

EventBridgeはスキルタグとして単独で立っていないことが多いため、AWSの環境タグで絞り込み、案件詳細の技術要件で「サーバーレス」「Lambda」「イベント駆動」といった語を併用して探すのが実務的です。フリコンのAWS案件一覧から絞り込めます。

単価は経験年数・担当範囲（実装のみか設計から入るか）・稼働日数で幅が大きく、一律の目安を出しにくい領域です。自分の経歴でどの程度の水準を狙えるかは、無料のフリーランスエンジニア単価診断で市場単価の目安を確認するのが早道です。単価を体系的に上げる考え方は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？に整理があります。

複数の案件で迷ったときの優先順位のつけ方は、案件の選び方｜フリーランスエンジニアが単価・稼働・スキルで決める優先順位が判断材料になります。

よくある失敗と導入前チェックリスト

デッドレターキューを設定していない

最も多い失敗です。ターゲットの呼び出しに失敗したイベントは再試行されますが、Classicでは最大24時間・最大185回で打ち切られます。その時点でデッドレターキューが未設定だと破棄され、後から追跡もできません。ルールを作る時点でSQSのデッドレターキューを紐づけてください。

冪等性を考えずに実装している

at-least-once配信である以上、二重実行は起こり得ます。決済や在庫の更新で重複処理が走ると実害が出ます。イベントIDによる重複チェックを最初から入れてください。

イベントにデータを詰め込みすぎる

64KBを超えると課金が増え、256KBを超えると送信自体が失敗します。イベントは「何が起きたか」と「どこを見ればよいか」を伝えるだけに留め、本体はS3やDBに置く設計にします。

パターンが粗く、関数側で捨てている

ターゲットが起動した時点で処理コストが発生します。絞り込みはEventBridge側で済ませるのが原則です。

導入前チェックリスト

• [ ] 拾いたいイベントの実際のJSON構造を確認したか

• [ ] イベントパターンで必要十分に絞り込めているか

• [ ] ターゲットのIAMロールに実行権限を付与したか

• [ ] デッドレターキューを設定したか

• [ ] ターゲット側の処理は冪等か

• [ ] イベントサイズは64KB以内に収まっているか

• [ ] CloudWatchでFailedInvocationsのアラームを設定したか

• [ ] IaCで構成を管理しているか

• [ ] 新規構築なら、新カスタムバスとClassicのどちらを使うか判断したか

• [ ] 本番と同じリージョンでスループット上限を確認したか

まとめ

EventBridgeは、AWS上でサービス同士をつなぐときの標準的な選択肢です。条件に合うイベントだけを複数のターゲットへ配る、という一点に特化しています。

• 機能はイベントバス・Pipes・スケジューラの3つ。役割が違うため混同しないこと

• 2026年9月24日に新カスタムバスが登場し、従来のものはClassicへ改称された

• 新バスでは順序保証・最大365日の保持・重複排除・RAM共有が使える

• 既存のClassicは引き続き動作するため、稼働中システムの移行を急ぐ必要はない

• Classicの料金はイベント数の従量課金で、AWS管理イベントの取り込みと同一アカウント内の配信は無料。新バスは転送データ量ベースの別体系

• Classicでは64KBを超えるイベントが複数件として課金される。大きなデータはS3へ逃がす

• 配信保証はat-least-once。冪等な実装とデッドレターキューは必須

• 東京リージョンのPutEvents上限は毎秒1,200（Classic・2026年11月時点）。負荷試験は本番リージョンで行う

次の一歩としては、AWSサービスのイベントをLambdaへ流す最小構成を1つ作ってみることをおすすめします。イベントの実際のJSON構造を目で見ると、パターン設計の勘所が一気に掴めます。

設計スタイルとしてのイベント駆動を採用すべきかどうかから検討したい場合は、イベント駆動アーキテクチャとは｜同期APIとの違いと採用判断を先に読んでください。

参照元・一次情報

• Amazon EventBridgeとは（AWS公式ユーザーガイド）

• EventBridge カスタムイベントバスとは（AWS公式）

• Amazon EventBridge がエンタープライズ規模向けにイベントバスを刷新（AWS What's New・2026年9月24日）

• Amazon EventBridge の料金（AWS公式）

• Amazon EventBridge のクォータ（AWS公式）