概要

Q: Amazon EventBridge とは何ですか?

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

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

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

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

はい。アプリケーションレベルのカスタムイベントを生成し、そのサービスの API 操作を介して EventBridge にイベントを送信できます。また、定期的に生成されるスケジュールされたイベントを設定し、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 グループで EC2 インスタンスが正常に作成された時に常に通知を受け取れるようにすることができます。

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

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

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

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

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

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

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

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

Q: CloudWatch Events を段階的に廃止されるのですか?

いいえ。API またはサービス自体を廃止する予定はありません。EventBridge は、同じ 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: EventBridge ではどの AWS のサービスがイベントターゲットとして統合されていますか?

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

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

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

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

API Destinations により、デベロッパーは、スループットを制御する機能と認証を備えたオンプレミスまたは SaaS アプリケーションにイベントを送り返すことができます。イベントの形式を受信サービスの形式にマップする入力変換を使用してルールを設定でき、EventBridge はセキュリティと配信を処理します。ルールが開始されると、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: EventBridge ではリソースのタグ付け機能をサポートしていますか?

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

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

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

スキーマレジストリは、AWS Toolkit for JetBrains (IntelliJ IDEA、PyCharm、WebStorm、Rider) と AWS Toolkit for Visual Studio Code、および EventBridge コンソールと API 操作で利用可能です。詳細については、IDE 内で EventBridge のスキーマレジストリの使用を参照してください。

Q: AWS サーバーレスアプリケーションモデル (SAM) でスキーマを使用できますか?

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

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

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

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

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

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

パイプ

Q: Amazon EventBridge Pipes とは何ですか?

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

Q: EventBridge Pipes の使用を開始する方法は?

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

Q: EventBridge Pipes で利用可能なイベントソースは何ですか?

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 があり、イベントバス自体もサポートしています。

Q: 変換とエンリッチメントはどのように行われるのですか?

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

Q: EventBridge Pipes を使用するには、EventBridge イベントバスを使用する必要がありますか?

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

Q: EventBridge イベントバスと EventBridge Pipes の違いは何ですか?

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

Q: EventBridge Pipes は、AWS Lambda の Event Source Mapping (ESM) とどう違うのでしょうか?

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

Q: EventBridge Pipes は順番を保証してくれますか?

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

Q: EventBridge Pipes はイベントのバッチ処理をサポートしていますか?

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

Q: セキュリティ分析、および運用上のトラブルシューティングのために、使用しているアカウントで実行された EventBridge Pipes API コールの履歴を取得できますか?

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

Q: EventBridge Pipes のコストを教えてください。

Amazon EventBridge Pipes スケジューラーの料金の詳細については、料金ページを参照してください。

スケジューラー

Q: Amazon EventBridge スケジューラーとは何ですか?

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

Q: EventBridge スケジューラーの使用を開始する方法は?

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

Q: EventBridge スケジューラーと Scheduled Rules の違いは何ですか?

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

Q: EventBridge Scheduled Rules または EventBridge スケジューラーはどんな場合に使用できますか?

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

Q: この機能では他の AWS のサービスとどのように連携が行われていますか?

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

Q: スケジュールを更新するには?

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

Q: EventBridge スケジューラーはすべてのタイムゾーンをサポートしていますか?

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

Q: EventBridge スケジューラーはどのようにスケジュールされた配信を確認するのですか?

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

Q: スケジュールの状態をモニタリングするにはどうすればよいですか?

EventBridge スケジューラー では、作成したすべてのスケジュールについて、EventBridge スケジューラー コンソール内にモニタリングページを提供しており、スケジュールの詳細や実施状況を確認することができます。このページでは、スケジュールの開始日、実装のタイムパターン、ターゲット配信のステータス (成功、失敗、リトライを確認できるレスポンスコード付き) などを確認できます。

Q: オンプレミスサーバーや外部 SaaS 製品など、AWS 以外のサービスのタスクをスケジュールできますか?

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

Q: EventBridge スケジューラーの料金は?

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

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

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

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

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

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

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

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

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

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

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

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: グローバルエンドポイントは、CloudTrail、S3、その他の AWS のサービスからの AWS イベントと連動しますか?

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

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

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

Q: グローバルエンドポイントのコストはいくらですか?

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

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

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

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

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

料金と請求

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

こちらには料金の詳細が記載されています。

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

いいえ。

アーキテクチャと設計

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

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

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

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

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

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

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

統合

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

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

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

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

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

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

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

サポートされている統合の完全なリストについては、EventBridge の統合を参照してください。

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

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

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

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

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

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

詳細