ある企業が複数の社内システムから生成されるイベントを処理するイベントバスアーキテクチャを AWS 上に構築しています。各システムは異なるイベント形式（JSON スキーマが異なる）を使っており、それぞれのイベントを適切なコンシューマーにルーティングする必要があります。また、将来的に新しいイベントタイプやコンシューマーを追加する際に、既存のコードを変更せずに対応できる拡張性が必要です。最も適切なアーキテクチャはどれですか？
- A. Amazon SNS でトピックを作成し、各コンシューマーが必要なトピックを購読する。各ソースシステムが適切なトピックにメッセージを送信する
- B. Amazon Kinesis Data Streams に全イベントを送信し、Lambda がすべてのイベントを受信してソースシステムと種別に応じてルーティングロジックを実装する
- C. すべてのイベントを SQS FIFO キューに送信し、Lambda ポーリングで順序付き処理を実装する
- D. Amazon EventBridge をイベントバスとして使用し、各ソースシステムからのイベントをカスタムイベントバスに送信する。EventBridge ルールでイベントパターン（source、detail-type、detail の属性）に基づいてイベントをフィルタリングし、適切なターゲット（Lambda、SQS、SNS、Step Functions）に自動ルーティングする。EventBridge Schema Registry でスキーマを管理する
解答と解説を見る
正解: D
EventBridge はサーバーレスのイベントバスで、イベントパターンマッチング（source、detail-type、任意の detail フィールド）に基づく細かなルーティングが可能です。新しいルールを追加するだけで既存コードを変更せずに新しいイベントタイプやコンシューマーを追加できます。Schema Registry でスキーマを管理し、イベント駆動アーキテクチャのドキュメントとして活用できます。 B: Kinesis + Lambda でのカスタムルーティングは、新しいイベントタイプ追加のたびにコード変更が必要で、拡張性の要件に反します。 A: SNS は有効ですが、複数の属性を組み合わせた複雑なフィルタリング（メッセージフィルタリングポリシー）は EventBridge のイベントパターンマッチングほど柔軟ではありません。 C: SQS FIFO は順序付き処理に有効ですが、イベントのルーティング（異なるコンシューマーへの振り分け）機能がなく、単一のコンシューマーへの配信のみです。
📚 関連サービスの解説: Amazon EventBridge ・ AWS Lambda