AWS EventBridge入門｜イベント駆動アーキテクチャの基礎からルール設計・スケジューラーまで現場で使える実践ガイド

オンプレの世界では「ポーリング」が当たり前でした。バッチ処理が終わるたびに「あのジョブが完了したか確認してから次を動かす」というシェルスクリプトを書き続けてきたエンジニアは多いはずです。

クラウドへ移行すると、こうした設計思想そのものを見直す機会が訪れます。イベント駆動アーキテクチャ（EDA: Event-Driven Architecture）はその中核をなす考え方で、Amazon EventBridgeはAWSでEDAを実装する代表的なサービスです。

この記事では、Amazon EventBridgeの基本構造・設定手順から料金の仕組み・実務での活用パターンまでを、オンプレ経験者にもわかりやすく解説します。マイクロサービス設計や運用自動化を検討しているインフラエンジニアの方は、ぜひ参考にしてください。

なぜイベント駆動アーキテクチャなのか？（オンプレとの違い）

オンプレでよくある「密結合」の問題

オンプレ環境では、複数のサービスやバッチが連携するとき、こんな構成がよく見られます。

・サービスAが完了したら、シェルスクリプトがサービスBを起動する
・cronが一定間隔でDBをポーリングし、新しいレコードがあれば処理を実行する
・APIサーバーがキューに直接アクセスして処理状況を管理する

この設計の問題点は「密結合」です。サービスAがサービスBを「知っている」必要があり、どちらかが変わればもう一方も修正が必要になります。スケールも難しく、障害時の連鎖も起きやすい。

イベント駆動型で何が変わるか

イベント駆動アーキテクチャの考え方はシンプルです。「何かが起きたらイベントを発行する。誰が受け取るかは発行側が知らなくていい」というモデルです。

Amazon EventBridgeは、このイベント駆動の考え方をAWSサービス全体で実現するためのサーバーレス型イベントバスサービスです。

Amazon EventBridgeの基本構造を理解する

EventBridgeを理解するための中心概念は3つです。イベントバス・ルール・ターゲット。この3つを押さえれば、EventBridgeの動作を直感的に理解できます。

イベントバス（Event Bus）とは

イベントバスは、イベントが集まる「中継地点」です。オンプレでいえばメッセージブローカー（ActiveMQや社内のキューサーバー）に近いイメージです。

EventBridgeには3種類のイベントバスがあります。

・デフォルトイベントバス: AWSのサービス（EC2、S3、RDSなど）が自動的にイベントを送信するバス。追加設定不要で使えます
・カスタムイベントバス: 自社アプリやマイクロサービスが独自のイベントを送信するバス
・パートナーイベントバス: SalesforceやZendeskなどのSaaSサービスからイベントを受信するバス

ルール（Rule）とターゲット（Target）

ルールは「このイベントが来たらこのターゲットに転送する」という設定です。フィルタリング条件（イベントパターン）と転送先（ターゲット）を組み合わせます。

ターゲットとして指定できる代表的なAWSサービスは次の通りです。

・AWS Lambda: イベントを受け取って任意の処理を実行
・Amazon SQS: イベントをキューに積んで非同期処理
・Amazon SNS: 複数の購読者にイベントを通知
・AWS Step Functions: ステートマシン（ワークフロー）を起動
・Amazon ECS / AWS Fargate: コンテナタスクを起動
・Amazon API Gateway: APIエンドポイントを呼び出す

1つのルールに対して最大5つのターゲットを設定できます。

イベントパターンとスケジューラー

ルールの起動条件には2種類あります。

イベントパターン方式: 受信したイベントのJSONを条件式でフィルタリングします。「EC2インスタンスの状態が stopped になったとき」「S3バケットへのPutObjectイベントのみ」といった条件を指定できます。

スケジューラー方式: cron式またはrate式で定期実行します。オンプレのcronジョブの代替として、AWS Lambdaや各種バッチ処理を定期起動するケースで広く使われます。2022年以降はAmazon EventBridge Schedulerという専用サービスが分離し、より高機能なスケジューリングが可能になっています。

EventBridgeの設定手順（AWSコンソール操作）

実際にカスタムイベントバスを作成し、AWS Lambdaをターゲットに設定するまでの流れを説明します。

1. カスタムイベントバスを作成する

AWSマネジメントコンソールにログインし、検索バーで「EventBridge」を検索して開きます。左メニューから「イベントバス」を選択し、「イベントバスを作成」をクリックします。

名前を入力します（例: my-app-event-bus）。暗号化はデフォルトのAWS管理キーで問題ありません。

# AWS CLIでカスタムイベントバスを作成する場合
aws events create-event-bus --name my-app-event-bus

# 作成結果の確認
aws events describe-event-bus --name my-app-event-bus

2. ルールを定義してターゲットを設定する

左メニューの「ルール」を選択し、「ルールを作成」をクリックします。

・名前: order-completed-rule（用途がわかる名前を付ける）
・イベントバス: 先ほど作成した my-app-event-bus を選択
・ルールタイプ: 「イベントパターンを持つルール」を選択

イベントパターンには、カスタムパターンとして以下のようなJSONを記述します。

{
  "source": ["my-app.orders"],
  "detail-type": ["OrderCompleted"]
}

次のページでターゲットを設定します。「ターゲットを追加」でAWS Lambdaを選択し、対象の関数を指定してください。IAMロールはコンソールから新規作成するか、既存のものを指定します。

3. イベントを送信してテストする

ルール作成後、実際にイベントを送信して動作を確認します。AWS CLIで直接送信できます。

# AWS CLIでカスタムイベントを送信する
aws events put-events --entries '[
  {
    "EventBusName": "my-app-event-bus",
    "Source": "my-app.orders",
    "DetailType": "OrderCompleted",
    "Detail": "{\"orderId\": \"12345\", \"amount\": 5000}"
  }
]'

AWS Lambdaのログ（Amazon CloudWatch Logs）を確認し、イベントが正しく受信されているかを検証してください。コンソールの「イベントバス」画面にある「テストイベントを送信」機能でも動作確認できます。

料金の仕組みとコスト感覚

EventBridgeの料金はイベント数課金が基本です（2026年3月時点）。

月100万イベントを超えない小規模なシステムでは、EventBridge自体の料金はほぼゼロに近いレベルです。コストが積み上がるのはターゲット側（AWS Lambdaの実行料金、Amazon SQSのメッセージ料金など）がほとんどです。

AWSサービスイベント（EC2の状態変化、S3のオブジェクト作成など）を受信する場合は追加料金なしです。ただし、自社アプリから put-events APIで送信するカスタムイベントは課金対象になります。大量のイベントを送信するシステムでは、イベントのバッチ送信（1回の呼び出しで最大10件）を活用してAPI呼び出し回数を抑えることを検討してください。

実務での活用パターン

パターン1: マイクロサービス間の疎結合化

注文サービス・在庫サービス・メール通知サービスが別々に存在するマイクロサービス構成を考えます。

従来のオンプレ設計では「注文完了 → 在庫サービスのAPIを直接呼ぶ → メール通知APIを直接呼ぶ」という直列実行になりがちでした。注文サービスは他のサービスを全て知っている必要があります。

Amazon EventBridgeを使うと「注文完了 → OrderCompletedイベントを発行」だけで済みます。在庫サービスもメール通知サービスも、それぞれ独立したルールでイベントを受け取り、並列に処理できます。注文サービスは他サービスの存在を一切知らなくていい。これが疎結合の本質です。

パターン2: AWSサービスイベントを活用した運用自動化

EC2やRDSなどのAWSサービスは、状態変化を自動的にデフォルトイベントバスに送信します。これを活用することで、追加コストなしに運用自動化が実現できます。

・EC2インスタンス停止の自動通知: EC2の stopped 状態変化をEventBridgeで検知 → AWS LambdaでSlackに通知
・Amazon RDSスナップショット完了の通知: RDSのバックアップ完了イベントを受信 → Amazon SNSでチームにアラート
・S3バケットポリシー変更の監視: AWS Configイベント連携で設定変更を検知 → セキュリティチームにメール送信

オンプレでは監視ツールのエージェントを各サーバーに仕込んでポーリングしていた処理が、AWSサービスイベントとEventBridgeの組み合わせでほぼゼロコストで実現できます。

パターン3: スケジューラーでcronジョブをサーバーレス化

オンプレのcronサーバーを廃止し、Amazon EventBridge Schedulerに移行するケースは多いです。

# EventBridge Schedulerでcron式を使う例（毎日午前9時に実行）
aws scheduler create-schedule \
  --name daily-batch-job \
  --schedule-expression "cron(0 9 * * ? *)" \
  --schedule-expression-timezone "Asia/Tokyo" \
  --target '{
    "Arn": "arn:aws:lambda:ap-northeast-1:123456789012:function:MyFunction",
    "RoleArn": "arn:aws:iam::123456789012:role/EventBridgeSchedulerRole"
  }' \
  --flexible-time-window '{"Mode": "OFF"}'

タイムゾーンを Asia/Tokyo で指定できる点は、オンプレのcronからの移行でありがたいポイントです。EC2インスタンスを常時稼働させる必要がなくなるため、cronサーバーのコスト削減にも直結します。

Linuxサーバーでのcron設定の基礎については、姉妹サイトLinuxMaster.JPで詳しく解説しています。

よくあるトラブルと対処法

ターゲットのLambdaが実行されない

最もよくあるのがIAM権限の設定漏れです。EventBridgeがAWS Lambdaを呼び出すには、LambdaのリソースベースポリシーにEventBridgeからの呼び出しを許可する設定が必要です。

# LambdaにEventBridgeからの実行権限を付与する
aws lambda add-permission \
  --function-name MyFunction \
  --statement-id AllowEventBridgeInvoke \
  --action lambda:InvokeFunction \
  --principal events.amazonaws.com \
  --source-arn arn:aws:events:ap-northeast-1:123456789012:rule/my-app-event-bus/order-completed-rule

コンソールでルールを作成した場合はこの設定が自動で付与されますが、TerraformやAWS CDKで作成した場合は明示的な設定が必要なことがあります。

イベントパターンにマッチしているのにルールが動かない

EventBridgeのイベントパターンはサブセットマッチです。パターンに記述したフィールドが、受信イベントのJSONに含まれていれば一致と判定されます。

よくある落とし穴が、put-events APIで送信する Detail フィールドの値です。JSON形式のオブジェクトではなく、エスケープされた文字列として渡す必要があります。型を間違えると、イベントパターンのフィルタリングが正しく動作しません。

EventBridgeコンソールの「イベントパターンのテスト」機能を使うと、送信するJSONがパターンにマッチするかを事前に確認できます。ぜひ活用してください。

スケジューラーの実行時刻がずれる

Amazon EventBridge SchedulerはデフォルトのタイムゾーンがUTCです。--schedule-expression-timezone "Asia/Tokyo" を明示しないと、日本時間と9時間ずれて実行されます。オンプレのcronからの移行時に見落としやすいポイントです。設定後は必ず実際に実行されるログをAmazon CloudWatch Logsで確認してください。

本記事のまとめ

Amazon EventBridgeの要点を整理します。

オンプレでのポーリング型・密結合設計から、EventBridgeを中心としたイベント駆動設計へのシフトは、クラウドネイティブなシステム設計の第一歩です。まずはデフォルトイベントバスを活用したEC2状態変化の検知から試してみると、EventBridgeの動作を体感しやすいです。