概要
Amazon EventBridge は、イベントを使ってアプリケーションのコンポーネント同士をつなぐサーバーレスサービスです。「S3 バケットにファイルが置かれた」「EC2 インスタンスが停止した」といった出来事（イベント）を受け取り、条件に合うものだけを Lambda 関数や SQS キューなどの処理先に届けます。
システムを作っていると、「ファイルが届いたら変換処理を動かしたい」「毎朝決まった時刻に集計を走らせたい」という要件がよく出てきます。処理を呼び出す側と呼び出される側を直接つなぐと、つなぎ先が増えるたびに双方の改修が必要になります。EventBridge を間に置くと、イベントを出す側は「何が起きたか」を送るだけで済み、誰がそれを受け取るかはルールで後から決められます。また、EventBridge Scheduler を使えば、cron 式や rate 式で処理を定期的に起動することもできます。
本記事では、イベント駆動の考え方と EventBridge の基本要素（イベントバス・ルール・イベントパターン・ターゲット）、EventBridge Scheduler を理解し、S3 のオブジェクト作成イベントとスケジュールの 2 つの方法で同じ Lambda 関数を起動するところまで体験します。
クラウドおさる「何かが起きたら動く」と「時間が来たら動く」、この 2 つのきっかけを 1 本の Lambda 関数で確かめるのでござるな。猿山の見張り台の鐘と、毎朝の点呼の太鼓を両方鳴らしてみる気分でござる。
この記事のメリット
- イベント駆動の考え方と、EventBridge が間に入ることのメリットを理解できる
- イベントバス（デフォルト・カスタム）、ルール、イベントパターン、ターゲットの関係を把握できる
- EventBridge Scheduler の 3 種類のスケジュール（rate・cron・1 回限り）の違いを理解できる
- SNS・SQS・EventBridge の使い分けの観点を整理できる
- S3 のイベントで Lambda 関数を起動し、CloudWatch Logs でイベントの中身を確認する手順を体験できる
- EventBridge Scheduler で Lambda 関数を定期実行し、スケジュールを無効化する手順を体験できる
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
イベント駆動とは
クラウドおさるとひさん、EventBridge は「イベント駆動」のサービスと聞いたでござる。そもそもイベント駆動とは何でござるか？
土肥「何かが起きたこと」をきっかけに処理が動く設計のことだよ。たとえば「S3 にファイルがアップロードされた」という出来事がイベントで、それを受けてサムネイル作成の処理が動く、みたいな流れだね。
クラウドおさるLambda の記事でも S3 から Lambda を動かす話があったでござる。わざわざ EventBridge を挟むのはなぜでござるか？
土肥いいところに気づいたね！ 送る側と受け取る側を直接つなぐと、受け取る処理が増えるたびに送る側の設定も変えないといけないんだ。EventBridge を間に置くと、送る側は「こんなことが起きたよ」とイベントを投げるだけ。誰が受け取るかは EventBridge のルールで後から足したり外したりできるんだよ。こういう「ゆるい結合」にできるのが EventBridge のいちばんの価値かな。
クラウドおさるなるほど、猿山の見張り台は「客が来た」と鐘を鳴らすだけで、門番が動くか台所が動くかは各自が決めるのと同じでござるな！ 見張りが一匹ずつ呼びに走らずに済むでござる。
土肥そうそう、その通り！ EventBridge には大きく 3 つの使い方があるから、先に全体を見ておこうか。
| 機能 | 役割 |
|---|---|
| イベントバス | 複数のソースからイベントを受け取り、ルールに合うものを 0 個以上のターゲットに届けるルーター |
| EventBridge Pipes | 1 つのソースから 1 つのターゲットへ、イベントを加工しながら届ける（ポイントツーポイント） |
| EventBridge Scheduler | cron 式・rate 式・1 回限りの日時指定で、ターゲットを時間どおりに呼び出すサーバーレスのスケジューラ |
土肥この記事ではイベントバスと Scheduler を触るよ。Pipes は「1 対 1 でつなぐ仕組みもある」と名前だけ覚えておけば大丈夫。
イベントバス（デフォルト・カスタム）
クラウドおさるイベントバスとは、イベントが流れてくる通り道のようなものでござるか？
土肥そうだね。イベントバスはイベントを受け取って、ルールに照らしてターゲットに振り分けるルーターなんだ。種類は主にこの 2 つだよ。
| 種類 | 説明 |
|---|---|
| デフォルトイベントバス | すべての AWS アカウントに自動で作られているイベントバス。AWS のサービス（S3、EC2 など）のイベントはここに届く |
| カスタムイベントバス | 自分で作るイベントバス。自前のアプリケーションのイベントを分けて扱いたいときに使う |
クラウドおさる自分で作らなくても、最初から 1 本あるのでござるな。どちらを使えばよいでござる？
土肥AWS サービスのイベントを拾うならデフォルトイベントバスを使うよ。今回の S3 のイベントもデフォルトに届くんだ。自分たちのアプリケーションが出すイベントを扱う新しい仕組みを作るなら、AWS はカスタムイベントバスから始めることを勧めているよ。
クラウドおさるAWS からの知らせは最初からある共用の掲示板に、自分たちの知らせは専用の掲示板に、と分けるのでござるな。
ルールとイベントパターン
クラウドおさるイベントバスに届いたイベントは、どうやって振り分けられるのでござるか？
土肥そこで使うのがルールだよ。ルールは「どのイベントを、どのターゲットに送るか」を決めるもので、どのイベントかを決める条件をイベントパターンっていうんだ。まずイベントの中身を見てみようか。S3 でオブジェクトが作成されると、こんな JSON がイベントバスに届くよ。
{
"version": "0",
"id": "17793124-05d4-b198-2fde-7ededc63b103",
"detail-type": "Object Created",
"source": "aws.s3",
"account": "111122223333",
"time": "2021-11-12T00:00:00Z",
"region": "ca-central-1",
"resources": ["arn:aws:s3:::amzn-s3-demo-bucket1"],
"detail": {
"version": "0",
"bucket": {
"name": "amzn-s3-demo-bucket1"
},
"object": {
"key": "example-key",
"size": 5,
"etag": "b1946ac92492d2347c6235b4d2611184"
},
"reason": "PutObject"
}
}source がイベントを出したサービス、detail-type がイベントの種類、detail にバケット名やオブジェクトのキーといった詳しい中身が入っているよ。このイベントだけを拾うイベントパターンは、こう書くんだ。
{
"source": ["aws.s3"],
"detail-type": ["Object Created"],
"detail": {
"bucket": {
"name": ["amzn-s3-demo-bucket1"]
}
}
}イベントと同じ形をしているでござるな。値が [ ] で囲まれているのはなぜでござる？
土肥よく見てるね！ イベントパターンには決まりがいくつかあるんだ。
- イベントパターンは、照合したいイベントと同じ構造で書く
- パターンの値は配列で書く（配列の中のどれかに一致すればよい）
- パターンに書いていないフィールドは照合の対象外になる
土肥だからこのパターンは「S3 の、Object Created で、バケット名がこれ」のイベントだけに一致して、オブジェクトのキーやサイズは何でもいい、という意味になるよ。
クラウドおさる書いた項目だけで絞り込むのでござるな！ 猿山の見張りに「南の門から来た、バナナを持った客」とだけ伝えれば、毛の色は問わぬのと同じでござる。
ターゲット
クラウドおさるルールに一致したイベントは、どこへ届けられるのでござるか？
土肥それがターゲットだよ。イベントパターンに一致したときに、EventBridge がイベントを送る先のことなんだ。Lambda 関数、SQS キュー、SNS トピック、Step Functions のステートマシン、CloudWatch Logs のロググループ、別のイベントバスなど、たくさんの種類を指定できるよ。
クラウドおさる1 つのルールで、送り先を何か所も指定できるのでござるか？
土肥できるよ。1 つのルールにターゲットは最大 5 つまで定義できて、一致したイベントは並行してそれぞれに送られるんだ。
クラウドおさるEventBridge が勝手に Lambda を呼んでよいのでござるか？ 猿山なら、門番の許しなく倉庫は開けられぬでござる。
土肥鋭いね！ EventBridge が Lambda 関数を呼び出すには、許可が必要なんだ。方法は 2 つあって、ルールに lambda:InvokeFunction を許可した実行ロール（IAM ロール）を付けるか、関数のリソースベースのポリシーで EventBridge（events.amazonaws.com）からの呼び出しを許可するかだよ。コンソールでルールを作ると、実行ロールが自動で作られる形が既定になっているんだ。どちらにしても、勝手に呼べるわけじゃないから安心してね。
EventBridge Scheduler（cron・rate・1 回限り）
クラウドおさる「毎朝 9 時に動かす」のように、時間で処理を起動したいときはどうするのでござるか？
土肥そのときは EventBridge Scheduler を使うよ。スケジュールを作って、時間が来たらターゲットを呼び出してもらうサーバーレスのスケジューラなんだ。スケジュールの決め方は 3 種類あるよ。
| 種類 | 書式 | 使いどころ |
|---|---|---|
| レートベース | rate(5 minutes) のように「値 + 単位（minutes / hours / days）」 | 5 分ごと、2 時間ごとのように一定間隔で繰り返す |
| cron ベース | cron(分 時 日 月 曜日 年) | 毎週月曜 9 時、毎月最終金曜など、日時を細かく指定して繰り返す |
| 1 回限り | at(yyyy-mm-ddThh:mm:ss) | 指定した日時に 1 回だけ呼び出す |
クラウドおさる毎朝 9 時と言っても、どこの 9 時でござる？ 雲の上と地上で時刻が違ったら困るでござる。
土肥いい質問だね！ cron ベースと 1 回限りのスケジュールはタイムゾーンを指定できるから、Asia/Tokyo を選べば日本時間の 9 時に動くよ。夏時間がある地域でも自動で合わせてくれるんだ。それと、呼び出しの精度は 60 秒単位だから、秒単位でぴったりの起動を期待するものではないよ。
クラウドおさるほかに覚えておく設定はあるでござるか？
土肥よく使うのはこのあたりかな。
| 設定 | 説明 |
|---|---|
| 柔軟な時間枠 | 指定した時間枠の中で呼び出しのタイミングを分散させる。「オフ」なら予定どおりに呼び出す |
| スケジュールの状態 | 有効 / 無効を切り替えられる。無効にすると、削除せずに呼び出しだけを止められる |
| スケジュール完了後のアクション | 「削除」を選ぶと、1 回限りのスケジュールは呼び出し後に、繰り返しのスケジュールは最後の予定呼び出し後に自動で削除される |
| 再試行ポリシーとデッドレターキュー | ターゲットがエラーを返したときの再試行回数や、最終的に失敗したイベントの退避先（SQS キュー）を決める |
| 実行ロール | Scheduler がターゲットを呼び出すための IAM ロール。コンソールから新しく作らせることができる |
クラウドおさる1 回限りのスケジュールは、終わったら片付けるように設定できるのでござるな。
土肥そう。1 回限りのスケジュールは、実行が終わってもクォータ（作成できる数の上限）に数えられたままになるから、削除しておくことが推奨されているんだ。それから、EventBridge のルールにも「スケジュールで動くルール」があるけど、これはレガシー機能で、今はスケジュールには Scheduler を使うことが推奨されているよ。
SNS・SQS との使い分け
クラウドおさる「イベントを届ける」だけなら、SNS や SQS でもできそうでござる。どう使い分けるのでござるか？
土肥試験でもよく聞かれるところだね。AWS の判断ガイドの観点でまとめるとこうなるよ。
| 観点 | Amazon SQS | Amazon SNS | Amazon EventBridge |
|---|---|---|---|
| 届け方 | 受け取る側が取りに行く（プル型） | 購読者に押し出す（プッシュ型） | ルールに一致したイベントをターゲットに送る |
| メッセージの保持 | キューに保持する（最大 14 日） | 保持しない | 保持しない |
| 絞り込み | 基本的なもの | サブスクリプションのフィルターポリシー | イベントパターンによる複雑なパターンマッチング |
| 向いている用途 | 処理のバッファリング、非同期処理、送り手と受け手を別々にスケールさせる | 多数の宛先へのファンアウト通知、モバイルプッシュ | AWS サービスや SaaS のイベントを条件で振り分けるイベント駆動の構成 |
クラウドおさる溜めておいて順に片付けたいなら SQS、みんなに一斉に知らせたいなら SNS、出来事の中身を見て行き先を振り分けたいなら EventBridge、でござるな！
土肥その覚え方でばっちりだよ。実際には組み合わせて使うことも多くて、EventBridge のターゲットに SQS や SNS を指定する構成もよくあるんだ。
実践
ここでは、受け取ったイベントをログに出すだけの Lambda 関数を作り、S3 のオブジェクト作成イベントと EventBridge Scheduler の 2 つの方法でその関数を起動します。起動されるたびに Lambda 関数が受け取ったイベントの中身を CloudWatch Logs で確認します。
Lambda 関数の作成やコードの編集に慣れていない場合は「AWS Lambda で関数を作成しイベント駆動で実行する」、S3 バケットの操作は「Amazon S3 でバケットを作成しオブジェクトを管理する」、CloudWatch の基本は「Amazon CloudWatch でメトリクスとアラームを設定する」もあわせて参照してください。
前提条件
- リージョン:
ap-northeast-1（東京） - AWS マネジメントコンソールにログイン済み
- IAM ユーザー（またはロール）に Lambda、S3、EventBridge、EventBridge Scheduler、IAM ロールの作成、CloudWatch Logs の操作権限があること
- 事前に作成しておくリソースはありません
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| Lambda 関数 | eventbridge-handson-logger | 受け取ったイベントをログに出力する関数 |
| IAM ロール | （Lambda 関数の作成時に自動作成） | Lambda 関数の実行ロール |
| S3 バケット | eventbridge-handson-<アカウントID> | オブジェクト作成イベントの発生元 |
| EventBridge ルール | s3-object-created-to-lambda | S3 のオブジェクト作成イベントで Lambda 関数を起動するルール |
| IAM ロール | （ルールの作成時に自動作成） | EventBridge のルールが Lambda 関数を呼び出すための実行ロール |
| EventBridge Scheduler スケジュール | eventbridge-handson-rate | Lambda 関数を一定間隔で起動するスケジュール |
| IAM ロール | （スケジュールの作成時に自動作成） | Scheduler が Lambda 関数を呼び出すための実行ロール |
イベントをログに出す Lambda 関数を作成する
- AWS マネジメントコンソールにログインし、リージョンが
ap-northeast-1（東京）であることを確認します - 上部の検索バーに
Lambdaと入力し、表示された「Lambda」を選択します - 左側ナビゲーションの「関数」を選択し、「関数の作成」をクリックします
- 「一から作成」が選択されていることを確認し、以下を入力します
- 関数名:
eventbridge-handson-logger - ランタイム:
Python 3.13 - 「その他の設定」にあるアーキテクチャ（
x86_64）と実行ロール（基本的な Lambda アクセス許可で新しいロールを作成）はデフォルトのままにし、「関数の作成」をクリックします - 「コード」タブのエディタで
lambda_function.pyの内容を以下に書き換えます
import json
def lambda_handler(event, context):
# 受け取ったイベントをそのままログに出す
print(json.dumps(event, ensure_ascii=False))
return {"status": "ok"}- 「Deploy」をクリックし、関数が更新されたことを示すメッセージが表示されることを確認します
S3 バケットで EventBridge への通知をオンにする
- 上部の検索バーに
S3と入力し、表示された「S3」を選択します - 左側ナビゲーションの「汎用バケット」を選択し、「バケットを作成」をクリックします
- バケット名に
eventbridge-handson-<アカウントID>（<アカウントID>は右上のアカウントメニューで確認できる 12 桁の数字）を入力します - その他の項目はデフォルトのままにし、ページ下部の「バケットを作成」をクリックします
- バケット一覧から
eventbridge-handson-<アカウントID>を選択します - 「プロパティ」タブを選択し、「イベント通知」セクションまでスクロールします
- 「Amazon EventBridge」サブセクションの「編集」をクリックします
- 「このバケット内のすべてのイベントについて Amazon EventBridge に通知を送信する」で「オン」を選択し、「変更の保存」をクリックします
- 「プロパティ」タブの「Amazon EventBridge」サブセクションで、通知がオンになっていることを確認します
EventBridge への通知をオンにしてから実際に反映されるまで、約 5 分かかります。次のルール作成を進めている間に反映されます。
オブジェクト作成イベントのルールを作成する
- 上部の検索バーに
EventBridgeと入力し、表示された「Amazon EventBridge」を選択します - 左側ナビゲーションの「イベントバス」を選択し、「デフォルトのイベントバス」の
defaultをクリックします - 「ルール」タブで「ルールを作成」をクリックします
- 画面上部の「ビルダーモード」は「アドバンストビルダー」（ステップバイステップのルール設定）を選択します。既定の「強化ビルダー」はドラッグアンドドロップで組み立てるビジュアルビルダーで、以降の手順の画面とは異なります
- 「ルールの詳細を定義」で以下を設定し、「次へ」をクリックします
- 名前:
s3-object-created-to-lambda - イベントバス:
default（「選択したイベントバスでルールを有効にする」はオンのまま） - 「イベントパターンを構築」で以下を設定します
- イベントソース:
AWS イベントまたは EventBridge パートナーイベント - 作成のメソッド:
パターンフォームを使用する - イベントソース:
AWS のサービス - AWS のサービス:
S3 (Simple Storage Service) - イベントタイプ:
Amazon S3 イベント通知 - 「イベントタイプの仕様 1」で「特定のイベント」を選択し、
Object Createdを選択 - 「イベントタイプの仕様 2」で「特定のバケット (名前別)」を選択し、
eventbridge-handson-<アカウントID>を入力 - 画面右側の「イベントパターン」に、
sourceがaws.s3、detail-typeがObject Created、detail.bucket.nameがバケット名になったパターンが表示されることを確認します
- 「次へ」をクリックします
- 「ターゲットを選択」で以下を設定します
- ターゲットタイプ:
AWS のサービス - ターゲットを選択:
Lambda 関数 - 関数:
eventbridge-handson-logger - 許可: 「実行ロールを使用 (推奨)」のチェックを入れたまま、実行ロールは「デフォルトロールを作成」を選択
- 「次へ」をクリックし、「タグを設定」はデフォルトのまま「次へ」をクリックします
- 「レビューと作成」で設定内容を確認し、ルールを作成します
- ルールの詳細画面が開き、
s3-object-created-to-lambdaのステータスが「有効」になっていることを確認します
コンソールからターゲットを追加すると、実行ロール（Amazon_EventBridge_Invoke_Lambda_<数字> という名前の IAM ロール）が自動で作られ、EventBridge はそのロールを使って関数を呼び出します。そのため、この手順では Lambda 関数側のリソースベースのポリシーを自分で編集する必要はありません。
オブジェクトをアップロードしてイベントを確認する
- S3 コンソールに戻り、
eventbridge-handson-<アカウントID>の「オブジェクト」タブを開きます - 「アップロード」をクリックし、「ファイルを追加」から手元の小さなテキストファイル（例:
hello.txt）を選択して「アップロード」をクリックします - Lambda コンソールで
eventbridge-handson-loggerを開き、「モニタリング」タブを選択します - 「CloudWatch Logs を表示」をクリックすると、CloudWatch コンソールでロググループ
/aws/lambda/eventbridge-handson-loggerが開きます - 「ログストリーム」から最新のログストリームを選択します
STARTとENDの間の行を展開すると、Lambda 関数が出力したイベントの JSON が記録されていることを確認できます。"source": "aws.s3"、"detail-type": "Object Created"、detailの中にバケット名とオブジェクトのキー（hello.txt）、"reason": "PutObject"が含まれています
ログが見当たらない場合は、S3 の EventBridge 通知が反映される前にアップロードした可能性があります。数分待ってから別のファイルをアップロードし直してください。また、ログが表示されるまで数分かかることがあります。
クラウドおさるLambda 関数のコードには S3 のことを何も書いていないのに、バケット名もファイル名もちゃんと届いたでござる。S3 は「置かれた」と知らせただけで、誰に渡すかはルールが決めたのでござるな。
EventBridge Scheduler で Lambda 関数を定期実行する
- EventBridge コンソールの左側ナビゲーションで「Scheduler」の「スケジュール」を選択し、「スケジュールを作成」をクリックします
- 「スケジュールの名前と説明」で以下を設定します
- スケジュール名:
eventbridge-handson-rate - スケジュールグループ:
default - 「スケジュールのパターン」で以下を設定します
- 頻度:
定期的なスケジュール - タイムゾーン: デフォルトのまま
- スケジュールの種類:
rate ベースのスケジュール - rate 式: 値
1、単位minutes（単位の既定値はhoursなので変更します） - フレックスタイムウィンドウ:
オフ - 「時間枠」はデフォルト（開始日時・終了日時なし）のままにします
- 「次へ」をクリックします
- 「ターゲットの選択」で「テンプレート化されたターゲット」を選択したまま、タイルの「AWS Lambda」の「Invoke」を選択します
- 「Invoke」セクションで以下を設定します
- Lambda 関数:
eventbridge-handson-logger - ペイロード:
{"message": "hello from EventBridge Scheduler"}
- 「次へ」をクリックします
- 「設定 – オプション」で以下を確認・設定します
- スケジュールの状態: 「有効化」がオン
- スケジュール完了後のアクション:
NONE - 再試行ポリシーとデッドレターキュー (DLQ): デフォルトのまま
- アクセス許可:
このスケジュールの新しいロールを作成 - 「次へ」をクリックし、内容を確認して「スケジュールを作成」をクリックします
- スケジュールの詳細画面（または「スケジュール」の一覧）で、
eventbridge-handson-rateのステータスが「有効」になっていることを確認します
スケジュールからの起動をログで確認する
- 数分待ってから、CloudWatch コンソールでロググループ
/aws/lambda/eventbridge-handson-loggerを開き、最新のログストリームを選択します - 1 分ごとの呼び出しで、
{"message": "hello from EventBridge Scheduler"}が記録されていることを確認します。S3 から起動したときとは違い、Scheduler で指定したペイロードがそのままイベントとして関数に渡されていることがわかります
スケジュールを無効化する
- EventBridge コンソールの「Scheduler」→「スケジュール」で、
eventbridge-handson-rateの行のチェックボックスを選択します - 一覧上部の「無効化」をクリックし、確認画面で「無効化」をクリックします
eventbridge-handson-rateのステータスが「無効」になったことを確認します
- 数分待ってから CloudWatch Logs を確認し、新しいログが増えていないことを確認します
クラウドおさるrate のスケジュールは、止めない限り 1 分ごとに Lambda 関数を呼び続けるのでござる。確認が済んだら無効化を忘れずに。猿山でも点呼の太鼓を止め忘れて、夜中まで叩き続けた若猿がいたでござる。
まとめ
- イベント駆動は「何かが起きたこと」をきっかけに処理を動かす設計で、EventBridge を間に置くと送る側と受け取る側をゆるく結合できる
- イベントバスはイベントを受け取ってルールで振り分けるルーターで、AWS サービスのイベントはデフォルトイベントバスに届く。自前のアプリケーションのイベントにはカスタムイベントバスを使う
- ルールはイベントパターンで対象のイベントを絞り込み、一致したイベントをターゲット（1 ルールあたり最大 5 つ）に送る。イベントパターンはイベントと同じ構造で書き、値は配列で書き、書いていないフィールドは照合されない
- EventBridge Scheduler は rate・cron・1 回限りの 3 種類でターゲットを呼び出す。スケジュールで動くルールはレガシー機能で、スケジュールには Scheduler が推奨される
- EventBridge Pipes は 1 つのソースから 1 つのターゲットへつなぐ仕組み
- 溜めて順に処理するなら SQS、一斉に知らせるなら SNS、イベントの中身で振り分けるなら EventBridge
- S3 で EventBridge への通知をオンにすると、オブジェクト作成などのイベントがデフォルトイベントバスに送られ、ルールで Lambda 関数を起動できる
参照先
- Amazon EventBridge とは
- Amazon EventBridge イベントバス (デフォルトと Classic)
- Amazon EventBridge のルール
- Amazon EventBridge のイベントパターン
- Amazon EventBridge のイベントバスターゲット
- Amazon EventBridge のリソースベースのポリシーを使用する
- Amazon EventBridge のターゲットにイベントを送信するための IAM ロール
- 拡張ビルダーを使用したルールの作成
- チュートリアル: Amazon EventBridge を使用してイベントが発生したときに E メールを送信する
- チュートリアル: AWS Lambda 関数をスケジュールする
- EventBridge の使用
- Amazon EventBridge を有効にします
- EventBridge イベントメッセージの構造
- Amazon EventBridge スケジューラとは
- EventBridge スケジューラのスケジュールタイプ
- EventBridge スケジューラの開始方法
- EventBridge スケジューラでのスケジュール状態の変更
- スケジュールに従って Lambda 関数を呼び出す
- Lambda 関数へのアクセス権を AWS のサービスに付与する
- Lambda 関数ログを CloudWatch Logs に送信する
- Lambda 関数の CloudWatch Logs を表示する
- Amazon SQS、Amazon SNS、または Amazon EventBridge?
