Amazon EventBridge強化版Custom event busを読み解く――組織横断のイベント基盤はどう変わるか

EventBridgeが「共有できるイベント基盤」へ進化

Amazon EventBridgeに、エンタープライズ向けに強化された新しいCustom event busが登場しました。今回の変更は単なる機能追加ではありません。複数のチームやAWSアカウントにまたがるイベント連携を、専用のメッセージ基盤を運用せずに構築しやすくするものです。

新しいCustom event busでは、次の機能が提供されます。

• AWS Resource Access Managerによるクロスアカウント共有
• CloudEventsなど、既存のJSONイベント形式を維持したイベント発行
• 24時間の標準イベント保持と、最大1年までの保持期間拡張
• 厳密な順序性を必要とするユースケースへの対応
• コンテンツベースの自動的な重複排除
• Subscriberリソースによるフィルタリングと、250以上のAWSサービスへの配信
• データ転送量を基準とする新しい料金モデル

既存のCustom event busは、混同を避けるためCustom event bus - classicに名称変更されます。既存APIは引き続き変更されません。

従来のEventBridge Classicとの違い

従来のEventBridge Custom event busでも、イベントパターンによるルーティングやAWSサービスとの連携は可能でした。一方、今回の強化版は、イベントを受け取って配信するだけでなく、イベント基盤を複数チームで共有することを意識した設計になっています。

既存システムを直ちに移行する必要はありません。現在のClassicバスが安定して動作している場合は、そのまま利用しつつ、新規の組織横断連携から強化版を適用するという段階的な導入が現実的です。

クロスアカウント共有がマイクロサービスに効く理由

大規模なAWS環境では、チームやシステムごとにアカウントを分離する構成が一般的です。たとえば、注文、決済、在庫、配送を別アカウントで管理している場合、各サービス間のイベント連携には次のような設計が必要でした。

• 中央のイベント基盤へ各アカウントからイベントを転送する
• アカウント間に個別の権限や配信経路を構築する
• イベント形式やスキーマをチーム間で調整する
• 障害発生時の再送や履歴取得の仕組みを用意する

新しいCustom event busでは、中央のイベントバスを複数アカウントから共有できます。これにより、イベント発行側は共通のバスへ直接発行し、購読側は必要なイベントだけをフィルタリングして受け取る構成を取りやすくなります。

重要なのは、アカウント共有によってネットワーク接続を減らせる可能性があることです。ただし、共有範囲を広げすぎると、どのチームがどのイベントを発行・購読できるのか分かりにくくなります。実運用では、次のようなルールを先に決めるべきです。

• イベントバスを所有するプラットフォームチームを定義する
• 発行者と購読者のAWSアカウントを明確に管理する
• IAMポリシーで発行権限と購読権限を分離する
• イベント名、スキーマ、バージョニング方針を標準化する
• 本番・ステージング環境のイベントバスを分離する

CloudEvents対応で得られる移植性

イベント駆動アーキテクチャでは、イベントの中身だけでなく、発生元、種類、発生時刻、識別子などのメタデータも重要です。CloudEventsは、こうしたイベントの共通属性を定義するJSONベースの形式です。

新しいCustom event busでは、CloudEventsのような形式でイベントを発行し、そのスキーマを変更せずに扱えます。これにより、EventBridge専用の形式へ変換する処理を減らしやすくなります。

たとえば、注文サービスが次のようなイベントを発行する設計を考えます。

{
  "specversion": "1.0",
  "id": "order-2025-000001",
  "source": "com.example.order",
  "type": "com.example.order.created.v1",
  "time": "2025-01-01T12:00:00Z",
  "subject": "order-12345",
  "datacontenttype": "application/json",
  "data": {
    "orderId": "order-12345",
    "customerId": "customer-67890",
    "totalAmount": 12800
  }
}

この形式を組織内の標準として採用すれば、AWS上の購読者だけでなく、将来ほかのメッセージ基盤やSaaSへ連携する場合にも、変換処理を抑えられます。

ただし、CloudEventsを採用すればスキーマ管理が不要になるわけではありません。typeの命名規則、必須属性、後方互換性、個人情報の扱いなどを、イベント契約として管理する必要があります。

保持期間の拡張は障害復旧と新機能追加に効く

新しいCustom event busには24時間のイベント保持が含まれ、保持期間は最大1年まで拡張できます。これは、単なる再送機能以上の意味を持ちます。

たとえば、購読サービスに障害が発生した場合、過去のイベントを利用して処理を再開できます。また、新しい検索サービスや分析コンポーネントを追加した際に、過去のイベントから初期データを構築する「ハイドレーション」にも活用できます。

一方で、イベント保持をデータベースの代わりに使う設計には注意が必要です。保持期間を超えたイベントは利用できず、イベントの完全性や再処理の方法も要件に依存します。長期的な監査証跡や完全な再構築が必要な場合は、S3やデータベースなどへの永続保存を併用する設計が適しています。

運用面では、次の点を決めておくとよいでしょう。

• どの障害をイベント保持から復旧するか
• 再処理時の開始位置や対象イベントをどう指定するか
• 同じイベントを再処理しても安全な冪等性をどう実現するか
• 保持期間を延長するイベントと、延長しないイベントをどう分けるか
• 個人情報や機密情報をイベントに含めるか

厳密な順序性と重複排除の実務的な意味

決済、在庫、状態遷移などでは、イベントの順序が結果に影響します。たとえば「注文をキャンセルした」というイベントを「注文を作成した」イベントより先に処理すると、正しい状態を再現できません。

今回の強化版は、厳密な順序性を必要とするユースケースに対応します。ただし、アプリケーション全体の処理順序が自動的に保証されるという意味ではありません。どの単位で順序を保証するのか、並列処理をどこまで許容するのか、失敗したイベントをどう扱うのかを設計する必要があります。

また、コンテンツベースの重複排除により、同一内容のイベントを重複して処理するリスクを抑えられます。しかし、重複排除だけで完全な冪等性が実現するわけではありません。外部API呼び出しやデータベース更新では、イベントIDや業務キーを使った冪等性制御を購読側にも実装するのが安全です。

Spring Bootから利用する際の実装パターン

Spring Bootアプリケーションでは、ドメインイベントの生成とEventBridgeへの発行を分離すると、AWS固有の実装に依存しにくくなります。次のように、アプリケーションサービスから発行ポートを呼び出す構成が考えられます。

public interface EventPublisher {
    void publish(OrderCreated event);
}

@Service
public class OrderService {
    private final EventPublisher eventPublisher;

    public OrderService(EventPublisher eventPublisher) {
        this.eventPublisher = eventPublisher;
    }

    public void createOrder(String orderId, String customerId, int totalAmount) {
        // 注文の永続化処理

        var event = new OrderCreated(
            orderId,
            customerId,
            totalAmount
        );

        eventPublisher.publish(event);
    }
}

EventPublisherの実装で、CloudEvents形式へのシリアライズ、新しいCustom event busへの発行、リトライ、ログ出力などを担当させます。AWS SDKや新しい発行APIを直接呼び出すコードをアプリケーションサービスへ埋め込まないことがポイントです。

本番実装では、次の対策も必要になります。

• イベント発行に失敗した場合の再試行方針
• DB更新とイベント発行の間で不整合が起きる問題への対策
• イベントID、相関ID、トレースIDの付与
• 発行成功数、失敗数、遅延時間、再処理数の監視
• 機密情報をログへ出力しないためのマスキング

注文情報をデータベースへ保存した直後にイベント発行が失敗する可能性があるため、厳密な整合性が必要なシステムでは、アウトボックスパターンなども検討対象になります。

Kafkaとの使い分け

Kafkaは、高スループットなストリーム処理、長期的なログ保持、細かなコンシューマー制御、Kafkaエコシステムとの統合に強みがあります。一方、新しいEventBridge Custom event busは、AWSサービスへの配信、サーバーレス運用、AWSアカウント間共有を重視するシステムに向いています。

大量のイベントを長期間保持して何度もストリーム処理する場合はKafkaが適する可能性があります。一方、チームが個別にコンシューマーを追加し、AWSサービスへイベントを配送する構成では、EventBridgeの運用上の利点が大きくなります。両者を併用し、EventBridgeを業務イベントの配信層、Kafkaをストリーム処理層とする構成も考えられます。

新料金モデルで見るコストの考え方

今回の強化版では、イベント数ではなくデータ転送量を基準とする料金モデルが導入されました。小さなイベントを大量に扱うシステムでは、イベント数課金よりもスケール時の単価が下がる可能性があります。

コストを見積もる際は、少なくとも次の値を分けて計算します。

• 1イベントあたりの平均サイズ
• 1秒あたり、または1日あたりのイベント数
• 発行元からイベントバスへ転送されるデータ量
• 購読者やターゲットへの配信データ量
• 保持期間を延長するイベントのデータ量
• クロスリージョンや他サービスへの転送に伴う費用

概算では、次のようにデータ量を算出できます。

月間データ量
= 1イベントの平均バイト数
  × 月間イベント数
  × 発行・配信経路の係数

実際の料金はリージョン、データ量、配信先、保持設定などに左右されるため、導入前にはAWSの料金ページと利用予定リージョンの条件をもとに見積もるべきです。特に、購読者が増えると配信データ量も増えるため、発行量だけで判断しないことが重要です。

採用時に確認したい設計ポイント

新しいCustom event busは、組織横断のイベント連携を簡素化する有力な選択肢です。ただし、機能が増えた分、イベント基盤のガバナンスがより重要になります。

採用前には、次の観点を整理してください。

• イベントバスの所有者と運用責任者
• アカウント間の発行・購読権限
• CloudEventsを含むイベントスキーマの標準
• 順序性を保証する単位と、並列処理の範囲
• 重複排除に加えた購読側の冪等性対策
• 再処理、障害復旧、監査の手順
• 保持期間と長期保存先
• 1イベントのサイズと月間データ転送量
• 東京を含む利用可能リージョンとデータレジデンシー
• 既存のCustom event bus – classicとの役割分担

強化版Custom event busは、既存のEventBridgeを置き換えるための機能というより、複数チーム・複数アカウントでイベントを共有するための選択肢を広げるアップデートと捉えると分かりやすいでしょう。イベント形式、保持、順序性、権限、コストを一体で設計できる組織であれば、マイクロサービス間の結合を減らしながら、AWSサービスとの連携も効率化できます。

出典： AWS What’s New