Amazon EventBridge のよくある質問

EventBridge には、イベントを公開できるレート、イベントバスで作成できるルールの数、ターゲットを呼び出すことができるレートに関するデフォルトのクォータがあります。クォータの詳細なリストとそれを引き上げる方法については、Service Quotas のページをご覧ください。

レイテンシーは通常約 0.5 秒です。これは場合によって異なることにご注意ください。

はい、ルールとイベントバスにタグを付けることができます。

デフォルトの EventBridge クォータは、1 秒あたり数十万のイベントを処理するように増やすことができます。イベントバスのスループットの制限については、「AWS Service Quotas のページ」ページをご覧ください。より多くのスループットが必要な場合は、[ケースを作成] を選択してから、[サービス制限の引き上げ] を選択して、AWS サポートセンターを通じてサービス制限の引き上げをリクエストします。

はい。AWS では、毎月の請求期間において、それぞれの AWS リージョンで少なくとも 99.99% の月間稼働率で EventBridge を利用可能とするよう、商業上合理的な努力を払います。詳細については、EventBridge サービスレベルアグリーメントをご確認ください。

スキーマとはイベントの構造を表し、通常、イベントに含まれているデータの、各要素の形式やタイトルなどの情報を含んでいます。

例えば、スキーマには名前、電話番号などのフィールドを含む場合があります。名前がテキスト文字列であることや電話番号が整数であることなどの情報を含みます。スキーマには、電話番号の長さが 10 桁であるという必要条件などの、パターンについての情報を含めることもできます。イベントのスキーマは、イベントに含まれる情報を表しており、そのデータに基づいたコードを書くのに役立つため、重要です。

スキーマレジストリは、検索可能なスキーマのコレクションを保存するため、組織内のどのデベロッパーでも、アプリケーションによって生成されたスキーマにより簡単にアクセスすることができます。これは、スキーマのドキュメントを見たり、スキーマの作者を探したりするのとは対照的です。スキーマはレジストリに手動で追加できます。または、EventBridge のスキーマの検出機能をオンにすることでこのプロセスを自動化することもできます。

スキーマの検出では、スキーマを見つけることやそれをレジストリに追加する処理を自動化します。EventBridge のイベントバスでスキーマの検出が有効になっている場合、イベントバスに送信される各イベントのスキーマはレジストリに自動的に追加されます。スキーマのイベントが変更されると、スキーマの検出ではレジストリに新しいバージョンのスキーマを自動的に作成します。

スキーマがレジストリに追加されると、EventBridge コンソールまたは統合開発環境 (IDE) で直接、スキーマのコードバインディングを生成できます。これにより、コード内でイベントを強く型付けされたオブジェクトとして表現することができます。これにより、検証やオートコンプリートなどの IDE の機能を利用することができます。

はい。スキーマ検出では、アカウント全体のイベントを検出できるため、イベントバスに公開されたイベントのスキーマを完全に可視化できます。

スキーマレジストリの使用に料金はかかりませんが、スキーマの検出をオンにした場合、取り込まれたイベントごとに料金が発生します。

スキーマの検出は、1 か月あたり 500 万件の取り込まれたイベントまで無料利用枠で利用でき、ほとんどの開発での使用はこれを超えることはありません。無料利用枠を超えて使用する場合、100 万件の取り込まれたイベントごとに 0.10 USD の追加料金が発生します。料金についての詳細は、EventBridge の料金ページをご覧ください。

スキーマレジストリでは、次のことが可能になるため、コード量を削減できます。

• EventBridge のイベントバスに発行された、あらゆるイベントのスキーマを自動的に特定することができます。それをレジストリに格納し、イベントスキーマを手動で管理する手間を省きます。
• バスのイベントを扱うアプリケーションを記述すると、スキーマのコードバインディングのダウンロードや生成ができ、コードで厳密に型指定されたオブジェクトとして使用できます。

コードバインディングにより、イベントハンドラーの推測、検証、逆シリアル化のオーバーヘッドが軽減されます。

イベント駆動型アプリケーションをより速く構築するには、スキーマレジストリを使用する必要があります。スキーマレジストリは、AWS サービス、サードパーティ、カスタムアプリケーションなど、サポートされているイベントソースから利用可能なイベントを自動的に見つけ、そのスキーマを検出することで、開発チーム間の調整に費やす時間を削減します。開発者が利用可能なイベントやその構造を探したり、イベントを解釈して翻訳するコードを書いたりする貴重な時間を無駄にすることなく、アプリケーションコードだけに集中できるように構築されました。

スキーマレジストリは、AWS Toolkit for JetBrains (IntelliJ IDEA、PyCharm、WebStorm、Rider) および Visual Studio Code を通じて、ならびに EventBridge コンソールや API で使用できます。詳細については、IDE 内での EventBridge のスキーマレジストリの使用をご覧ください。

はい。最新バージョンの AWS SAM CLI にはインタラクティブモードが含まれています。これは、EventBridge でスキーマ用に新しいサーバーレスアプリケーションをイベントタイプとして作成するのに役立ちます。

「EventBridge スターターアプリケーション」のテンプレート、イベントのスキーマを選択すると、SAM で自動的に EventBridge に基づく Lambda 関数を使用したアプリケーションが生成され、イベントのコードが処理されます。つまり、イベントトリガーをコード内の通常のオブジェクトのように扱い、IDE で検証やオートコンプリートなどの機能を使用できるということです。

AWS Toolkit for Jetbrains (Intellij IDEA、PyCharm、Webstorm、Rider) プラグインおよび AWS Toolkit for Visual Studio Code は、これらの IDE から直接、スキーマをトリガーとして使用して、このテンプレートからサーバーレスアプリケーションを生成する機能も提供します。

EventBridge が提供するコード生成は Java (8 以上)、Python (3.6 以上)、TypeScript (3.0 以上)、Go (1 以上) で利用できます。

EventBridge スキーマレジストリは、以下のリージョンで利用できます。

• 米国東部 (オハイオ、バージニア北部)
• 米国西部 (北カリフォルニア、オレゴン)
• アジアパシフィック (香港、ムンバイ、ソウル、シンガポール、シドニー、東京)
• カナダ (中部)
• 欧州 (フランクフルト、アイルランド、ロンドン、パリ、ストックホルム)
• 南米 (サンパウロ)

EventBridge Pipes は、イベントプロデューサーとコンシューマーをポイントツーポイントで統合する、よりシンプルで一貫性のあるコスト効率の良い方法を提供しています。パイプを作成することは、ソースとターゲットを選択するのと同じくらい簡単であり、バッチ処理、開始位置、同時実行などをカスタマイズできます。オプションのフィルタリングステップを使用すると、特定のソースイベントのみをパイプに流し込めます。また、AWS Lambda、AWS Step Functions、API 送信先、あるいは Amazon API Gateway を活用したオプションの強化ステップを使用すれば、ターゲットに到達する前のイベントを強化または変換できます。EventBridge Pipes では、差別化につながらない統合コードを記述、管理、スケールする必要がないため、アプリケーションの接続ではなく、アプリケーションの構築に時間をかけることができます。

EventBridge コンソールにアクセスし、[Pipes] タブを選択して、[Pipe を作成] を選択することで開始できます。そこから、利用可能なソースのリストから選択し、必要なイベントのみを転送するために使用されるフィルタリングパターンをオプションで指定できます。パイプのオプションの変換とエンリッチメントのステップでは、SaaS アプリケーション API やコンテナクラスター、Lambda 関数、AWS Step Function などの API エンドポイントを提供できます。そして、パイプが API リクエストを行い、処理が完了した時点でレスポンスを取得します。最後に、イベントの配信先サービスを設定し、パイプでアーカイブまたは DLQ 機能を有効にする必要があるかどうかを指定します。AWS CLI、CloudFormation、AWS Cloud Development Kit (CDK) を使用してパイプを作成することも可能です。

EventBridge Pipes は、EventBridge 製品群のソースとして、Amazon SQS、Amazon Kinesis、Amazon DynamoDB、Amazon Managed Streaming Kafka、セルフマネージド型の Kafka、および Amazon MQ を導入しています。EventBridge Pipes は、イベントバスと同じターゲットサービスをサポートしています。例としては、Amazon SQS、AWS Step Functions、Amazon Kinesis Data Streams、Amazon Kinesis Data Firehose、Amazon SNS、Amazon ECS があり、イベントバス自体もサポートしています。

EventBridge Pipes は、Velocity Template Language (VTL) を使用した基本的な変換をサポートしています。より強力な変換を行う場合、EventBridge Pipes では、Lambda 関数または Step Functions ワークフローを指定してイベントを変換することができます。Amazon Elastic Container Service (ECS) やAmazon Elastic Kubernetes Service (EKS) などのコンテナサービスを使用したい場合は、コンテナクラスターの API エンドポイントと認証スキームを指定できます。その後、EventBridge が変換のためのイベントを配信します。

いいえ。EventBridge Pipes は、既存の EventBridge の機能とは別に使用でき、EventBridge イベントバスを使用せずに、Kinesis、SQS、Amazon MSK などの他のイベントプロデューサーからイベントを受信するのに役立ちます。また、多対多の統合にイベントバスを使用する場合、ポイントツーポイントの統合にも使用されます。すでに EventBridge イベントバスを使用してイベントをルーティングしている場合は、EventBridge Pipes を使用して、サポートされているソースに接続し、イベントバスをパイプのソースとして設定することが可能です。

EventBridge イベントバスは、イベント駆動型サービス間の多対多のイベントルーティングに適しています。EventBridge Pipes は、イベントパブリッシャーとコンシューマー間のポイントツーポイントの統合を目的としており、高度な変換やエンリッチメントに対応しています。EventBridge Pipes は、EventBridge イベントバスをターゲットとして使用できます。2 つのリソース間でフィルタリングとターゲットが同じままなので、EventBridge のイベントバスルールからパイプへの移行はより簡単です。

AWS Lambda の イベントソースマッピング (ESM) と Amazon EventBridge Pipes は、同じポーリングインフラストラクチャを使用してイベントを選択し、送信しています。ESM は、受信したイベントを処理するターゲットとして Lambda を使用したいお客様に最適です。Pipes は、Lambda コードの作成、メンテナンス、スケーリングを気にするのではなく、ソースと 14 を超えるターゲットのいずれかを接続するためのシンプルなマネージドリソースをご希望のお客様に最適です。

はい、EventBridge Pipes は、イベントソースから受信したイベントを配信先サービスに送信する際、その順番を維持します。

はい。イベントのバッチ処理をサポートしているサービスでは、パイプの作成時に希望するバッチサイズを設定することができます。バッチ処理をサポートしないソースやターゲットの場合でも、エンリッチメントや変換のステップでイベントをバッチ処理することができます。これにより、コンピューティングコストを節約しながら、選択したターゲットにイベントを個別に配信することができます。

はい、自分のアカウントで行った EventBridge Pipes API コールの履歴を取得するには、AWS マネジメントコンソールで AWS CloudTrail を有効にする必要があります。

Amazon EventBridge Pipes の料金の詳細については、料金ページにアクセスしてください。

Amazon EventBridge スケジューラは、基盤となるインフラストラクチャをプロビジョニングまたは管理することなく、AWS サービス全体で数百万のスケジュールを作成、実行、および管理することを簡素化するサーバーレスタスクスケジューラです。

AWS アカウントにログインし、EventBridge コンソールに移動して、[スケジュールを作成] ボタンを選択します。ステップバイステップワークフローに従い、必要なフィールドに入力します。タスク実行の時間枠、固定レート、Cron、特定の日時など、スケジューリング形式を選択します。AWS サービスのリストからターゲットを選択し、再試行ポリシーを設定することで、スケジュールの実行を最大限に制御することができます。スケジュールを確認し、[作成] を選択します。

EventBridge スケジューラーは、Scheduled Rules で提供されるスケジューリング機能に基づいて構築されています。EventBridge スケジューラーには、タイムゾーンのサポート、スケールの増加、ターゲットペイロードのカスタマイズ、時間式の追加、およびスケジュールをモニタリングするためのダッシュボードが含まれています。スケジュールは、スケジュールされたルールを使用してイベントバスを作成する必要なく、個別に作成できます。

Scheduled rules は引き続き使用できますが、EventBridge Scheduler はより豊富な機能セットを提供し、スケジュールの作成、実行、および管理においてより柔軟性があります。無料で開始することもできます。詳細については、料金ページをご覧ください。

EventBridge スケジューラーは AWS サービスと密に統合されており、AWS API アクションを持つあらゆるサービスに対してスケジュールを作成することが可能です。タイムパターンや再試行の設定は AWS で統一されており、一貫したスケジューリングが可能です。スケジュールのモニタリングは、EventBridge Scheduler コンソールのダッシュボードや 「ListSchedule」API リクエストで簡単に行うことができます。開始時間、最終実行時間、割り当てられた AWS ターゲットなど、スケジュールに関する重要な情報を確認することができます。より詳細な情報については、CloudWatch Logs で利用可能な実行ログを確認するか、S3 または Kinesis Firehose に送信することができます。

変更するスケジュールを選択すると、EventBridge スケジューラーコンソールでスケジュールを更新できます。新しいパネルにオプションが表示されます。

はい。EventBridge スケジューラーでは、スケジュールがどのタイムゾーンで動作するかを選択できます。これらのスケジュールは自動的に夏時間 (DST) に調整され、標準時間に戻ります。

EventBridge スケジューラーは、ターゲットに対して少なくとも 1 回のイベント配信を行い、ターゲットからの応答を得ることを意味する at-least-once イベントを提供します。再試行、タイムウィンドウ、およびタイムアウトを設定するオプションは、ビジネス要件を満たすために使用できます。

完了時の削除は、現在サポートされているすべてのスケジューリングパターン (cron、rate、および 1 回限りのスケジュール) で使用できます。

はい。スケジュールが呼び出される前であればいつでも、スケジュールを更新して完了時に削除するように設定できます。前回のスケジュール呼び出し時刻を過ぎると、変更を加えることはできません。

スケジュールが最後に呼び出される前に完了時に削除してスケジュールを無効にした場合、そのスケジュールは無効状態のままアカウントに残ります。

スケジュールは引き続きターゲットを呼び出し、終了日が設定されるまで自動的に削除されません。

EventBridge スケジューラーは、AWS 以外のターゲットを直接サポートしません。ただし、Lambda、ECS、Fargate、またはAPI Destinations 経由の EventBridge 機能を使用して、AWS 以外のターゲットを呼び出すことができます。

Amazon EventBridge スケジューラの料金の詳細については、料金ページにアクセスしてください。

グローバルエンドポイントを使用すると、AWS を使用した高可用性イベント駆動型アプリケーションを簡単に構築できます。プライマリーおよびセカンダリーリージョン間でイベントを複製し、最小限のデータ損失でフェイルオーバーを実施することができます。また、サービスが停止した場合に備えて、バックアップリージョンに自動的にフェイルオーバーする機能を実装することもできます。これにより、マルチリージョンアーキテクチャの採用が容易になり、イベント駆動型アプリケーションに回復力を持たせることができます。

グローバルエンドポイントは、サービスの中断時にリスクにさらされるデータ量を最小限に抑えることで、エンドカスタマーにより良い体験を提供するのに役立ちます。

イベント駆動型アプリケーションをより堅牢で回復力のあるものにするために、手動による介入を必要とせず、自動的にセカンダリリージョンにイベント取り込みをフェイルオーバーする機能を備えています。Amazon CloudWatch アラーム (Amazon Route 53 ヘルスチェック経由) を使用してフェイルオーバー基準を設定する柔軟性を得て、いつフェイルオーバーを行って、いつプライマリリージョンへのイベントのルーティングを再開するのかを判断することができます。

グローバルエンドポイントにイベントを発行したら、イベントはプライマリリージョン内のイベントバスにルーティングされます。プライマリリージョンでエラーが検出された場合、ヘルスチェックが異常としてマークされ、受信イベントがセカンダリリージョンにルーティングされます。エラーは、指定した CloudWatch アラーム (Route 53 ヘルスチェックを介して) を使ってより簡単に検出できます。問題が軽減されると、新しいイベントをプライマリリージョンにルーティングし直し、イベントの処理を継続します。

グローバルエンドポイントは、冪等性を必要としないアプリケーションや、リージョン間で冪等性を処理できるアプリケーションに適しています。また、420 秒までのイベントが複製されないことに耐性を持つアプリケーションに適しています。このため、サービスやリージョンが回復するまで、プライマリリージョンに留まることになります (目標復旧時点と呼ばれます)。

EventBridge のレイテンシー全体を報告する新しいメトリクスを追加しました。これにより、EventBridge 内でエラーが発生し、イベントの取り込みをセカンダリーリージョンにフェイルオーバーする必要があるかどうかをより容易に判断できるようになりました。

CloudWatch アラームと Route53 ヘルスチェックを作成するために、あらかじめ用意された CloudFormation スタック (必要に応じてカスタマイズ可能) を提供することで、コンソールで簡単に始められるようにしました。アラームとヘルスチェックのセットアップ方法の詳細については、起動に関するブログとドキュメントをご覧ください。

ヘルスチェックにサブスクライバーメトリクスを含めないことを推奨します。これは、プライマリリージョンで他のすべてのサブスクライバーが正常であるにもかかわらず、1 つのサブスクライバーに問題が発生した場合、パブリッシャーがバックアップリージョンにフェイルオーバーする原因となる可能性があるからです。

もし、サブスクライバーの 1 つがプライマリリージョンでイベントの処理に失敗している場合、レプリケーションを有効にして、セカンダリリージョンのサブスクライバーがイベントを正常に処理できることを確認する必要があります。

目標復旧時間 (RTO) は、障害発生後、バックアップリージョンまたはターゲットが新しいイベントを受信し始める時間です。目標復旧時点 (RPO) は、障害発生時に処理されずに残されるデータの指標です。グローバルエンドポイントの場合、アラーム設定に関する規定のガイダンスに従うと、RTO と RPO は 360 秒になります (最大 420 秒)。RTO については、CloudWatch アラームの開始や Route 53 ヘルスチェックのステータスを更新する期間も含まれます。RPO の場合、セカンダリリージョンに複製されず、サービスやリージョンが回復するまでプライマリリージョンに滞留するイベントも時間に含まれます。

はい。サービスの中断時にリスクにさらされるデータを最小限に抑えるために、レプリケーションを有効にします。両方のリージョンでカスタムバスをセットアップし、グローバルエンドポイントを作成したら、グローバルエンドポイントにイベントを公開するようにアプリケーションを更新することができます。そうすることで、問題が軽減された時点で、受信イベントがプライマリリージョンに再び複製されます。セカンダリリージョンでイベントをアーカイブして、サービス中断時に失われるイベントがないことを確認することができます。サービスの中断からすばやく復旧するために、セカンダリリージョンにアーキテクチャを複製して、イベントの処理を続行することができます。また、問題が緩和された後の自動的な回復を確認するために、レプリケーションを有効にする必要があります。

プライマリおよびセカンダリリージョンで同じクォータが設定されていることを確認する必要があります。レプリケーションを有効にして、セカンダリリージョンでイベントを処理する必要があります。これは、正しいクォータがあることを確認するだけでなく、セカンダリリージョンのアプリケーションが正しく設定されていることを確認するためです。

AWS CloudFormation StackSets を使用すると、AWS リージョン間でより簡単にアーキテクチャをレプリケートできます。例については、ドキュメントを参照してください。

起動の第一の反復では、オプトイン、中国、GovCloud リージョンはサポートされていません。このローンチでサポートされるリージョンのリストについては、以下のこの質問を参照してください。また、リージョンをまたいだ同一アカウント、同一名称のバス間でのフェイルオーバーやリカバリもサポートしています。

グローバルエンドポイントは、カスタムイベントでのみ利用可能です。今後、AWS サービスからのイベント、S3 からのオプトインイベント (Amazon S3 イベント通知)、サードパーティーイベントのサポートを追加していく予定です。

いいえ、起動の第一の反復では、レイテンシーベースルーティングはサポートしていません。

グローバルエンドポイントは追加料金なしでご利用いただけます。グローバルエンドポイントは現在カスタムイベントのみに使用でき、グローバルエンドポイントに発行されたカスタムイベントについては、カスタムイベントごとに課金されます。料金については、EventBridge の料金ページにアクセスしてください。

はい。レプリケーションには、EventBridge がクロスリージョンイベントに対して課金するもので、100 万件のイベントにつき 1 USD の料金がかかります。

グローバルエンドポイントは次のリージョンで利用できます。

• 米国東部 (オハイオ、バージニア北部)
• 米国西部 (北カリフォルニア、オレゴン)、
• アジアパシフィック (ムンバイ、大阪、ソウル、シンガポール、シドニー、東京)
• カナダ (中部)
• 欧州 (フランクフルト、アイルランド、ロンドン、パリ、ストックホルム)
• 南米 (サンパウロ)

Amazon EventBridge では、従量課金制モデルで柔軟な価格設定が可能です。お支払いいただくのは、イベントバスで公開されたイベント、スキーマ検出のために取り込まれたイベント、イベントリプレイ、API Destinations に対してのみです。EventBridge の例と料金の詳細については、料金ページにアクセスしてください。

いいえ。

はい。これはクロスアカウントイベントと呼ばれ、別のアカウントのデフォルトのイベントバス、またはその他のイベントバスであるターゲットを使用することができます。これを使用すると、複数のアカウントからのイベントを 1 つのイベントバスに集約して、イベントの監視と監査をより簡単にしたり、アカウント間でデータを同期したりできます。

はい。CloudFormation サポートは、Amazon EventBridge が利用可能なすべてのリージョンでご利用いただけます。CloudFormation を使用して EventBridge のリソースをプロビジョニングし管理する方法についての詳細は、ドキュメントをご覧ください。

EventBridge と SNS は両方ともイベント駆動型アプリケーションの開発に使用できます。どちらを選択するかはお客様の特定のニーズによって決まります。

Amazon EventBridge の使用をお勧めするのは、独自のアプリケーション、SaaS アプリケーション、AWS のサービスからのイベントに対応するアプリケーションを構築する場合です。EventBridge は、サードパーティーの SaaS パートナーと直接統合される唯一のイベントベースのサービスです。また、EventBridge ではデベロッパーがアカウント内にリソースを作成する必要なく、200 種類を超える AWS のサービスからイベントを自動的に取り込むことができます。

EventBridge は、定義された JSON ベースの構造をイベントに使用し、イベントの本体全体に適用されるルールを作成し、ターゲットに転送するイベントを選択するのに役立ちます。EventBridge は現在、Lambda、SQS、SNS、Amazon Kinesis Data Streams、Data Firehose など、20 以上の AWS サービスをターゲットとしてサポートしています。

Amazon SNS は、高いファンアウト (数千または数百万のエンドポイント) を必要とするアプリケーションに推奨されます。よく見られるパターンは、お客様が SNS をルールのターゲットとして使用して、必要なイベントをフィルタリングし、複数のエンドポイントにファンアウトするというものです。

メッセージは構造化されておらず、任意の形式にすることができます。SNS では 6 種類の異なるターゲット (Lambda、SQS、HTTP/S エンドポイント、SMS、モバイルプッシュ、E メール) へのメッセージ転送がサポートされています。Amazon SNS のレイテンシーは通常 30 ミリ秒未満です。(Amazon EC2、Amazon S3、Amazon RDS を含む 30 種類を超える) 幅広い AWS サービスで、SNS メッセージを送信するよう設定して送信できます。

AWS AppFabric はコード不要のサービスであり、セキュリティ、管理、生産性を向上させることで、企業の Software as a Service (SaaS) アプリケーションへの既存の投資を強化します。Asana、Slack、Zoom などのアプリや Microsoft 365 や Google Workspace などの生産性スイートからの SaaS ログデータを集約して正規化することで、アプリケーションのオブザーバビリティを高め、ポイントツーポイント統合の構築と維持に関連する運用コストを削減するには、AppFabric を使用します。EventBridge は、イベントを使用してアプリケーションコンポーネント同士を接続するサーバーレス統合サービスです。これにより、デベロッパーはスケーラブルなイベント駆動型アプリケーションを簡単に構築できます。カスタムアプリケーション、AWS サービス、サードパーティーの SaaS アプリケーションなどのソースからのイベントを組織全体のコンシューマーアプリケーションにルーティングするには、EventBridge を使用します。EventBridge は、イベントの取り込み、フィルタリング、変換、配信を行うためのシンプルで一貫した方法を提供します。

Amazon EventBridge では、AWS に構築されたカスタマーのイベント駆動型アーキテクチャに、SaaS ベンダーがサービスをより簡単に統合できるようにします。

EventBridge では、SaaS ベンダーの製品に数百万の AWS デベロッパーが直接アクセスでき、新しいユースケースを提供できるようします。また、監査に完全に対応した、安全でスケーラブルなイベント送信用の経路が提供されます。SaaS ベンダーがイベントのインフラストラクチャを管理する必要はありません。

EventBridge パートナーになることに関心がある SaaS ベンダーは、Amazon EventBridge integrations ページのセルフサービスの手順に従って、EventBridge でのイベントの発行を開始する必要があります。

Webhook やその他のプッシュ型統合モードを既にサポートしている SaaS ベンダーは、EventBridge との統合に 5日もかからずに済むかもしれません。

45 を超える SaaS 統合をサポートしています。Amazon EventBridge でサポートされている SaaS 統合のリスト一覧をご覧ください。