翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
組織内でクロスアカウント Amazon EventBridge 接続を作成する
作成者: Sam Wilson (AWS) と Robert Stone (AWS)
概要
大規模な分散システムでは、Amazon EventBridge を使用して、 AWS Organizations 組織内のさまざまな Amazon Web Services (AWS) アカウント間で状態の変化を通信します。ただし、EventBridge は通常、同じ 内のエンドポイントまたはコンシューマーのみをターゲットにできます AWS アカウント。例外は、別のアカウントのイベントバスです。そのイベントバスは有効なターゲットです。別のアカウントのイベントバスからイベントを消費するには、イベントをソースアカウントのイベントバスから送信先アカウントのイベントバスにプッシュする必要があります。異なる 内のアプリケーション間で重要なイベントを管理する際の課題を回避するには AWS アカウント、このパターンで示されている推奨アプローチを使用します。
このパターンは、 AWS Organizations 組織 AWS アカウント 内の複数の が関与する EventBridge でイベント駆動型アーキテクチャを実装する方法を示しています。このパターンでは AWS Cloud Development Kit (AWS CDK) Toolkit と を使用します AWS CloudFormation。
EventBridge には、イベントを受信、フィルタリング、変換、ルーティング、配信するのに役立つサーバーレスイベントバスが用意されています。EventBridge は、イベント駆動型アーキテクチャの重要なコンポーネントであり、メッセージのプロデューサーとそれらのメッセージのコンシューマーの分離をサポートしています。単一のアカウントでは、これは簡単です。マルチアカウント構造では、1 つのアカウントのイベントバス上のイベントを同じ組織内の他のアカウントで消費するために、追加の考慮事項が必要です。
プロデューサーとコンシューマーのアカウント固有の考慮事項については、「追加情報」セクションを参照してください。
前提条件と制限
前提条件
少なくとも 2 つの が関連付けられている AWS Organizations 組織 AWS アカウント
両方の の AWS Identity and Access Management (IAM) ロール。 AWS アカウント を使用して、両方の でインフラストラクチャをプロビジョニングできます AWS アカウント 。 AWS CloudFormation
Git がローカルにインストール
されている AWS Command Line Interface (AWS CLI) ローカルにインストールされている
AWS CDK ローカルにインストールされ、両方の でブートストラップされている AWS アカウント
製品バージョン
このパターンは、次のツールとバージョンを使用して構築およびテストされています。
AWS CDK ツールキット 2.126.0
Node.js 18.19.0
npm 10.2.3「」
Python 3.12
このパターンは、任意のバージョンの AWS CDK v2 または npm で機能します。Node.js バージョン 13.0.0 から 13.6.0 は と互換性がありません AWS CDK。
アーキテクチャ
ターゲット アーキテクチャ
次の図は、あるアカウントからイベントをプッシュし、別のアカウントで消費するためのアーキテクチャワークフローを示しています。

ワークフローには以下のステップが含まれます。
ソースアカウントのプロデューサー AWS Lambda 関数は、アカウントの EventBridge イベントバスにイベントを配置します。
クロスアカウント EventBridge ルールは、イベントを送信先アカウントの EventBridge イベントバスにルーティングします。
送信先アカウントの EventBridge イベントバスには、コンシューマー Lambda 関数を呼び出すターゲット Lambda ルールがあります。
ベストプラクティスは、コンシューマー Lambda 関数の失敗した呼び出しを処理するためにデッドレターキュー (DLQ) を使用することです。ただし、DLQ はわかりやすくするためにこのソリューションから省略されています。ワークフローに DLQ を実装し、ワークフローが障害から回復する機能を向上させる方法の詳細については、AWS Lambda 「エラー処理パターンの実装
自動化とスケール
AWS CDK は、必要なアーキテクチャを自動的にプロビジョニングします。EventBridge は、 に応じて 1 秒あたり数千レコードにスケールできます AWS リージョン。詳細については、Amazon EventBridge のクォータドキュメントを参照してください。
ツール
AWS のサービス
AWS Cloud Development Kit (AWS CDK) は、コードで AWS クラウド インフラストラクチャを定義およびプロビジョニングするのに役立つソフトウェア開発フレームワークです。このパターンでは、 AWS CDK アプリケーションを操作するのに役立つコマンドラインクラウド開発キットである AWS CDK Toolkit を使用します。
Amazon EventBridge は、アプリケーションをさまざまなソースのリアルタイムデータに接続できるようにするサーバーレスイベントバスサービスです。例えば、 AWS Lambda 関数、API 送信先を使用する HTTP 呼び出しエンドポイント、その他のイベントバスなどです AWS アカウント。
AWS Lambda は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。
AWS Organizations は、作成して一元管理する AWS アカウント 組織に複数の を統合するのに役立つアカウント管理サービスです。
その他のツール
コードリポジトリ
このパターンのコードは、GitHub cross-account-eventbridge-in-organization
ベストプラクティス
EventBridge を使用する際のベストプラクティスについては、以下のリソースを参照してください。
エピック
タスク | 説明 | 必要なスキル |
---|---|---|
ソースアカウントと送信先アカウントのローカル認証情報を設定します。 | 「新しい設定と認証情報の設定」を確認し、環境に最も適した認証と認証情報の方法を使用します。 重要ソースアカウント認証と送信先アカウント認証の両方 AWS CLI に を設定してください。 これらの手順は、 | アプリ開発者 |
両方をブートストラップします AWS アカウント。 | アカウントをブートストラップするには、次のコマンドを実行します。
| アプリ開発者 |
パターンコードをクローンします。 | リポジトリのクローンを作成するには、次のコマンドを実行します。
次に、 ディレクトリを新しくクローンされたプロジェクトフォルダに変更します。
| アプリ開発者 |
タスク | 説明 | 必要なスキル |
---|---|---|
AWS Organizations とアカウントの詳細 | プロジェクトのルートフォルダで、 に次の変更を加えます
| アプリ開発者 |
ProducerStack リソースをデプロイします。 | プロジェクトのルートディレクトリから次のコマンドを実行します。
プロンプトが表示されたら、 を介して作成された新しい IAM ロールとその他のセキュリティ関連のアクセス許可を受け入れます AWS CloudFormation。 | アプリ開発者 |
ProducerStack リソースがデプロイされていることを確認します。 | リソースを確認するには、以下を実行します。
| アプリ開発者 |
タスク | 説明 | 必要なスキル |
---|---|---|
ConsumerStack リソースをデプロイします。 | プロジェクトのルートディレクトリから次のコマンドを実行します。
プロンプトが表示されたら、 を介して作成された新しい IAM ロールとその他のセキュリティ関連のアクセス許可を受け入れます AWS CloudFormation。 | アプリ開発者 |
ConsumerStack リソースがデプロイされていることを確認します。 |
| アプリ開発者 |
タスク | 説明 | 必要なスキル |
---|---|---|
プロデューサー Lambda 関数を呼び出します。 |
| アプリ開発者 |
イベントが受信されたことを確認します。 |
| アプリ開発者 |
タスク | 説明 | 必要なスキル |
---|---|---|
ConsumerStack リソースを破棄します。 | このパターンをテストとして使用している場合は、追加コストが発生しないように、デプロイされたリソースをクリーンアップします。 プロジェクトのルートディレクトリから次のコマンドを実行します。
スタックの削除を確認するメッセージが表示されます。 | アプリ開発者 |
ProducerStack リソースを破棄します。 | プロジェクトのルートディレクトリから次のコマンドを実行します。
スタックの削除を確認するメッセージが表示されます。 | アプリ開発者 |
トラブルシューティング
問題 | ソリューション |
---|---|
送信先アカウントでイベントは受信されませんでした。 |
|
コンソールから Lambda 関数を呼び出すと、次のエラーが返されます。
| AWS アカウント 管理者に連絡して、 |
関連リソース
リファレンス
チュートリアルと動画
追加情報
プロデューサールール
ソースアカウントでは、EventBridge イベントバスが作成され、プロデューサーからのメッセージを受け入れます (アーキテクチャセクションを参照)。このイベントバスには、IAM アクセス許可が付随するルールが作成されます。ルールは、次のcdk.json
構造に基づいて、送信先アカウントの EventBridge イベントバスをターゲットにします。
"rules": [ { "id": "CrossAccount", "sources": ["Producer"], "detail_types": ["TestType"], "targets": [ { "id": "ConsumerEventBus", "arn": "arn:aws:events:us-east-2:012345678901:event-bus/CrossAccount" } ] } ]
消費するイベントバスごとに、イベントパターンとターゲットイベントバスを含める必要があります。
イベントパターン
イベントパターンは、このルールが適用されるイベントをフィルタリングします。この例では、イベントソースとレコードは、ソースアカウントのイベントバスから送信先アカウントのイベントバスに送信するイベントdetail_types
を識別します。
ターゲットイベントバス
このルールは、別のアカウントに存在するイベントバスを対象としています。ターゲットイベントバスを一意に識別するには、完全な arn
(Amazon リソースネーム) が必要です。 id
は、 で使用される論理 ID です AWS CloudFormation。ターゲットイベントバスは、ターゲットルールの作成時に実際に存在する必要はありません。
送信先アカウント固有の考慮事項
送信先アカウントでは、ソースアカウントのイベントバスからメッセージを受信する EventBridge イベントバスが作成されます。ソースアカウントからイベントを発行できるようにするには、リソースベースのポリシーを作成する必要があります。
{ "Version": "2012-10-17", "Statement": [{ "Sid": "AllowOrgToPutEvents", "Effect": "Allow", "Principal": "*", "Action": "events:PutEvents", "Resource": "arn:aws:events:us-east-2:012345678901:event-bus/CrossAccount", "Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-XXXXXXXXX" } } }] }
権限を付与することは特に重要です。これによりevents:PutEvents
、同じ組織内の他のアカウントがこのイベントバスにイベントを発行できるようになります。を組織 ID aws:PrincipalOrgId
として設定すると、必要なアクセス許可が付与されます。
イベントパターン
含まれているイベントパターンは、ユースケースに合わせて変更できます。
rule = events.Rule( self, self.id + 'Rule' + rule_definition['id'], event_bus=event_bus, event_pattern=events.EventPattern( source=rule_definition['sources'], detail_type=rule_definition['detail_types'], ) )
不要な処理を減らすには、イベントパターンで、送信先アカウントによって処理されるイベントのみが送信先アカウントのイベントバスに送信されるように指定する必要があります。
リソースベースのポリシー
この例では、組織 ID を使用して、送信先アカウントのイベントバスにイベントを配置できるアカウントを制御します。ソースアカウントの指定など、より制限の厳しいポリシーの使用を検討してください。
EventBridge クォータ
次のクォータに注意してください。
イベントバスあたり 300 ルールがデフォルトのクォータです。これは必要に応じて拡張できますが、ほとんどのユースケースに合わせる必要があります。
ルールごとに 5 つのターゲットが最大許容数です。アプリケーションアーキテクトは、イベントパターンをきめ細かく制御できるように、送信先アカウントごとに個別のルールを使用することをお勧めします。