Amazon EventBridgeとは？仕組み・料金とCLI・Pythonでの実装手順、新Custom Event Busとの違いを解説【2026年版】

Amazon EventBridge（アマゾン イベントブリッジ）は、アプリやAWSサービス、SaaSが出す「イベント」を受け取り、あらかじめ決めたルールに従ってLambdaやSQSなどの届け先へ振り分ける、サーバーレスのイベントバスです。ポイントは、送り手と受け手を直接つながず、間にEventBridgeを挟むことで、システムを疎結合に保てる点にあります。2026年9月24日には、購読者ごとに順序付き配信やリプレイができる新しいCustom Event Busが追加され、従来のバスは「Custom Event Bus – Classic」と表示されるようになりました（AWS公式ブログ）。この記事では、3つの構成要素とイベントパターン、AWS CLIとPythonで実際に動かす手順、新旧2種類のバスの違い、Pipes・Scheduler、料金と上限値、そしてSQS・SNS・Step Functionsといつ使い分けるかの判断までを扱います。料金の細部は既存の解説へ譲り、EventBridgeで何ができ、どう組み、いつ選ぶかに絞ります。

まとめ：EventBridgeはイベントで疎結合をつなぐサーバーレスの連携基盤

先に結論を示します。EventBridgeは、送り手と受け手の間に立ち、イベントをルールで振り分けて配る「ルーター」です。EC2の状態変化やS3へのファイル到着といったAWSサービスのイベント、自作アプリが投げるカスタムイベント、SaaSからのパートナーイベントを受け取り、Lambda・SQS・Step Functionsなど多数のターゲットへ、条件に合うものだけを届けます。サーバーの管理は要らず、受けた分だけ課金される従量制です。

向くのは、1つのイベントを複数のサービスへ同時に配りたい、送り手と受け手を疎結合にして片方の変更が他方に波及しないようにしたい、という多対多の連携です。逆に、1対1で受け渡すだけの連携では、SQSや直接呼び出しのほうが素直に収まります。従来のバス（Classic）は配信順を保証しないため、順序が要る処理はSQS FIFOやKinesisに寄せるのが定石でした。新しいCustom Event Busはイベントグループ単位のFIFO配信に対応したので、順序要件だけを理由にEventBridgeを外す場面は減っています。まずEventBridgeで配れるかを起点に考え、単純さが勝つなら別方式へ寄せる、という順序が現実的でしょう。

実装に入る前の最短ルートは、カスタムバスを1本作り、イベントパターンを test-event-pattern で事前に確かめ、SQSをターゲットにしてDLQとリトライを付ける、という流れです。本文の手順章で、そのままコピーして動かせるコマンドとPythonコードを載せています。

EventBridgeの基本｜イベント駆動とCloudWatch Eventsとの関係

EventBridgeを理解する近道は、「イベントを中心に組む」という発想と、その中を流れる部品の役割をつかむことです。発想そのもの、つまりイベント駆動アーキテクチャの全体像や実装パターンはイベント駆動アーキテクチャの仕組みと採用判断の解説で整理しているので、ここではEventBridgeの部品に絞って全体像から入ります。

イベントバス・ルール・ターゲットというEventBridgeの3つの構成要素

EventBridgeの中心は、イベントバス・ルール・ターゲットの3つです。イベントバスは、イベントを受け取る入口となるルーターを指します。ルールは、流れてきたイベントのうち「どれを」「どこへ」送るかを決める設定で、後述するイベントパターンで対象を絞り込む役割です。ターゲットは、ルールに合致したイベントの届け先で、Lambda関数やSQSキュー、Step Functionsのステートマシンなどを指定します。送り手はイベントをバスへ投げるだけ、受け手はルール経由で必要なイベントだけを受け取る、という分業がEventBridgeの基本形です。1つのイベントを複数のルールで受け、それぞれ別のターゲットへ配ることもできます。

公式ドキュメントは、EventBridgeの処理経路を「イベントバス」と「パイプ」の2つに分け、別枠でスケジューラーを提供すると説明しています（What Is Amazon EventBridge?）。バスは多対多のルーター、パイプは1対1の配管、スケジューラーは時刻起点の呼び出し、と3つの入口を持つサービスとして捉えると、後の章が読みやすくなります。

CloudWatch Eventsから拡張された経緯と現在の位置づけ

EventBridgeは、もともとCloudWatch Eventsとして提供されていた機能を土台に、外部SaaSやカスタムアプリのイベントも扱えるよう拡張されたサービスです。そのため、CloudWatch Eventsで作ったルールやAPIは現在もEventBridge側でそのまま動きます。既存のCloudWatch Eventsの設定を引き継ぎつつ、新しくSaaS連携やカスタムバスを足していける、という互換性の高さが実務では効きます。ドキュメントやコンソールの表記もEventBridgeへ寄せられているため、新規に組むならEventBridgeの名前で設計するのが素直です。CLIのサービス名が今も aws events なのは、この経緯の名残にあたります。旧名が残るCLI・IAM・Terraformの対応表と、既存ルールを棚卸しする手順はCloudWatch EventsとEventBridgeの違い：同じAPIで動く範囲と移行時の確認手順で整理しています。

2026年9月追加の購読者型Custom Event BusとClassicの違い

2026年9月24日、EventBridgeに新しい種類のカスタムイベントバスが加わりました。公式ドキュメントでは、新しいほうを「Custom Event Bus」、ルールとターゲットで振り分ける従来のバスを「Custom Event Bus – Classic」と呼び分け、新規のアプリケーションは新しいバスから始めるよう案内しています（What Is Amazon EventBridge?）。既存のカスタムバスは変更不要でそのまま動き、表示名がClassicに変わるだけです。提供開始時点のリージョンには東京も含まれています（2026年10月時点）。

新しいバスの考え方は、振り分けの設定を持つ主体が逆になる点にあります。Classicではバスの持ち主がルールを書きますが、新しいバスでは利用側のチームやアカウントが自分で「サブスクライバー」を作り、フィルタ・変換・届け先・リトライ・DLQをその単位で管理します。違いを公式の比較表から抜き出すと次のとおりです（What is the EventBridge Custom Event Bus?）。

使い分けの目安は単純です。1つのバスを組織内の複数アカウントで共有し、各チームが自分の購読を持つ構成や、口座番号ごとの順序を守りたい決済イベントのような処理なら、新しいバスが向きます。1つのアカウント内で、AWSサービスのイベントを数本のルールでLambdaへ流す程度なら、情報量の多いClassicで組んでも困りません。以降の手順章とコードは、資料と実績が厚いClassicを前提にしています。

イベントバスとルーティング｜3種類のバスとパターンによる振り分け

どのイベントを、どのバスで受け、どう絞り込むか。ここがEventBridgeの設計で最初に決める部分です。

デフォルト・カスタム・パートナーという3種類のイベントバスの使い分け

イベントバスには3種類あります。デフォルトバスは、各アカウントに最初から用意されているバスで、EC2やS3などAWSサービスが出す管理イベントはここへ流れ込む既定の入口です。カスタムバスは、自作アプリのイベント（カスタムイベント）を受けるために自分で作るバスで、業務ドメインごとにバスを分けて管理する用途に向きます。前述のとおり、カスタムバスには2026年9月からClassicと新しいCustom Event Busの2系統があります。パートナーバスは、Salesforceなど連携済みのSaaS（パートナー）が出すイベントを受け取る専用のバスです。設計の目安として、自社アプリのイベントはドメイン単位でカスタムバスに集約し、AWSサービス起因のイベントはデフォルトバスで受ける、という分け方が管理しやすくなります。別アカウント・別リージョンのバスへイベントを送るときのリソースポリシーと送信側IAMロールの設定は、EventBridge イベントバスの使い分け：クロスアカウント・リージョン送信のポリシー設定で設定例とあわせて解説しています。

イベントパターンによる内容ベースのフィルタリングとターゲット指定

ルールの核になるのがイベントパターンです。これは、イベントのJSON本文の中身（たとえば「source が aws.s3」「detail.state が terminated」など）を条件にして、合致したイベントだけをターゲットへ流す仕組みを指します。件名やトピック単位ではなく、本文の任意フィールドで絞り込める点が、内容ベースのフィルタリングと呼ばれるゆえんです。1つのルールに複数のターゲットを指定でき、届ける前にイベントの一部を抜き出して形を変える入力変換（Input Transformer）も設定できます。通知文の整形例と引用符の規則はEventBridge 入力トランスフォーマーの使い方で解説しています。PutEvents APIで投げたカスタムイベントも、同じくパターンで振り分けられる対象です。まず「どのフィールドで判定するか」を決めると、ルール設計の見通しが立ちます。

一致条件は完全一致だけではありません。前方一致（prefix）、後方一致（suffix）、否定（anything-but）、数値範囲（numeric）、項目の有無（exists）、IPアドレス範囲（cidr）、複数項目のいずれか（$or）などの演算子が用意されています（Comparison operators for use in event patterns）。たとえば「注文額1万円以上、かつテスト経路以外の注文作成イベント」は次のように書けます。

{
  "source": ["com.example.orders"],
  "detail-type": ["OrderCreated"],
  "detail": {
    "amount": [{ "numeric": [">=", 10000] }],
    "channel": [{ "anything-but": "test" }]
  }
}

注意点が2つあります。数値の比較は倍精度浮動小数点で行われるため、±2の53乗を超える整数IDは数値条件で正確に照合できません。また、ワイルドカードはイベントバスのルールでのみ使え、Pipesのフィルタでは使えない演算子です。IDは文字列として扱い、Pipesへ移す可能性があるパターンではワイルドカードを避けておくと、後の手戻りを防げます。prefix・anything-but・numericなど演算子ごとの書き方と照合規則の落とし穴は、EventBridge イベントパターンの書き方：演算子一覧とtest-event-patternでの検証で詳しく扱っています。

AWS CLIでカスタムバス・ルール・SQSターゲットを作り動かす手順

ここからは、注文作成イベントをカスタムバスへ投げ、条件に合うものだけをSQSキューへ届ける最小構成を、AWS CLI v2とPythonで組みます。東京リージョン（ap-northeast-1）、アカウントIDは例として 111122223333 を使います。実行するIAMユーザーまたはロールには、EventBridgeとSQSの作成権限が必要です。

検証環境の前提とカスタムイベントバス・SQSキューを用意する手順

最初に、イベントを受けるカスタムバスと、届け先のSQSキュー、配信に失敗したイベントを受けるDLQ用のキューを作ります。

aws events create-event-bus --name orders --region ap-northeast-1

aws sqs create-queue --queue-name order-created --region ap-northeast-1
aws sqs create-queue --queue-name order-created-dlq --region ap-northeast-1

EventBridgeがSQSへ書き込むには、キュー側のアクセスポリシーで events.amazonaws.com からの sqs:SendMessage を許可しておく必要があります。送信元をこのルールに限定する条件まで付けた例が次のポリシーです。set-queue-attributes の Policy 属性へ文字列として設定するか、コンソールのアクセスポリシー欄へ貼り付けます。DLQ用のキューにも同じ許可を付けてください。

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "events.amazonaws.com" },
    "Action": "sqs:SendMessage",
    "Resource": "arn:aws:sqs:ap-northeast-1:111122223333:order-created",
    "Condition": {
      "ArnEquals": {
        "aws:SourceArn": "arn:aws:events:ap-northeast-1:111122223333:rule/orders/order-created-large"
      }
    }
  }]
}

イベントパターンを書きtest-event-patternで一致を事前に確かめる

ルールを作る前に、パターンが狙ったイベントに一致するかをローカルのJSONで確かめておくと、配信されない原因の切り分けが楽になります。前章のパターンを pattern.json に保存し、試験用のイベントを event.json として用意します。test-event-pattern に渡すイベントには、id・account・source・time・region・resources・detail-type・detail の各項目が要る点に注意してください（AWS CLI test-event-pattern）。

{
  "id": "1",
  "account": "111122223333",
  "source": "com.example.orders",
  "time": "2026-10-01T00:00:00Z",
  "region": "ap-northeast-1",
  "resources": [],
  "detail-type": "OrderCreated",
  "detail": { "orderId": "A-1001", "amount": 12800, "channel": "web" }
}

aws events test-event-pattern \
  --event-pattern file://pattern.json \
  --event file://event.json

# 一致すれば次の結果が返る
# { "Result": true }

event.json の amount を 9800 に、または channel を test に書き換えて再実行し、"Result": false になることも確かめます。一致する側だけでなく、弾く側のケースを1つずつ試すのが、パターンの書き間違いを早く見つけるコツです。

put-rule・put-targetsでSQSへ配信しDLQとリトライを設定する

パターンが確かめられたら、カスタムバス上にルールを作り、SQSキューをターゲットに登録します。ターゲットには、リトライの回数と保持時間、使い切ったときの退避先（DLQ）を同時に指定します。

aws events put-rule \
  --name order-created-large \
  --event-bus-name orders \
  --event-pattern file://pattern.json

aws events put-targets \
  --rule order-created-large \
  --event-bus-name orders \
  --targets file://targets.json

[
  {
    "Id": "order-queue",
    "Arn": "arn:aws:sqs:ap-northeast-1:111122223333:order-created",
    "RetryPolicy": {
      "MaximumRetryAttempts": 8,
      "MaximumEventAgeInSeconds": 3600
    },
    "DeadLetterConfig": {
      "Arn": "arn:aws:sqs:ap-northeast-1:111122223333:order-created-dlq"
    }
  }
]

リトライ設定を省くと、既定では最長24時間・最大185回まで、指数バックオフとジッターを付けて再送されます。すべての再試行を使い切ったイベントは破棄されるため、取りこぼしを防ぐにはDLQの指定が前提です（How EventBridge retries delivering events）。上の例では、受け手の障害を1時間以内に検知する運用を想定し、保持を3,600秒に縮めています。設定できる項目の全体はAWS CLI put-targetsのリファレンスで確認できます。イベントがターゲットに届かないときの調査手順はEventBridge ログの調べ方：ルールが発火しない原因をメトリクス・バスログ・DLQで特定するで解説しています。

Pythonのboto3：PutEvents送信とFailedEntryCount確認

最後に、アプリ側からイベントを送ります。boto3の put_events で、送信元・種別・本文・送り先のバス名を指定します（boto3 put_events）。

import json
import boto3

client = boto3.client("events", region_name="ap-northeast-1")


def publish_order_created(order: dict) -> str:
    resp = client.put_events(Entries=[{
        "Source": "com.example.orders",
        "DetailType": "OrderCreated",
        "Detail": json.dumps(order, ensure_ascii=False),
        "EventBusName": "orders",
    }])
    # PutEventsは一部のエントリが失敗してもHTTP 200を返すため、件数で判定する
    if resp["FailedEntryCount"] > 0:
        failed = [e for e in resp["Entries"] if "ErrorCode" in e]
        raise RuntimeError(f"PutEvents failed: {failed}")
    return resp["Entries"][0]["EventId"]


if __name__ == "__main__":
    print(publish_order_created({"orderId": "A-1001", "amount": 12800, "channel": "web"}))

実行後、aws sqs receive-message でorder-createdキューを読めば、EventBridgeの封筒（version・id・source・detail-type・detail など）に包まれたイベントが届いているはずです。ここで見落としやすいのが失敗の判定です。PutEventsはリクエスト全体が成功しても、個々のエントリが失敗することがあり、そのときもHTTP 200が返ります。レスポンスの FailedEntryCount と各エントリの ErrorCode を見て再送するのが正しい扱い方です。1回のリクエストに入れられるのは最大10件で、エントリの合計サイズは1MB未満という制約もあります（PutEvents APIリファレンス・2026年10月時点のClassic）。

ターゲットとPipes・Scheduler｜配信先と1対1統合・定期実行の役割

イベントの届け先と、バスとは別系統の2つの機能（PipesとScheduler）を押さえると、EventBridgeで組める範囲が見えてきます。

Lambda・SQS・Step Functionsなど主要ターゲットと配信の考え方

ターゲットとして指定できるサービスは幅広く、Lambda関数、SQSキュー、SNSトピック、Step Functionsのステートマシン、Kinesis Data Streams、ECSタスク、さらにHTTPエンドポイントを叩くAPI Destinationsなどが選べます。イベント処理を関数で行うならLambda、受けたイベントを一旦ためて非同期にさばくならSQS、複数ステップの処理を組むならStep Functions、という当て方が基本です。SQSやLambdaと組み合わせた非同期処理の具体的な組み方はSQS・Lambda・EventBridgeを用いた非同期処理の解説で実装例を追えます。配信に失敗したイベントを取りこぼさないよう、ターゲットごとにデッドレターキュー（DLQ）とリトライを設定しておくのが実務の定石で、その具体的な書き方は前章の targets.json のとおりです。

ルールあたり5ターゲット・東京のPutEvents毎秒1,200件という上限値

設計段階で効いてくる上限値も押さえておきます。Classicのバスでは、1つのルールに付けられるターゲットは5つまでで、この値は引き上げられません。1つのイベントを6か所以上へ配りたいなら、ルールを分けるか、SNSトピックを1つのターゲットにして先で広げる構成にします。ルール数はバスあたり既定300本、イベントパターンの大きさは既定2,048文字です。流量の上限は東京リージョンの場合、PutEventsが既定で毎秒1,200リクエスト、ルールに一致してターゲットを呼ぶ回数が毎秒2,250回で、どちらも申請で引き上げられます（Amazon EventBridge quotas・2026年10月時点）。呼び出しの上限に達しても配信は失われず遅延する扱いですが、大量のイベントを一度に流すバッチ移行では、事前に見積もって申請しておくのが安全です。

EventBridge Pipesが担う単一ソースから単一ターゲットの1対1統合

Pipesは、イベントバスとは別に用意された1対1統合の仕組みです。1本のパイプが、単一のソースからイベントを受け、途中でフィルタやエンリッチ（外部データの付加）を挟み、単一のターゲットへ届けます。ソースにはDynamoDB Streams、Kinesis、SQS、Amazon MQといったストリーム/キュー系を指定でき、これまでLambdaで橋渡しを自作していた「ストリームを読んで別サービスへ流す」処理を、コードなしで組めます。バスが多対多のルーターなのに対し、Pipesは点と点をつなぐ配管、と役割で覚えると混同しません。パイプのターゲットにイベントバスを指定して、両者を組み合わせる構成もよく使われます。パイプをAWS CLIで組む手順と、フィルタ・エンリッチの書き方はEventBridge Pipesの使い方：DynamoDB Streamsのフィルタとエンリッチ実装で解説しています。公式ドキュメントも、DynamoDBのストリームをパイプで受けてイベントバスへ流し、バスのルールで複数の届け先へ広げる例を代表的な使い方として挙げています（Amazon EventBridge Pipes）。

EventBridge Schedulerによる定期実行と1回限りのタスク管理

Schedulerは、時刻や間隔をきっかけにターゲットを呼び出す、スケジューリング専用の機能です。cron式やrate式で「毎日9時」「5分ごと」といった繰り返しを定義でき、特定日時の1回限り実行も設定できます。指定時刻の前後で実行を許容する柔軟な時間枠、リトライ上限、失敗時の最大保持時間なども個別に決められる点も特徴です（What is Amazon EventBridge Scheduler?）。従来はルールのスケジュール機能で定期実行を組んでいましたが、大量のスケジュールを一元管理するならSchedulerが向きます。設定項目や制限の詳細はAmazon EventBridge Schedulerの解説で確認できます。

料金とスキーマ｜従量課金の課金要素とスキーマレジストリの役割

EventBridgeは受けたイベントの量で課金される従量制です。何にいくらかかるかの骨格と、イベント構造を扱う補助機能を整理します。

カスタムイベント100万件1ドルと64KB課金・AWSイベント無料の体系

課金の中心はイベントの取り込み量です。Classicのバスでは、自作アプリが投げるカスタムイベントは、取り込み100万件あたり1.00ドルで、同一アカウント内のターゲットへの配信は追加料金がかかりません。一方、EC2やS3などAWSサービスがデフォルトバスへ出す管理イベントの取り込みは無料です。課金の単位には注意が必要で、料金は「ペイロード64KBごとに1イベント」として数えられるため、大きなイベントは複数件分として計上されます。別アカウントへの配信やパートナーイベント、API Destinations（100万件0.20ドル）、Pipes（フィルタ後100万リクエスト0.40ドル）、Scheduler（月1,400万呼び出しまで無料、超過分は100万件1.00ドル）など要素ごとに単価が分かれる仕組みです（Amazon EventBridge 料金・2026年10月時点・米国東部の表示）。無料になる条件や64KB課金でつまずきやすい点はAmazon EventBridgeの料金の解説に詳しく、コスト試算はそちらを土台にすると精度が上がります。

2026年9月に追加された新しいCustom Event Busは、件数ではなくデータ量で数える別の料金体系です。取り込みは月5,000GBまで1GBあたり0.18ドル、それを超えると0.12ドル、サブスクライバーへの配信は1GBあたり0.05ドルで、これに保持期間分のストレージ料金が加わります。発行側が取り込み分を、購読側が配信分を払う形なので、組織内でバスを共有するときは費用の持ち方も自然に分かれます。小さなイベントを大量に流す用途と、大きめのイベントを少量流す用途では、どちらのバスが安いかが逆転しうるため、実際のイベントサイズで両方を試算してから選ぶのが確実です。

スキーマレジストリと検出によるイベント構造の自動把握とコード生成

スキーマレジストリは、イベントのJSON構造（どんなフィールドがどの型で入るか）を登録・管理する機能です。スキーマ検出（Schema Discovery）を有効にすると、バスを流れるイベントから構造を自動で拾い上げてレジストリへ登録してくれます。登録済みのスキーマからは、JavaやPythonなどのコードバインディングを生成でき、イベントを型付きオブジェクトとして扱えるため、フィールド名のタイプミスを実装段階で減らせます。検出は月500万件の取り込みまで無料で、超過分は100万件1.00ドル（8KB単位・2026年10月時点）です。多数のカスタムイベントを扱い、開発者間でイベント仕様を共有したいチームで効いてきます。新しいCustom Event Busでは、AvroやProtobufで発行したイベントもスキーマレジストリでデシリアライズしてフィルタに掛けられます。

EventBridgeとSQS・SNS・Step Functionsの違いと使い分けの基準

似た用途のサービスと並べると、EventBridgeの持ち場がはっきりします。役割の差で切り分けます。

SQS・SNSとの違い｜キュー/通知とイベントルーターの役割差

SQSはメッセージを一時的にためて1つの受け手が順に取り出すキュー、SNSは1つのメッセージを購読者へ一斉配信するトピック（プッシュ通知）です。これに対しEventBridgeは、イベントの中身を見て条件に合う届け先だけへ振り分けるルーターという違いがあります。内容ベースのフィルタリングや、AWSサービス/SaaSからのイベント取り込み、入力変換が要るならEventBridgeが向きます。単純に処理をためてワーカーへ渡すだけならSQS、同報通知だけならSNSで足りるはずです。実際には、EventBridgeで振り分けた先にSQSを置いてバッファリングする、といった併用も定番です。SQSの標準キューとFIFOの違いや可視性タイムアウトの設計はAmazon SQSの解説、SNSのメッセージフィルタリングやFIFOトピックはAmazon SNSの解説で、それぞれの側から比較できます。EventBridgeとSNSを組み合わせるときに間へSNSを挟むかの判断と連携の手順はEventBridge SNSの連携手順にまとめています。

Step Functionsとの違い｜ワークフロー制御とイベント配信の分担

Step Functionsは、複数ステップの処理順序・分岐・リトライを1つのステートマシンとして制御するワークフローエンジンです。EventBridgeはあくまでイベントを配るところまでを担い、配った先の多段処理はStep Functionsに任せる、という分担になります。たとえば「注文イベントを受けたら、在庫確認→決済→通知の順に処理する」なら、EventBridgeがイベントを受けてStep Functionsを起動し、Step Functionsが各ステップを制御する構成です。イベントの受配信はEventBridge、処理フローの管理はStep Functions、と層を分けて設計すると役割が混ざりません。Standard／Expressの2種類のワークフローや料金の違いはAWS Step Functionsの解説で扱っています。Azure側でイベントを起点にワークフローまで一続きで組む統合サービスとしては、Azure Logic Appsが対応します。

Google CloudのEventarc・AzureのEvent Gridとの対応関係

マルチクラウドで設計するときは、他社の同種サービスとの対応も把握しておくことで、移植の見積もりを立てやすくするのが狙いです。Google Cloudでイベントを振り分ける役割を担うのがEventarcで、Standard／Advancedの違いやEventBridgeとの差はEventarcの解説にまとめています。AzureではAzure Event Gridが近い位置にあり、名前空間とカスタムトピック、再試行と順序の設計が論点になります。どのクラウドでも「イベントの形式をCloudEventsなど共通の型に寄せておくか」で移植の手間が変わるため、イベントのスキーマは早めに決めておくと後が楽です。

EventBridgeを採用すべき条件と見送って別方式に寄せる場面

ここは言い切ります。EventBridgeはすべての連携で正解になるわけではありません。向く条件と、あえて選ばない場面を分けて示します。

EventBridgeの採用が向く条件｜多対多のイベント配信と疎結合な連携

効果が出るのは、1つのイベントを複数のサービスへ同時に配りたい、送り手と受け手を切り離して片方の変更が他方に波及しないようにしたい、という多対多かつ疎結合な連携です。マイクロサービス間のイベント連携、AWSサービスの状態変化をトリガーにした自動処理、SaaSのイベントを起点にした業務連携などが典型で、サーバーを持たずに配信の土台を作れます。組織内の複数アカウントで1本のバスを共有し、各チームが自分の購読を持ちたい場合は、新しいCustom Event Busを選ぶ理由になる条件です。イベント駆動でAWS上のシステムを設計・実装したい、既存のバッチ連携をイベント起点へ組み替えたい、といった相談はAWSを含むインフラ構築の受託で受け付けています。設計から運用までを外部に任せたい場合の入口です。

見送るべき場面｜厳密な順序保証や単純な1対1の受け渡しのケース

逆に見送ったほうがよい場面もあります。Classicのバスは配信順を保証しないため、イベントの到着順を厳密に守りたい処理では、FIFOキュー（SQS FIFO）やAmazon Kinesisのように順序性を持つ仕組みを選ぶ判断です。新しいCustom Event Busならイベントグループ内のFIFO配信で対応できますが、2026年10月時点では提供リージョンが限られ、1サブスクライバーに届け先1つという制約もあるため、要件と照らして選びます。また、送り手と受け手が固定の1対1で、フィルタリングも同報も要らない単純な受け渡しなら、SQSへ直接入れるかサービスを直接呼び出すほうが構成がシンプルで済みます。ミリ秒単位の低遅延が要求されるリアルタイム処理も、配信のわずかな遅延が問題になりうるため設計を要確認です。判断の順序としては、まず多対多・疎結合・内容フィルタが要るかを確かめ、当てはまらなければ別方式へ寄せる、という進め方が堅実です。

よくある質問

EventBridgeの料金や他サービスとの違いなど、導入前に迷いやすい点をまとめます。

Amazon EventBridgeとCloudWatch Eventsは何が違いますか？

EventBridgeはCloudWatch Eventsを拡張したサービスで、AWSサービスのイベントに加えて、自作アプリのカスタムイベントやSaaSのパートナーイベントも扱えるようになったものです。CloudWatch Eventsで作ったルールやAPIはEventBridgeでもそのまま動くため、新規に組むならEventBridgeの名前で設計すれば問題ありません。CLIのコマンド名が aws events のままなのは、この経緯によるものです。

EventBridgeの料金はどのくらいかかりますか？

Classicのバスでは、自作アプリのカスタムイベントは取り込み100万件あたり1.00ドル、AWSサービスがデフォルトバスへ出す管理イベントの取り込みは無料です（2026年10月時点）。料金はペイロード64KBごとに1イベントとして数えられます。2026年9月に追加された新しいCustom Event BusはGB単位の取り込み・配信・保持で課金される別体系です。無料になる条件や64KB課金の細部は料金専用の解説で確認するのが確実です。

EventBridgeとSQSはどう使い分けますか？

イベントの中身を見て複数の届け先へ振り分けたい、AWSサービスやSaaSのイベントを取り込みたいならEventBridgeが向きます。単純にメッセージをためて1つのワーカーが順に処理するだけならSQSで対応可能です。EventBridgeで振り分けた先にSQSを置いてバッファリングする併用も定番で、本文の手順章はその最小構成をCLIで組んでいます。

EventBridge PipesとEventBridgeのバスは何が違いますか？

バスは多数のソースから多数のターゲットへイベントを振り分けるルーターで、Pipesは単一ソースから単一ターゲットへつなぐ1対1統合です。DynamoDB StreamsやSQSを読んで別サービスへ流す配管をコードなしで組めるのがPipesで、途中でフィルタやエンリッチを挟めます。両者を組み合わせる構成もよく使われます。なお、イベントパターンのワイルドカードはバスのルール専用で、Pipesのフィルタでは使えません。

定期実行のスケジュールはEventBridgeで組めますか？

組めます。EventBridge Schedulerを使えば、cron式やrate式で繰り返し実行を、あるいは特定日時の1回限り実行を設定できる仕組みです。柔軟な時間枠やリトライ、失敗時の保持時間も指定できます。月1,400万呼び出しまでは無料枠に収まり（2026年10月時点）、大量のスケジュールを一元管理する用途に向いています。設定の詳細を確認する際の参照先は、Scheduler専用の解説です。

関連記事

• Amazon EventBridgeの料金｜無料条件と64KB課金：カスタムイベント課金や無料になる条件など、コスト試算の細部を実装視点で解説しています。
• Amazon EventBridge Schedulerの概要と基本機能：cron/rate式の定期実行や柔軟な時間枠など、Schedulerの設定項目を詳しく追えます。
• SQS・Lambda・EventBridgeによる非同期処理：EventBridgeを起点にSQSとLambdaを組み合わせた非同期処理の実装と運用がわかります。
• イベント駆動アーキテクチャとは？仕組み・実装パターンと採用判断：EventBridgeを使う前提となる設計思想と実装パターンを整理しています。
• Amazon SQSとは？標準キューとFIFOの違い・DLQ設計：EventBridgeの届け先として置くキューの設計を深掘りできます。
• Eventarcとは？Google Cloudのイベントルーティング：EventBridgeとの違いを、Google Cloud側の仕組みから比較しています。
• GuardDuty EventBridge連携の実装：検出結果とCloudTrailの操作をSNS・Slackへ通知する：EventBridgeでセキュリティの検出結果とAPI呼び出しを通知する実装例です。