概要

Q: Amazon EventBridge とは何ですか?

Amazon EventBridge は、コードを作成せずに、AWS のサービス、独自のアプリケーション、Software as a Service (SaaS) アプリケーションのデータの変更にリアルタイムにアクセスできるサービスです。使用を開始するには、Amazon EventBridge コンソールでイベントソースを選択し、AWS Lambda、Amazon Simple Notification Service (SNS)、Amazon Kinesis Data Firehose といった数々の AWS のサービスの中からターゲットを選択します。Amazon EventBridge により、イベントがほぼリアルタイムで自動的に送信されます。

Q: Amazon EventBridge の使用をどのように開始できますか?

まず AWS アカウントにログインし、Amazon EventBridge コンソールに移動します。次に、パートナー SaaS アプリケーションと AWS のサービスの一覧からイベントソースを選択します。パートナーアプリケーションを使用する場合は、イベントを出力するよう SaaS アカウントを設定したことを確認し、Amazon EventBridge コンソールのイベントソースセクションでパートナーアプリケーションを選択します。Amazon EventBridge により、イベントがルーティングされるイベントバスが自動的に作成されます。別の方法として、AWS SDK を使用して、イベントバスへのイベントの出力を開始するようアプリケーションを設定することもできます。オプションでフィルタリングルールを設定し、イベントのターゲット (Lambda 関数など) をアタッチすることもできます。Amazon EventBridge により、設定したターゲットへのイベントの取り込み、フィルタリング、送信が、安全かつ可用性の高い方法で自動的に実行されます。

Q: Amazon EventBridge に独自のイベントを送信できますか?

はい。アプリケーションレベルのカスタムイベントを生成し、そのサービスの API を使用して Amazon EventBridge にイベントを送信できます。また、定期的に生成されるスケジュールされたイベントを設定し、Amazon EventBridge でサポートされているいずれかのターゲットでそのイベントを処理することもできます。

Q: イベントの形式はどのようなものですか?

イベントでは、特定の JSON 構造が使用されます。すべてのイベントには、イベントソース、タイムスタンプ、リージョンといった最上位のエンベロープフィールドがあります。その下にはイベントの本体である詳細フィールドが続きます。例えば、Amazon Elastic Compute Cloud (EC2) Auto Scaling グループで新しい Amazon EC2 インスタンスが作成された場合、"aws.autoscaling" というソースと "EC2 instance created successfully" という詳細を持つイベントが出力されます。

Q: どのイベントがターゲットに送信されるかをフィルタリングするにはどうすればよいですか?

ルールを使用してイベントをフィルタリングできます。ルールにより、受信イベントを任意のイベントバスと一致させ、処理のためターゲットにルーティングできます。単一のルールを使用して複数のターゲットにルーティングし、それらすべてを同時に処理できます。ルールにより、異なるアプリケーションコンポーネントで目的のイベントを探して処理することができます。ルールでは、イベントを特定の部分のみ渡すことにより、または常に上書きすることにより、ターゲットに送信する前にカスタマイズできます。前の質問で取り上げた例で説明すると、"aws.autoscaling" というソースと "EC2 instance created successfully" という詳細を持つイベントと一致させるイベントルールを作成し、Auto Scaling グループで Amazon EC2 インスタンスが正常に作成された時に常に通知を受け取れるようにすることができます。

Q: Amazon EventBridge へのアクセスを保護するにはどうすればよいですか?

Amazon EventBridge は AWS Identity and Access Management (IAM) と統合されているため、どのアクションを AWS アカウント内のユーザーが実行できるかを管理者が指定できます。例えば、組織内の特定のユーザーのみにイベントバスの作成やイベントターゲットのアタッチを許可する IAM ポリシーを作成できます。

Q: Amazon EventBridge は CloudWatch Events とどのように関連していますか?

Amazon EventBridge は、CloudWatch Events をベースに構築された、CloudWatch Events を拡張するサービスです。Amazon EventBridge では、CloudWatch Events と同じサービス API とエンドポイント、同じ基盤となるサービスインフラストラクチャを使用します。これまで CloudWatch Events を使用しているお客様にとっては、何も変わることはありません。これまでと同じ API、CloudFormation テンプレート、コンソールを引き続き使用できます。お客様からの報告によれば、CloudWatch Events はイベント駆動型アーキテクチャを構築するための理想的なサービスです。そのため、AWS ではお客様が独自のアプリケーションとサードパーティーの SaaS アプリケーションからデータを接続できるようにする新しい機能を構築しました。AWS は、この機能を CloudWatch サービス内にとどめておくのではなく、Amazon EventBridge という新しい名前でリリースしました。この機能が、CloudWatch Events が開発された目的であるモニタリングユースケースを超えた拡張であることを示すためです。

Q: 現在 Amazon CloudWatch Events を使用しており、Amazon EventBridge の機能をぜひ試してみたいと考えています。Amazon CloudWatch Events のルールとアクセス許可を Amazon EventBridge に移動させる必要がありますか?

いいえ。Amazon CloudWatch Events ユーザーは新しい Amazon EventBridge コンソールと API または Amazon CloudWatch Events コンソールと API で、既存のデフォルトのバス、ルール、イベントにアクセスできます。

Q: 現在 Amazon CloudWatch Events を使用しており、Amazon EventBridge の機能は必要ありません。Amazon EventBridge で何か変わることはありますか?

何も変わることはありません。Amazon EventBridge では同じ Amazon CloudWatch Events API を使用するため、既存のすべての CloudWatch Events API の使用に変化はありません。

Q: Amazon CloudWatch Events は将来廃止される予定ですか?

いいえ。API またはサービス自体を廃止する予定はありません。Amazon EventBridge では Amazon CloudWatch Events と同じ API を使用していますが、他の機能もあります。将来的に、Amazon CloudWatch Events の名称は Amazon EventBridge に置き換えられる予定です。

Q: Amazon EventBridge ではどの AWS のサービスがイベントソースとして統合されていますか?

EventBridge では、AWS Lambda、Amazon Kinesis、AWS Fargate、Amazon Simple Storage Service (S3) を含む 90 種類を超える AWS のサービスをイベントソースとして利用できます。AWS のサービスの統合の一覧については、EventBridge のドキュメントをご参照ください。

Q: Amazon EventBridge ではどの AWS のサービスがイベントターゲットとして統合されていますか?

EventBridge では、AWS Lambda、Amazon Simple Queue Service (SQS)、Amazon SNS、Amazon Kinesis Streams、Amazon Kinesis Data Firehose を含む 15 種類を超える AWS のサービスをイベントターゲットとして利用できます。AWS のサービスの統合の一覧については、EventBridge のドキュメントをご参照ください。

Q: EventBridge Archive および Replay Events とは何ですか?

Event Replay は Amazon EventBridge の新機能であり、お客様が、過去のイベントをイベントバスまたは特定の EventBridge ルールに再処理することを可能にします。この機能により、デベロッパーはアプリケーションを簡単にデバッグし、履歴イベントでターゲットをハイドレートすることでアプリケーションを拡張し、エラーから回復させることができます。Event Replay により、デベロッパーは、EventBridge に発行されたすべてのイベントにいつでもアクセスできるという安心感が得られます。

Q: EventBridge API Destinations とは何ですか?

API Destinations を使用すると、デベロッパーは、スループットを制御する機能と認証を備えたオンプレミスまたは SaaS アプリケーションにイベントを送り返すことができます。お客様はイベントの形式を受信サービスの形式にマップする入力変換を使用してルールを設定でき、EventBridge はセキュリティと配信を処理します。ルールがトリガーされると、Amazon EventBridge は指定された条件に基づいてイベントを変換し、ルールのセットアップ時に提供された認証情報とともに、設定されたウェブサービスに送信します。セキュリティが組み込まれているため、デベロッパーは使用するサービス用に認証コンポーネントを記述する必要がなくなりました。

Q: API Destinations の「Connection」とは何ですか? API Destinations を設定するにはどうすればよいですか?

各 API Destinations は、HTTP エンドポイントへの接続に使用する承認方法と認証情報を定義する Connection を使用します。承認設定を設定して接続を作成すると、AWS Secrets Manager にシークレットが作成され、承認情報が安全に保存されます。アプリケーションに応じて、接続に含めるパラメータをさらに追加することもできます。

API Destinations を設定するには、API Destinations エンドポイント (イベントの HTTP 呼び出しエンドポイントターゲット) を提供する必要があります。このエンドポイントに対して認証するには、Connection を作成する必要があります。オプションで、呼び出しレート制限 (API Destinations エンドポイントに送信する 1 秒あたりの最大呼び出し数) を定義することもできます。接続と API Destinations の詳細をご覧ください

制限とパフォーマンス

Q: サービスの制限はどのようになっていますか?

こちらの「サービスの制限」ページを参照してください。

Q: イベントの送受信の間に発生するレイテンシーはどの程度になりますか?

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

Q: Amazon EventBridge ではリソースのタグ付け機能をサポートしていますか?

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

Q: Amazon EventBridge ではどの程度のスループットを見込めますか?

イベントバスのスループットの制限については、こちらの「サービスの制限」ページを参照してください。 より高いスループットが必要な場合は、AWS Support Center で [Create Case (ケースの作成)] を選択してから、[Service Limit Increase (サービス制限の緩和)] を選択し、サービス制限の緩和を申請してください。

Q: EventBridge にサービスレベルアグリーメント (SLA) はありますか?

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

スキーマレジストリ

Q: スキーマとは何ですか?

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

Q: スキーマレジストリとは何ですか?

スキーマレジストリでは、検索可能なスキーマのコレクションを格納します。それにより、ドキュメントを調べたり、情報についてスキーマの作成者を探したりすることなく、組織のデベロッパーなら誰でも簡単にアプリケーションによって生成されたスキーマにアクセスできます。スキーマはレジストリに手動で追加できます。または、EventBridge のスキーマの検出機能をオンにすることでこのプロセスを自動化することもできます。

Q: スキーマの検出機能とは何ですか?

スキーマの検出では、スキーマを見つけることやそれをレジストリに追加する処理を自動化します。EventBridge のイベントバスでスキーマの検出が有効になっている場合、イベントバスに送信される各イベントのスキーマはレジストリに自動的に追加されます。スキーマのイベントが変更されると、スキーマの検出ではレジストリに新しいバージョンのスキーマを自動的に作成します。レジストリにスキーマが追加されると、EventBridge コンソールや直接 IDE からスキーマのコードバインディングを生成することができます。それにより、コードで厳密に型指定されたオブジェクトとしてイベントを表現し、検証やオートコンプリートなどの IDE 機能を活用することができます。

Q: 他のアカウントに配信したイベントからスキーマを検出することはできますか?

スキーマの検出はデフォルト、カスタム、パートナーイベントバスの検出機能として、同じアカウント内で発生したイベントに対してのみ有効です。

Q: スキーマレジストリのコストはどれくらいですか?

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

Q: スキーマレジストリを使用すると記述する必要のあるコードの量をどのように減らすことができますか?

まず最初の点として、スキーマの検出を使用し、EventBridge のイベントバスに発行された、あらゆるイベントのスキーマを自動的に特定することができます。それをレジストリに格納し、イベントスキーマを手動で管理する手間を省きます。2 番目の点として、バスのイベントを扱うアプリケーションを記述するときに、スキーマのコードバインディングのダウンロードや生成ができます。それにより、コードで厳密に型指定されたオブジェクトとして使用できます。これは、イベントハンドラーの推測、検証、逆シリアル化のオーバーヘッドの削減につながります。

Q: スキーマレジストリを使用するメリットは何ですか?

スキーマレジストリを使用すると、EventBridge でイベント駆動型アプリケーションを高速に開発でき、アプリケーションコードに集中できるようになります。以前は、利用可能なイベントや構造を探し、コードとして実行できる形式にするためにイベントを解釈して、変換することが必要でした。今では、スキーマレジストリによって、AWS のサービス、サードパーティー、カスタムアプリケーションを含む、すべてのサポートされているイベントソースから利用可能なイベントを自動的に見つけて、スキーマを検出することができます。

Q: どの IDE でスキーマレジストリはサポートされていますか?

スキーマレジストリは、AWS Toolkit for JetBrains (IntelliJ、PyCharm、WebStorm、Rider)、VS Code、EventBridge コンソールや API でご利用いただけます。詳細については、IDE 内で EventBridge のスキーマレジストリの使用を参照してください。

Q: Serverless Application Model (AWS SAM) でスキーマを使用できますか?

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

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

Q: スキーマからどの言語を生成することができますか?

Java (8+)、Python (3.6+)、TypeScript (3.0+) でコードを生成できます。

Q: スキーマレジストリはどの AWS リージョンで利用できますか?

EventBridge スキーマは、米国東部 (オハイオおよびバージニア北部)、米国西部 (オレゴンおよび北カリフォルニア)、カナダ (中部)、欧州 (ストックホルム、パリ、アイルランド、フランクフルト、ロンドン)、アジアパシフィック (ムンバイ、東京、ソウル、シンガポール、香港、シドニー)、および南米 (サンパウロ) の各リージョンでご利用いただけます。

グローバルエンドポイント

Q: グローバルエンドポイントとは何ですか?

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

Q: グローバルエンドポイントを使用する必要があるのはなぜですか?

グローバルエンドポイントは、サービスの中断時にリスクにさらされるデータ量を最小限に抑えることで、エンドカスタマーにより良い体験を提供するのに役立ちます。イベント駆動型アプリケーションをより堅牢で回復力のあるものにするために、手動による介入を必要とせず、自動的にセカンダリリージョンにイベント取り込みをフェイルオーバーする機能を備えています。CloudWatch アラーム (Route53 ヘルスチェック経由) を使用してフェイルオーバー基準を設定する柔軟性を得て、いつフェイルオーバーを行って、いつプライマリリージョンへのイベントのルーティングを再開するのかを判断することができます。

Q: グローバルエンドポイントで、どのように私のアプリケーションの可用性が向上されますか?

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

Q: グローバルエンドポイントに適しているアプリケーションの種類は?

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

Q: グローバルエンドポイントのフェイルオーバーには、どのようなメトリクスを使用すればよいですか?

Amazon EventBridge のエンドツーエンドのレイテンシーを報告する新しいメトリクスを追加しました。これにより、EventBridge 内でエラーが発生し、イベントの取り込みをセカンダリリージョンにフェイルオーバーする必要があるかどうかを簡単に判断することができます。CloudWatch アラームと Route53 ヘルスチェックを作成するために、あらかじめ用意された CloudFormation スタック (必要に応じてカスタマイズ可能) を提供することで、コンソールで簡単に始められるようにしてあります。アラームとヘルスチェックのセットアップ方法の詳細については、起動に関するブログとドキュメントをご覧ください。

Q: グローバルエンドポイントのフェイルオーバーにサブスクライバーのメトリクスを使用すべきですか?

ヘルスチェックにサブスクライバーのメトリクスを含めることはお勧めしません。これは、プライマリリージョンで他のすべてのサブスクライバーが正常であるにもかかわらず、1 つのサブスクライバーに問題が発生した場合、パブリッシャーがバックアップリージョンにフェイルオーバーする原因となる可能性があるからです。もし、サブスクライバーの 1 つがプライマリリージョンでイベントの処理に失敗している場合、セカンダリリージョンのサブスクライバーがイベントを正常に処理できるようにレプリケーションを有効にする必要があります。

Q: 目標復旧時間 (RTO) と目標復旧時点 (RPO) はどの程度を想定していますか?

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

Q: レプリケーションを有効にするべきですか?

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

Q: 両方のリージョンでクォータを管理するためのベストプラクティスは何ですか?

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

Q: セカンダリリージョンで自分のアーキテクチャを簡単に複製する方法はありますか?

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

Q: セカンダリアーキテクチャに、任意のアカウント、任意のリージョン、任意のバスを使用することができますか?

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

Q: グローバルエンドポイントは、CloudTrail、S3、その他の AWS のサービスからの AWS イベントと連動しますか?

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

Q: レイテンシーベースのルーティングはサポートされていますか?

いいえ、起動の第一の反復では、レイテンシーベースのルーティングはサポートしていません。
グローバルエンドポイントのコストはいくらですか?

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

Q: レプリケーションに料金はかかりますか?

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

Q: グローバルエンドポイントはどのリージョンで利用できますか?

グローバルエンドポイントは、米国東部 (オハイオおよびバージニア北部)、米国西部 (オレゴンおよび北カリフォルニア)、カナダ (中部)、欧州 (ストックホルム、パリ、アイルランド、フランクフルト、ロンドン)、アジアパシフィック (ムンバイ、東京、ソウル、シンガポール、大阪、シドニー)、および南米 (サンパウロ) の各リージョンでご利用いただけます。

料金と請求

Q: EventBridge の使用にはどれくらいのコストがかかりますか?

料金についてはこちらを参照してください。

 

Q: イベントバスがアタッチされていないイベントソースにパートナーから送信されるイベントに料金はかかりますか?

いいえ。

アーキテクチャと設計

Q: 別のアカウントにイベントを送信するターゲットを使用することはできますか?

はい。これはクロスアカウントイベントと呼ばれ、別のアカウントのデフォルトのイベントバス、またはその他のイベントバスであるターゲットを使用することができます。

Q: Amazon EventBridge と AWS CloudFormation は一緒に使用できますか?

AWS CloudFormation では、ルールと EventBusPolicy のリソースがサポートされています。イベントバスとイベントソースのリソースはまだサポートされていませんが、今後サポートされる予定です。

Q: Amazon EventBridge と Amazon SNS はそれぞれどのような場合に使用しますか?

Amazon EventBridge と Amazon SNS は両方ともイベント駆動型アプリケーションの開発に使用できます。どちらを選択するかはお客様の特定のニーズによって決まります。Amazon EventBridge の使用をお勧めするのは、SaaS アプリケーションや AWS のサービスからのイベントに対応するアプリケーションを構築する場合です。Amazon EventBridge は、サードパーティーの SaaS パートナーと直接統合される唯一のイベントベースのサービスです。また、EventBridge ではデベロッパーがアカウント内にリソースを作成する必要なく、90 種類を超える AWS のサービスからイベントを自動的に取り込むことができます。さらに、Amazon EventBridge では定義された JSON ベースの構造がイベントに使用されます。また、イベントの本体全体に適用されるルールを作成してイベントを選択し、ターゲットに転送できます。現在 Amazon EventBridge では、AWS Lambda、Amazon SQS、Amazon SNS、Amazon Kinesis Streams と Kinesis Data Firehose といったサービスを含む 15 種類を超える AWS のサービスがターゲットとしてサポートされています。リリース時点で、Amazon EventBridge にはスループットの制限 (「サービスの制限」を参照) があります。この制限は申請により緩和することができます。レイテンシーは通常約 0.5 秒です。

Amazon SNS の使用をお勧めするのは、他のアプリケーションやマイクロサービスからパブリッシュされた高スループットまたは低レイテンシーのメッセージに対応するアプリケーション (Amazon SNS ではほぼ無制限のスループットが提供されるため)、または非常に高いファンアウト (数十万または数百万のエンドポイント) を必要とするアプリケーションを構築する場合です。メッセージは構造化されておらず、任意の形式にすることができます。Amazon SNS では 6 種類の異なるターゲット (AWS Lambda、Amazon SQS、HTTP/S エンドポイント、SMS、モバイルプッシュ、E メール) へのメッセージ転送がサポートされています。Amazon SNS のレイテンシーは通常 30 ミリ秒未満です。Amazon EC2、Amazon S3、Amazon RDS を含む 30 種類を超える幅広い AWS のサービスで、SNS メッセージを送信するよう設定し、送信できます。

統合

Q: SaaS アプリケーションを Amazon EventBridge と統合するメリットは何ですか?

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

Q: 自社 (SaaS 企業) は優れたイベントソースになると考えています。パートナーになるにはどうすればよいですか?

Amazon EventBridge パートナーになることに関心をお持ちの SaaS ベンダーは、Amazon EventBridge integrations ページのセルフサービス型の手順に従って、Amazon EventBridge へのイベントをパブリッシュできます。

Q: Amazon EventBridge と統合するために SaaS ベンダーにはどのくらいの労力が必要ですか?

既に webhook またはプッシュベースの統合モードをサポートしている SaaS ベンダーは、5 日未満の開発日数で Amazon EventBridge と統合できることが想定されます。

Q: どの SaaS 統合がサポートされていますか?

サポートされている統合の一覧については、こちらを参照してください。

Amazon EventBridge の統合
Amazon EventBridge の統合の詳細

Amazon EventBridge の統合のページにアクセスする

詳細 
コンソールで構築を開始する
コンソールで構築を開始する

AWS マネジメントコンソールで Amazon EventBridge を使った構築を始めましょう。

サインイン 
ドキュメントを読む
ドキュメントを見る

デベロッパーガイドで EventBridge の理解をさらに深めましょう。

詳細