クラウドがよく分かる！お役立ちコラム

Amazon EventBridgeとは？使い方とメリット・デメリットを解説

• #Amazon EventBridge

Amazon EventBridgeの概要

Amazon EventBridgeは、AWSが提供するイベントバスサービスです。サーバーレスで利用でき、これを用いることで疎結合なイベント駆動型アーキテクチャを簡単に構築できます。例えば、AWSサービスや既存システム、SaaSアプリケーションなどと容易に連携し、それぞれのイベントをきっかけに処理を実行させることが可能です。

AWSが提供するサービスだけでなく、外部のSaaSアプリケーションや既存システムとの統合も可能である点が特徴です。これにより、大規模なイベント駆動型アプリケーションを柔軟かつ効率的に構築できます。

Amazon CloudWatch Eventsとの違い

Amazon EventBridgeは2019年7月に公開されたサービスです。それ以前は「Amazon CloudWatch Events」が利用されていました。古くからAWSを利用している方であれば、両方を耳にしたことがあるかもしれません。

両者は似たサービスですが、いくつかの重要な違いがあります。まず、EventBridgeでは連携できるサービスが大幅に増え、AWS外のサービスで発生したイベントも扱えるようになりました。

また、イベントの集約が可能になった点も重要です。クロスリージョンイベント配信がサポートされ、異なるリージョン間で発生したイベントをまとめて処理できます。これにより、以前よりもイベント駆動型アーキテクチャの管理が容易になりました。

Amazon EventBridgeの主な要素

Amazon EventBridgeは、大きく分けて4つの要素で構成されています。それぞれの機能や役割を理解しておくことが、効果的な活用の第一歩です。

イベントバス

EventBridgeの中心にあるのが「イベントバス」です。イベントバスはイベントを受け取り、ルールに従ってターゲットに配信します。

• デフォルトイベントバス：AWSサービスのイベントを受け取る標準バス
• カスタムイベントバス：自作アプリや社内システムからイベントを送信
• パートナーイベントバス：SaaSアプリ（Zendesk、Shopifyなど）との統合用

さらにリソースポリシー を設定すれば、アカウント間配信（cross-account） や リージョン間配信（cross-region） を安全に構成できます。複数ドメイン（業務や環境）ごとにバスを分けると、責務分離と運用管理が明確にできるのです。

ルール（Rules）

イベントバスに登録するルールは、どのイベントをどのターゲットへ送るかを定義します。例えば、「EC2インスタンスが停止したらSNSトピックに通知する」という設定が可能です。ルールはイベントパターン（JSON）でフィルタリングでき、柔軟な条件設定ができます。1つのイベントに複数ルールが適用され、ファンアウト（多段配信）も容易です。たとえば、以下のように記述できます。

json

{

  "source": ["myapp.orders"],

  "detail-type": ["OrderCreated"],

  "detail": {

    "totalAmount": [{ "numeric": [ ">", 10000 ] }],

    "country": [{ "anything-but": ["JP"] }]

  }

}

スケジュールルール（EventBridge Scheduler）

ルールは イベント発生トリガー だけでなく、rate() や cron() による スケジュールトリガーが可能です。これを用いることで、バッチ起動や定期同期を簡単に実装できます。たとえば、大規模一斉スケジュール、遅延実行、タイムゾーン指定などより柔軟なジョブ実行です。

「ルール」にもスケジュール機能は存在しています。ただ、より柔軟なジョブ実行が必要なら、専用の EventBridge Scheduler の利用も検討しなければなりません。用途に応じて「ルールのスケジュール」か「Scheduler」の使い分けが必要です。

ターゲット（Targets）

イベントの送信先として指定できるAWSサービスは多数あります。

• Lambda
• Step Functions
• SNS / SQS
• Kinesis Data Streams
• API Gateway
• CodePipeline
• ECS / Fargate
• ほか多数

ターゲットごとに 再試行ポリシー、最大イベント年齢、デッドレターキュー（DLQ） を設定できます。これにより、サーバーレスアーキテクチャや分散処理パイプラインの構築が可能です。

スキーマレジストリ

EventBridgeは受信したイベントのスキーマを自動検出し、スキーマレジストリに保存できます。開発者はこのスキーマからコードバインディングを生成し、型安全なアプリケーション開発が可能です。また、スキーマのバージョニングで互換性管理（breaking／non-breaking）を明示し、マイクロサービス間の契約を透明化できます。

Amazon EventBridgeの使い方

Amazon EventBridgeの使い方はさまざま考えられます。今回は、EC2の状態変化イベントをトリガーにLambda関数を実行する仕組みを紹介します。

手順1：事前準備

Amazon EventBridgeでルールを満たした際に動作させるLambda関数の作成が必要です。詳細は割愛しますが、今回は「EC2StateChangeNotifier」という関数を作成しておきました。皆さんが実際に利用する際は、LambdaやSNSトピック、Systems Manegerオートメーションなど、必要なものを作成してください。

手順2：イベントバスとルールの準備

AWSマネジメントコンソールでEventBridgeを開きます。

イベントバスをクリックし設定画面を表示します。今回は「default」を利用するため、すでに作成されていることを確認します。

続いて「ルール」画面へ移動し「ルールを作成」をクリックします。

ルールの名前などを識別できるように入力します。

続いてイベントのパターンを設定します。これは「どういったイベントが発生するとルールを起動するか」の定義です。今回は「カスタムパターン」でJSONを入力します。この部分はAWSの公式ドキュメントを参照し、用途に応じたカスタマイズが必要です。入力後に「次へ」をクリックします。

続く画面ではターゲットを入力します。「Lambda関数」で事前に作成した「EC2StateChangeNotifier」を指定します。その後「レビューと作成 にスキップ」をクリックすると準備が完了です。

手順3：動作確認

イベントパターンで設定した事象を発生させることにより、Lambda関数が起動することを確認しましょう。今回であれば、EC2の起動もしくは停止でLambda関数が起動します。EC2の場合は検知に数十秒が必要となるため、少し待機してください。CloudWatch LogsでLambdaの実行ログを確認し、イベント内容を解析できます。

Amazon EventBridgeを導入するメリット

続いて、制御にAmazon EventBridgeを導入するメリットを解説します。

ポーリング不要で効率的

Amazon EventBridgeは、従来のように一定間隔でデータを取得する「ポーリング処理」が不要です。イベントが発生したタイミングで処理が始まり、無駄なリソース消費を抑えられます。システム負荷やAPI呼び出し回数を削減し、レスポンスの速いイベント駆動型アーキテクチャを実現できるのです。

高い拡張性

新たなマイクロサービスや外部SaaSとの統合を簡単に実現できる点はメリットです。AWS公式のサービスに加え、カスタムイベントバスやパートナーイベントバスも利用できます。これらを駆使すると、将来的な機能追加やシステム拡張にも柔軟な対応が可能です。

低運用コスト

サーバー管理やスケーリングの必要がない完全マネージドサービスです。そのため、インフラ運用コストを大幅に削減できるメリットがあります。イベント量が増減しても自動的にスケーリングし、ピーク時にも安定稼働できるのです。また、料金は発行イベント数で課金され、必要以上の課金を回避できるメリットもあります。

Amazon EventBridgeを導入するデメリット

最後に、Amazon EventBridgeを導入するデメリットを解説します。

イベント配信の遅延可能性

Amazon EventBridgeは高い可用性を備えています。ただ、負荷が集中するタイミングやネットワーク状況によっては、数秒〜数十秒程度遅延しかねません。リアルタイム性が厳格に求められる場合、遅延が大きなデメリットになる可能性があります。

イベントサイズ制限

1イベントあたりのサイズが最大256KBに制限されています。そのため、大量のデータを1回で送信する用途には不向きであることがデメリットです。必要に応じてS3やKinesisなどと組み合わせ、イベントではメタ情報のみ送る設計が推奨されます。

過剰なイベント発行によるコスト増

料金は発行イベント数に基づく従量課金制です。そのため、イベントの発生頻度が高いシステムでは予想以上にコストが膨らむことがありえます。無駄なイベントを抑えるフィルタリングや、複数イベントのバッチ化など、コスト最適化を意識した設計が必要です。