Auth0のEvent StreamとAWS EventBridgeを連携して、リトライ可能かつ非同期に情報を連携する
はじめに
この記事で実現すること
この記事では、Auth0でユーザーをブロックした際に、自作アプリケーション側にもブロック状態が自動的に反映される仕組みを構築します。
具体的には、Auth0の管理画面でユーザーをブロックすると、その情報がAWS EventBridge経由でアプリケーションに通知され、即座にブロック状態が反映されます。
デモは以下の通りです。
こちらの記事では、Webhookを使った実装を紹介しましたが、今回はAWSのマネージドサービスを活用することで、より堅牢で運用しやすい構成を実現します。
この記事のアプローチ
今回の実装では、Auth0のEvent StreamとAWS EventBridgeを連携させることで、非同期かつリトライ可能な構成を実現します。
前回のWebhook版との大きな違いは、AWSのマネージドサービス（EventBridge、SQS、Lambda）を活用することで、リトライ機構やDLQ（Dead Letter Queue）による失敗イベントの再処理が可能になる点です。
これにより、一時的なネットワーク障害やアプリケーション側のエラーが発生しても、イベントを取りこぼしにくくなります。
他記事との関係
今回の内容を理解するために、まずは他の記事との関係性を整理します。
こちらの記事では、Auth0のEvent StreamからWebhookで直接通知を受け取る構成を紹介しました。
この前回のWebhook版はシンプルで実装しやすいというメリットがある一方で、以下のような課題も抱えていました。
- エラーが発生した際のリトライ処理を自前で実装する必要がある
- サーバーレス環境（Cloudflare Workersなど）では、EventEmitterなどでイベントが消失するリスクがある
- 連携先の長時間障害には対応しづらい
そこで今回のEventBridge版では、これらの課題をAWSのマネージドサービスで解決し、より本番運用に適した構成を目指します。
全体構成
それでは、今回構築するシステムの全体像を見ていきましょう。
構成図
今回構築するシステムの全体構成は以下のようになります。
この図では、Auth0からAWSのEventBridge、そしてデモアプリケーションまでの一連の流れを図示しています。
各コンポーネントの詳細な役割については、この後の項で順番に説明していきます。
処理フローの説明
まずは、システム全体の処理フローを順を追って説明します。
-
Auth0：ユーザーブロックイベントが発生
Auth0の管理画面でユーザーをブロックすると、user.updatedイベントが発生します。 -
EventBridge：Auth0からのイベントを受信
Auth0のEvent Streamで設定したAWS EventBridgeに、パートナーイベントソース経由でイベントが送信されます。 -
EventBus：イベントのフィルタリングとルーティング
EventBusに設定したルールで、Auth0からのイベントのみをフィルタリングし、SQSへ転送します。 -
SQS：イベントのキューイング
イベントをキューに保持し、後続のLambdaで処理できるようにします。
処理に失敗した場合は、設定した回数リトライした後、DLQ（Dead Letter Queue）に退避されます。 -
Lambda：イベント処理とアプリへの通知
SQSからイベントを取得し、デモアプリケーションのAPIを呼び出してブロック情報を通知します。 -
Demo App：ブロック状態の反映
今回のデモでは、Cloudflare Workers上で動作するVike/Honoアプリケーションでブロック状態を受け取り、反映します。
このように、Auth0でユーザーをブロックした瞬間から、アプリケーション側でもブロック状態が反映されるまでの流れが、非同期に処理されます。
各コンポーネントの役割
次に、システムを構成する各コンポーネントの役割をもう少し詳しく見ていきましょう。
まず、Auth0からのイベントを受信するのがEventBridge + EventBusです。
EventBridgeは、受信したイベントを適切なターゲット（この場合はSQS）にルーティングします。
Auth0との連携は、パートナーイベントソース経由となります。
次に、EventBridgeから受け取ったイベントは、SQS（Simple Queue Service）でキューに保持され、非同期処理を実現します。
この機能により、Lambda側の処理速度に関係なく、イベントを取りこぼすことなく受け取ることができます。
また、visibility timeoutの設定により、処理中のメッセージが他のコンシューマーに配信されないようにしています。
なので、非同期は保ちつつも、重複処理のリスクを低減しています。
万が一、SQSでの処理に失敗した場合は、イベントをDLQ（Dead Letter Queue）に退避します。
これにより、連携先のアプリケーションが復旧した後に、DLQからメッセージを再度メインキューに戻すことで、失敗したイベントを再処理することが可能です。
このような仕組みによって、一時的な障害でイベントが失われることを防いでいます。
最後に、SQSからイベントを取得して実際の処理を行うのがLambda関数（Node.js）です。
Lambda関数は、デモアプリケーションのAPIエンドポイントにHTTPリクエストを送信します。
今回はNode.js 20を使用し、シンプルなHTTPクライアント処理を実装しています。
Event Streamとは
ここまでで全体構成を説明してきましたが、そもそもAuth0のEvent Streamとは何なのかを軽く見ていきます。
この章では、Event Streamの概要と機能について説明します。
ただし、詳細については触れませんので、興味がある方は公式ドキュメントを参照してください。
概要
Auth0のEvent Streamは、Auth0で発生した各種イベントをリアルタイムに外部システムへ配信する機能です。
記事執筆時点(2026/01/12)ではEarly Accessの機能となっていますので、今後仕様が変更される可能性があることを念頭に置いてください。
このEvent Streamを使用することで、ユーザーに関するイベント（ログイン、ユーザー情報の更新、ブロックなど）や組織（Organization）に関するイベントを検知し、外部システムに配信できるようになります。
今回使用するuser.updatedイベントは、ユーザー情報が更新された際に発行されるイベントです。
イベントペイロードには、user_id、blocked、emailなどの情報が含まれており、このblockedプロパティを確認することで、ユーザーがブロックされたかどうかを判定できます。
ただし、一つ注意点があります。
user.updatedイベントはブロック以外の更新でも発火するということです。
例えば、メールアドレスの変更やメタデータの更新などでも同じイベントが配信されるため、本来であればblockedプロパティの変化を検知するフィルタリングロジックが必要になります。
今回ではブロックした時のケースしか扱っていませんが、実際はイベント内の値をどう扱うかはあらかじめ検討が必要となります。
配信先の選択肢
続いて、Auth0のEvent Streamがサポートしている配信先について見ていきます。
Event Streamは、Webhook URLとAWS EventBridgeの2つの配信先をサポートしています。
まず一つ目が、Webhook URLです。
これはこちらの記事で使用した方式で、指定したURLに対してHTTP POSTリクエストでイベントを送信する方式になります。
実装がシンプルで、任意のエンドポイントに配信できるというメリットがある一方で、シークレットの管理や、リトライ処理や障害対応を自前で実装する必要があります。
そして二つ目が、今回使用するAWS EventBridgeです。
この方式では、AWSのパートナーイベントソースを経由して、EventBridgeにイベントを配信します。
AWSのマネージドサービスと連携できるため、リトライ機構やDLQなどの機能を活用でき、より堅牢な構成を実現できるのが特徴です。
今回の構成の利点
ここまでで、システムの全体構成とEvent Streamの概要を説明してきました。
それでは次に、今回のEventBridge構成が持つ具体的な利点について見ていきましょう。
非同期処理によるブロッキングの回避
まず一つ目の利点は、非同期処理によるブロッキングの回避です。
今回の構成では、Auth0からEventBridge、SQS、Lambdaと非同期に処理が進むため、イベント発生元であるAuth0の処理をブロックしません。
Webhook版でも受け取った後に非同期処理を行うことは可能ですが、別途キューの仕組みを用意する必要があります。
特に、サーバーレス環境（例：Cloudflare Workers）でWebhookを受ける場合、EventEmitterなどを使ったイベント駆動の実装では、イベントが消失するリスクがあります。
というのも、Cloudflare Workersのようなエッジ環境では、リクエストのライフサイクルが短く、バックグラウンド処理の保証が難しいためです。
イベントを取りこぼさずに処理するには、やはりキューイングの仕組みが必要になります。
一方、今回のEventBridge + SQS構成では、AWSのマネージドサービスがキューイングを担保してくれるため、こうした課題を気にする必要がありません。
リトライ機構による一時的障害への耐性
二つ目の利点は、リトライ機構による一時的障害への耐性です。
SQSには標準的なリトライ機能が組み込まれており、Lambda関数での処理が失敗した場合、自動的にリトライされます。
今回の構成では、maxReceiveCountを3回に設定しているため、3回失敗するとDLQに移動する仕組みになっています。
これに対して前回のWebhook版では、エラーが発生した際に処理が消失してしまう可能性がありました。
もちろん、Webhook側でリトライ処理を実装することも可能ですが、連携先のアプリケーションが長時間ダウンしている場合、何度リトライしても失敗し続けることになってしまいます。
その点、SQSを使用することで、メッセージはキューに保持され、連携先が復旧するまで待つことができます。
さらに、visibility timeoutの設定により、処理中のメッセージが重複して処理されることも防げます。
DLQによる失敗イベントの再処理
そして三つ目の利点が、DLQによる失敗イベントの再処理です。
DLQ（Dead Letter Queue）は、指定した回数リトライしても処理に失敗したメッセージを退避する仕組みです。
この仕組みが威力を発揮するのは、連携先のアプリケーションに長時間障害が発生した場合です。
このような場合、メインキューでリトライを繰り返すのではなく、DLQに退避させることで、他の正常なメッセージの処理を妨げないようにできます。
そして、連携先が復旧した後に、DLQからメッセージを再度メインキューに戻すことで、失敗したイベントを再処理できるというわけです。
この再投入は、手動で行うことも、Lambda関数を使って自動化することも可能です。
このようにして、一時的な障害でイベントが失われることを防ぎ、イベントを失わずに処理できるようになります。
今回の構成の注意点
ここまで、今回の構成の利点を説明してきました。
しかし、良いことばかりではなく、注意すべき点もいくつかあります。
この章では、本番運用を考える際に考慮すべき注意点について説明します。
イベント順序の担保の難しさ
まず一つ目の注意点は、イベント順序の担保の難しさです。
今回の構成では、標準のSQSキュー（FIFOではない）を使用しているため、イベントの処理順序は保証されません。
どういうことかというと、例えば以下のような状況が考えられます。
- ユーザーAをブロックするイベントが発生
- その直後にユーザーAのブロックを解除するイベントが発生
- 何らかの理由でブロックイベントの処理が失敗し、DLQに移動
- ブロック解除イベントは正常に処理される
- 後でDLQからブロックイベントが再処理される
この場合、実際にはブロックが解除されているにもかかわらず、最後にブロックイベントが処理されるため、ユーザーAはブロック状態になってしまいます。
では、FIFOキューを使えば解決するのかというと、そう単純ではありません。
FIFOキューを使用すれば、ある程度の順序は保証されますが、DLQとメインキューを合わせた順序担保は困難です。
この問題を完全に解決するには、アプリケーション側でタイムスタンプを使った制御や、イベントのバージョニングなどの工夫が必要になります。
今回のデモでは、この点については対応していませんが、本番運用では考慮が必要な点だと認識しています。
冪等性の確保が必要
二つ目の注意点は、冪等性の確保です。
SQSとLambdaの構成では、同じイベントが複数回処理される可能性があります。
具体的には、例えば以下のような状況が考えられます。
- Lambda関数がSQSからメッセージを取得し、処理を開始
- 処理自体は成功したが、メッセージの削除前にLambda関数がタイムアウト
- SQSはメッセージが削除されていないため、再度同じメッセージを配信
このような重複処理を防ぐには、アプリケーション側で冪等性を担保する必要があります。
具体的な対策としては、イベントに含まれるevent_idをキーにして、既に処理済みかどうかをチェックする仕組みが有効です。
今回のデモでは、シンプルさを優先して冪等性は担保していませんが、本番運用では必須の対策となります。
コストへの意識
最後の注意点は、コストについてです。
今回の記事では、詳細なコスト計算は行いませんが、EventBridge、SQS、Lambdaのそれぞれでコストが発生します。
特に注意が必要なのが、EventBridgeです。
EventBridgeはイベント数に応じて課金されるため、むやみに多くのイベントを流すとコストが増加します。
前述の通り、user.updatedイベントはブロック以外の更新でも発火するため、フィルタリングを行わないと不要なイベントも配信されてしまいます。
そのため、本番導入時は、以下の点を考慮しつつ、キャッチしたいイベントをフィルタリングの検討が必要となります。
- 月間のイベント発生数
- SQSのメッセージ数とリトライ回数
- Lambda関数の実行回数と実行時間
設定手順
さて、ここまでで構成の利点と注意点を説明してきました。
それでは次に、実際にこの構成を試すための設定手順を見ていきましょう。
前提条件
まず、今回の構成を試すには、以下の前提条件が必要です。
一つ目は、Cloudflareアカウントです。
デモアプリケーションをCloudflare Workers上にデプロイしますので、アカウントを用意してください。
無料プランで構いません。
二つ目は、Auth0テナントです。
Auth0のアカウントとテナントが作成済みであることが必要です。
Event Streamを使用するため、Early Access機能が利用できる必要があります。
三つ目は、AWSアカウントです。
EventBridge、SQS、Lambdaを使用します。
IAM Identity CenterでAdmin権限を持つSSOアカウントがあることを前提としています。
これらのアカウントが準備できていれば、サンプルリポジトリの手順に従って構築を進められます。
サンプルリポジトリ
詳細な設定手順については、サンプルリポジトリにまとめています。
今回の構成を実際に試すためのサンプルコードは、以下のGitHubリポジトリで公開しています。
このサンプルリポジトリでは、AWSやAuth0のCLI、Terraformを使って環境構築を自動化しています。
この記事を見て、試してみたい方がいらっしゃいましたら活用いただければ幸いです。
手順については、詳細をREADMEに記載していますので、そちらを参照してください。
このブログでは、設定の流れの概要のみを説明します。
設定の流れ（概要のみ）
それでは、サンプルリポジトリを使った設定の流れを概要レベルで見ていきましょう。
大まかには、以下のような流れになります。
1つ目の手順として、AWSのSSOとAuth0のTerraform用アプリケーションをCLI経由で設定します。
まず最初に、TerraformでAWSリソースを管理するための準備を行います。
AWS CLIでSSOログインを行い、Terraform用のクレデンシャルを取得します。
また、Auth0側でもTerraformを使うため、Management APIにアクセスできるMachine to Machine Applicationを作成します。
2つ目の手順として、Auth0側でEvent StreamをTerraform経由で生成します。
Terraformの実行に必要なシークレットは一つ目の手順で自動的に設定されるため、Terraformを実行するだけでEvent Streamが作成されます。
3つ目の手順として、AWS側でパートナーイベントソースの紐づけをCLIで行います。
この手順は、後述するハマりポイントでも触れますが、TerraformではできないためCLIスクリプトで実行します。
4つ目の手順として、Terraform経由でAWSの残りの構成（EventBus、SQS、DLQ、Lambda）を設定します。
パートナーイベントソースの紐づけが完了したら、EventBusのルール、SQS、DLQ、Lambda関数をTerraformで作成します。
ここでは、パートナーイベントソースから作成されたEventBusをデータソースとして参照し、ルールを設定します。
5つ目の手順として、デモアプリ用のAuth0アプリ作成とデモアプリのデプロイをCLIで行います。
最後に、デモアプリケーションをCloudflare Workersにデプロイし、Auth0でアプリケーションを登録します。
以上の手順で、Auth0からAWS EventBridge経由でデモアプリケーションにイベントが配信される環境が構築できます。
個人的にハマったポイント
ここからは、今回の構成を構築する際に、個人的にハマったポイントを共有します。
同じような構成を構築する際の参考になれば幸いです。
Auth0のEventBridge設定とAWSの紐づけ
今回の構成を構築する際に、最も理解に時間がかかったのが、Auth0とAWSの連携方法でした。
具体的に何が分からなかったかというと、Auth0のEvent Stream作成画面では、AWSアカウントIDとリージョンを入力するだけで、特にAPIキーやシークレットを設定する項目がないことです。
最初は「これだけでAWSとどう連携するのか？」が分からず、時間を結構消費してしまいました。
その答えは、AWSのパートナーイベントソースにありました。
実は、Auth0がEvent Streamを作成すると、AWS側に自動的にパートナーイベントソースが作成されるのです。
このパートナーイベントソースは、AWSのEventBridgeコンソールで確認でき、aws.partner/auth0.com/...のような名前で表示されます。
そして、このパートナーイベントソースを、AWS側でEventBusに関連付ける必要があります。
この関連付けを行って初めて、Auth0からのイベントがEventBusに配信されるようになるというわけです。
この仕組みを理解するのに、以下の記事がとても参考になりました。
ただ、記事の内容はLog Streamを使った方法となっているため、実際の連携方法は異なります。
今回セットアップがCLI経由のため、UIベースの手順だとこんな感じの雰囲気になるのかという参考程度にご覧ください。
パートナーイベントソースとTerraformの連携
もう一つハマったのが、パートナーイベントソースとTerraformの連携方法です。
これも最初は分からなかったのですが、パートナーイベントソースをEventBusに関連付ける操作は、Terraformでは実行できません。
これは、パートナーイベントソースがAWS外部（この場合はAuth0）によって作成されるため、Terraformで管理できないためです。
そのため、この関連付けは以下のいずれかの方法で手動で行う必要があります。
- AWSコンソールのUI上で手動で関連付ける
- AWS CLIを使ってスクリプトで実行する
今回のサンプルリポジトリでは、update-eventbus.shスクリプトを作成し、内部でCLIを用いて対応しています。
詳細は上記ファイルを見ていただきたいですが、紐づけの部分は以下のような形です。
#!/bin/bash
# パートナーイベントソースを取得
EVENT_SOURCE_NAME=$(aws events list-event-sources \
--profile "${AWS_PROFILE}" \
--region "${AWS_REGION}" \
--name-prefix "aws.partner/auth0.com/" \
--query "EventSources[?State=='PENDING'] | sort_by(@, &CreationTime) | [-1].Name" \
--output text)
# EventBusに関連付ける
aws events create-event-bus \
--profile "${AWS_PROFILE}" \
--region "${AWS_REGION}" \
--name "${EVENT_SOURCE_NAME}" \
--event-source-name "${EVENT_SOURCE_NAME}"
一方で、関連付けた後のEventBusは、Terraformのaws_cloudwatch_event_busデータソースで参照できます。
これにより、EventBusに対するルールやターゲット（SQSなど）の設定をTerraformで管理できるようになります。
例としては以下のような形です。
# パートナーイベントソースから作成されたEventBusを参照
data "aws_cloudwatch_event_bus" "auth0" {
name = "aws.partner/auth0.com/..."
}
# EventBusに対するルールを作成
resource "aws_cloudwatch_event_rule" "auth0_events" {
name = "auth0-user-events"
event_bus_name = data.aws_cloudwatch_event_bus.auth0.name
event_pattern = jsonencode({
source = ["aws.partner/auth0.com"]
})
}
dataソースに名前を設定するのは、update-eventbus.shで行っています。
なので、別途tfファイルに設定する必要はありませんが、手順としては存在することを覚えておいてください。
設定についてはサンプルリポジトリである程度自動化していますが、一つ注意点があります。
データソースで参照しているため、terraform destroyを実行してもパートナーイベントソースの登録は解除されません。
完全にクリーンアップするには、AWS CLIまたはコンソールで手動で削除する必要があることを覚えておいてください。
WebhookとEventBridge、どちらを選ぶか
さて、ここまでEventBridge方式について詳しく説明してきました。
それでは、前回のWebhook方式と今回のEventBridge方式、実際にはどちらを選ぶべきなのでしょうか。
この章では、それぞれの方式の特徴を比較しながら、選択の指針を示します。
基本的な推奨
まず結論から言うと、コストが許すならEventBridge（AWS連携）を推奨します。
ただし、これはあくまで一般論であって、環境や要件によっては、Webhookの方が適している場合もあります。
そこで、それぞれのメリット・デメリットを整理していこうと思います。
EventBridgeを推奨する理由
それでは、EventBridge方式のメリットを具体的に見ていきましょう。
まず一つ目のメリットは、セキュリティ面での優位性です。
Webhook方式では、トークン管理やリクエストの検証を自前で実装する必要があります。
前回の記事では、Bearerトークンを使った認証を実装しましたが、トークンのローテーションや漏洩時の対応など、セキュリティ面での考慮事項が多くなってしまいます。
これに対してEventBridge方式では、AWSのパートナーイベントソースという仕組みを使うことで、Auth0とAWSの間の連携はAWSのマネージドな仕組みで保護されます。
そのため、開発者が認証トークンを管理する必要がなく、セキュリティリスクを軽減できます。
二つ目のメリットは、リトライ設計のしやすさです。
EventBridge + SQS + Lambdaの構成では、AWSのマネージドサービスが提供するリトライ機能をそのまま活用できます。
SQSのvisibility timeout、maxReceiveCount、DLQなど、設定ファイルで簡単にリトライ戦略を調整できるのが魅力です。
一方、Webhook方式で同等の機能を実現しようとすると、キューイングの仕組みを自前で実装する必要があります。
そして三つ目のメリットが、拡張性です。
EventBridgeを使うことで、複数のターゲットにイベントを配信することが容易になります。
例えば、SQS + Lambdaだけでなく、SNSやStep Functionsなど、他のAWSサービスとも連携できます。
さらに、EventBridgeのフィルタリング機能を使うことで、特定のイベントだけを特定のターゲットに配信するといった柔軟な設計が可能です。
Webhookを選ぶケース
一方で、以下のような場合は、Webhook方式の方が適していることもあります。
まず一つ目が、AWSを使っていない環境です。
EventBridge方式は、AWSのサービスを前提としています。
そのため、GCPやAzure、オンプレミス環境で動作するアプリケーションに通知したい場合は、Webhookの方がシンプルに実装できます。
二つ目が、コストを最小限に抑えたい場合です。
Webhook方式は、受け取り側のサーバーがあれば追加のコストはほとんどかかりません。
一方、EventBridge方式では、EventBridge、SQS、Lambdaのそれぞれでコストが発生します。
特に、イベント数が多い場合は、EventBridgeの課金が無視できない金額になる可能性があります。
小規模なプロジェクトや、イベント数が少ない場合は、Webhookの方がコスト効率が良いでしょう。
そして三つ目が、シンプルさを優先したい場合です。
Webhook方式は、HTTPエンドポイントを用意するだけで実装できるため、学習コストが低く、シンプルです。
AWSの知識がないチームや、プロトタイプを素早く作りたい場合は、Webhookの方が適しています。
以上のように、それぞれの方式にはメリット・デメリットがあります。
プロジェクトの要件や環境に応じて、適切な方式を選択してください。
終わりに
それでは最後に、今回の記事の内容をまとめていきます。
まとめ
今回は、Auth0のEvent StreamとAWS EventBridgeを連携して、非同期かつリトライ可能な構成を実現する方法を紹介しました。
改めて、前回のWebhook版と比較して、今回の構成には以下のようなメリットがあります。
- 非同期処理：Auth0の処理をブロックせず、AWSのマネージドサービスでイベントを失わずに処理
- リトライ機構：SQSの標準機能で一時的な障害に対応
- DLQによる失敗イベントの再処理：長時間障害が発生しても、イベントを失わずに再処理可能
- セキュリティ：パートナーイベントソースによる安全な連携
一方で、イベント順序の担保や冪等性の確保など、考慮すべき点もあることをお伝えしました。
本番運用では、これらの点を踏まえた設計が必要になります。
今後の発展
最後に、今回の構成をさらに発展させるためのアイデアをいくつか紹介します。
まず、冪等性の担保についてです。
event_idをキーにして、既に処理済みかどうかをチェックする仕組みを実装することで、重複処理を防げます。
DynamoDBやRedisなどを使って、処理済みイベントのIDを記録しておくなどの方法が考えられます。
次に、他のイベント種別への拡張です。
今回はuser.updatedイベントのみを扱いましたが、Auth0のEvent StreamはユーザーやOrganizationに関わる様々なイベントをサポートしています。
EventBridgeのフィルタリング機能を使って、イベント種別ごとに異なるターゲットに配信することも可能です。
さらに、モニタリング・アラートの追加も検討する価値があります。
CloudWatch Metricsを使って、SQSのメッセージ数やDLQのメッセージ数を監視し、異常値を検知したらアラートを発報する仕組みを追加すると、運用の安心感が増します。
特に、DLQにメッセージが溜まり続けている場合は、連携先のアプリケーションに問題がある可能性が高いため、早期に検知できるようにしておくことが重要です。
また、イベントの順序が重要な場合は、標準キューではなくFIFOキューを使用することも検討できます。
ただし、DLQとの組み合わせでは順序保証が難しい点に注意が必要です。
以上となります、この記事を読んで気になった方は是非とも試していただければ幸いです。
そして、何か改善点や質問があれば、コメントで教えていただけると嬉しいです。
ここまで読んでいただき、ありがとうございました。
参考リンク
Auth0 Event Stream公式ドキュメント：
Auth0とAWS EventBridgeの連携：
Webhook版記事：
参考にした記事：