【ITニュース解説】EventBridge to SQS when cross region and cross account

システムエンジニアを目指す皆さんにとって、現代のITシステム開発では、イベント駆動型アーキテクチャという考え方が非常に重要になってくる。このアーキテクチャでは、システム内で発生した「イベント」（例えば、ユーザーが商品を購入した、データが更新された、など）を検知し、そのイベントに応じて別の処理を自動的に実行するという仕組みがよく用いられる。このようなイベント駆動型システムでメッセージを効率的にやり取りするために、AWS（アマゾン ウェブ サービス）のEventBridge（イベントブリッジ）やSQS（シンプル キュー サービス）といったサービスが活躍する。

EventBridgeは、アプリケーションから発生する様々なイベントを一元的に集約し、設定されたルールに基づいて適切なターゲット（他のAWSサービスなど）にイベントをルーティングするサービスだ。一方、SQSは、メッセージを一時的に保存し、必要に応じてアプリケーションがメッセージを取り出すことができる、信頼性の高いメッセージキューサービスである。EventBridgeがイベントの「交通整理」を行い、SQSが「メッセージの一時保管所」として機能することで、システム間の連携をスムーズかつ堅牢に保つことができる。

多くの場合、EventBridgeでイベントを受け取った後、そのイベントをSQSキューに送り、別のアプリケーションがそのキューからメッセージを読み取って処理を進めるというパターンが利用される。この組み合わせは、イベント駆動型アーキテクチャの基本とも言える。しかし、システムが大規模になったり、複数のチームや部署でAWSアカウントを分けたり、地理的に異なるリージョン（地域）にサービスを分散させたりするようになると、EventBridgeからSQSへのメッセージ配信にも工夫が必要になる場面が出てくる。

本解説では、EventBridgeからSQSへメッセージを配信する際に遭遇する様々なシナリオと、それぞれの解決策について初心者にも分かりやすく解説していく。

最もシンプルなケースは、EventBridgeのイベントバス、そこで定義するルール、そしてイベントの送信先となるSQSキューが、すべて同じAWSアカウントの同じリージョン内に存在する場合だ。この場合、EventBridgeのルール設定で直接SQSキューをターゲットとして指定するだけで、簡単にメッセージを配信できる。これは、最も一般的で理解しやすい構成と言える。

次に、EventBridgeのイベントバスとルールは一つのリージョンにあるが、ターゲットとなるSQSキューが同じAWSアカウント内の別のリージョンにあるシナリオを考えてみよう。例えば、東京リージョンで発生したイベントを、大阪リージョンにあるSQSキューに送りたいといったケースだ。現状（2025年9月時点）では、EventBridgeは、ターゲットとなるSQSキューが同じリージョンにある場合にのみ直接メッセージを配信できるという制約がある。このため、直接異なるリージョンのSQSキューをターゲットとして指定することはできない。この制約を回避するためには、中継役となるEvent Busを利用する必要がある。具体的には、ターゲットのSQSキューが存在するリージョン（この例では大阪リージョン）に新しいEvent Busを作成するか、既存のデフォルトEvent Busを利用する。そして、この大阪リージョンのEvent Busのルールに、ターゲットとして大阪リージョンのSQSキューを設定する。さらに、元の東京リージョンのEventBridgeルールからは、この大阪リージョンのEvent Busをターゲットとして指定するのだ。これにより、イベントは「東京EventBridgeルール → 大阪Event Bus → 大阪SQSキュー」という経路で配信されることになる。

さらに複雑なシナリオとして、EventBridgeのイベントバスとルールがあるAWSアカウントに存在し、ターゲットとなるSQSキューが別のAWSアカウントに存在する場合がある。これらのリソースがすべて同じリージョン内にある場合を考えてみよう。以前は、異なるアカウントのリソースにメッセージを送る際も、前のシナリオと同様に、ターゲット側のAWSアカウントにEvent Busを設け、それを中継点とする必要があった。しかし、2025年初頭にEventBridgeの「クロスアカウントターゲット」という新機能が導入されたことで、このプロセスは大幅に簡素化された。この新機能を利用すれば、異なるAWSアカウントに存在するSQSキューであっても、EventBridgeのルールから直接ターゲットとして指定し、メッセージを配信できるようになる。これにより、異なるアカウント間での連携がよりシンプルになった。ただし、重要な制約として、このクロスアカウントターゲット機能を使う場合でも、EventBridgeのルールとターゲットSQSキューは「同じリージョン」にある必要がある。つまり、異なるAWSアカウントであっても、東京リージョンから東京リージョンのSQSキューへ送る、といった制約は依然として存在するのだ。

最後に、最も複雑なケースとして、EventBridgeのイベントバスとルールが一つ目のAWSアカウントの一つのリージョンにあり、ターゲットとなるSQSキューが、二つ目のAWSアカウントの、さらに異なるリージョンにあるというシナリオを見てみよう。例えば、アカウントAの東京リージョンから、アカウントBの大阪リージョンにあるSQSキューにメッセージを送りたい場合だ。ここまで解説してきた通り、EventBridgeは直接異なるリージョンのSQSキューをターゲットにできず、またクロスアカウントターゲット機能も同じリージョン内に限定される。このため、このシナリオでは、先に説明した「リージョンをまたぐための中継役Event Bus」の考え方と、「アカウントをまたぐためのクロスアカウントターゲット」の考え方を組み合わせる必要がある。具体的には、ターゲットのSQSキューが存在するリージョン（アカウントBの大阪リージョン）に、中継役となるEvent Busを設置する。そして、このアカウントBの大阪リージョンにあるEvent Busのルールに、ターゲットとして同じくアカウントBの大阪リージョンにあるSQSキューを設定する。次に、元のEventBridgeルールがあるアカウントAの東京リージョンから、アカウントBの大阪リージョンに設置した中継Event Busを、クロスアカウントターゲットとして指定するのだ。これにより、イベントは「アカウントA東京EventBridgeルール → アカウントB大阪Event Bus（クロスアカウント経由） → アカウントB大阪SQSキュー」という経路で配信されることになる。

これらのシナリオを総合すると、EventBridgeからSQSへのメッセージ配信における基本的な原則が見えてくる。それは、「EventBridgeのルールと、最終的なターゲットとなるSQSキューは、できる限り同じリージョンに配置する」ということだ。もし、EventBridgeのルールとターゲットSQSキューが同じリージョンに存在するのであれば、ターゲットSQSキューが別のAWSアカウントにあったとしても、比較的シンプルに直接メッセージを配信できる（クロスアカウントターゲット機能を利用）。しかし、EventBridgeのルールとターゲットSQSキューが異なるリージョンに存在する場合は、メッセージを届けたいSQSキューがあるリージョンに、一時的な「中継点」としてEvent Busを挟む必要が必ず発生する。この中継点のEvent BusとターゲットSQSキューは、同じAWSアカウント内にあっても、別のAWSアカウント内にあっても構わない。この原理を理解しておくことで、EventBridgeを使った柔軟で堅牢なイベント駆動型システムを設計する上で、非常に役立つだろう。