サイトアイコンmaita tomoya dev io

AWS EventBridge

DevOps/インフラ

AWS EventBridge

イベント駆動アーキテクチャとは

イベント駆動アーキテクチャ(EDA: Event-Driven Architecture)は、システムの状態変化(イベント)を契機として処理を実行するアーキテクチャパターン。サービス間の通信をイベントを介して行うことで、疎結合で拡張性の高いシステムを構築できる。

リクエスト駆動 vs イベント駆動

項目リクエスト駆動イベント駆動
通信方式同期(リクエスト/レスポンス)非同期(イベント発行/受信)
結合度密結合(呼び出し先を知っている)疎結合(発行者は受信者を知らない)
障害影響呼び出し先の障害が直接影響障害の影響が局所化
スケーラビリティ呼び出し先に依存独立してスケール可能
追加の処理呼び出し元の変更が必要新しいサブスクライバーを追加するだけ
graph TD subgraph "リクエスト駆動" A1[注文サービス] -->|API呼び出し| B1[在庫サービス] A1 -->|API呼び出し| C1[決済サービス] A1 -->|API呼び出し| D1[通知サービス] end subgraph "イベント駆動" A2[注文サービス] -->|注文イベント発行| E[EventBridge] E -->|ルール| B2[在庫サービス] E -->|ルール| C2[決済サービス] E -->|ルール| D2[通知サービス] end

Amazon EventBridgeとは

Amazon EventBridgeは、AWSが提供するサーバーレスのイベントバスサービス。AWSサービス、SaaSアプリケーション、独自アプリケーションからのイベントを受信し、ルールに基づいてターゲットにルーティングする。

旧名はCloudWatch Events。2019年にEventBridgeとしてリブランドされ、大幅に機能が拡張された。

EventBridgeの構成要素

構成要素説明
イベントバスイベントを受信するパイプライン
ルールイベントパターンに基づいてターゲットにルーティング
ターゲットイベントを受信して処理するAWSサービス
イベントパターンどのイベントをマッチさせるかの条件
スキーマレジストリイベントの構造を管理
Pipeソースからターゲットへのポイントツーポイント接続
Schedulerスケジュールベースのイベント発行

Rule(ルール)

ルールは、EventBridgeの中核機能。イベントパターンに一致するイベントをターゲットにルーティングする。

ルールの種類

種類説明ユースケース
イベントパターンルールイベントの内容に基づいてマッチ特定のイベントに反応する処理
スケジュールルール定期的にイベントを生成(※非推奨、Schedulerへ移行)定期バッチ処理

イベントパターンの書き方

基本構造

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
    "state": ["stopped", "terminated"]
  }
}

高度なフィルタリング

{
  "source": ["my-app.orders"],
  "detail-type": ["OrderCreated"],
  "detail": {
    "amount": [{ "numeric": [">=", 10000] }],
    "region": [{ "prefix": "ap-" }],
    "status": [{ "anything-but": ["cancelled"] }],
    "metadata": {
      "priority": [{ "exists": true }]
    }
  }
}
フィルタ演算子説明
完全一致値が完全に一致["value"]
prefix前方一致[{"prefix": "ap-"}]
suffix後方一致[{"suffix": ".json"}]
numeric数値比較[{"numeric": [">=", 100]}]
anything-but指定値以外[{"anything-but": ["test"]}]
existsフィールドの存在確認[{"exists": true}]
wildcardワイルドカード[{"wildcard": "order-*-premium"}]

ターゲットの種類

1つのルールに最大5つのターゲットを設定可能。

ターゲットユースケース
Lambdaイベント処理
Step Functionsワークフロー起動
SQSキューイング
SNS通知配信
Kinesis Data Streamsストリーミング
ECS タスクコンテナ処理
API GatewayHTTP API呼び出し
CloudWatch Logsログ記録
EventBridge(他アカウント/リージョン)クロスアカウント/リージョン
API Destinations外部HTTP API呼び出し

入力トランスフォーマー

イベントをターゲットに渡す前に形式を変換できる。

{
  "InputPathsMap": {
    "orderId": "$.detail.orderId",
    "amount": "$.detail.amount",
    "timestamp": "$.time"
  },
  "InputTemplate": "{\"message\": \"Order <orderId> created with amount <amount>\", \"time\": <timestamp>}"
}

Pipe(パイプ)

EventBridge Pipesは、ソースからターゲットへのポイントツーポイント統合を提供する。ソースからイベントを取得し、オプションでフィルタリング・エンリッチメントを行い、ターゲットに配信する。

Pipeの構成

graph LR A[ソース] --> B[フィルタリング] B --> C[エンリッチメント] C --> D[ターゲット] subgraph "オプション" B C end
ステージ必須説明
ソースはいイベントの取得元
フィルタリングいいえイベントパターンでフィルタ
エンリッチメントいいえLambda/Step Functions/API Gateway/API Destinationsでデータ補完
ターゲットはいイベントの配信先

サポートされるソース

ソース説明
SQSキューからのメッセージ
DynamoDB Streamsテーブルの変更イベント
Kinesis Data Streamsストリームデータ
Amazon MQメッセージブローカー
Apache Kafka (MSK)Kafkaトピック

Rule vs Pipe の使い分け

項目RulePipe
接続パターン1対多(ファンアウト)1対1(ポイントツーポイント)
ソースイベントバスに送信されたイベントSQS、DynamoDB Streams、Kinesis等
エンリッチメントなしLambda等で補完可能
ターゲット数最大5つ/ルール1つ
ユースケースイベントルーティングソースとターゲットの統合

Pipe の実装例

{
  "Name": "order-processing-pipe",
  "Source": "arn:aws:sqs:ap-northeast-1:123456789:order-queue",
  "SourceParameters": {
    "SqsQueueParameters": {
      "BatchSize": 10
    },
    "FilterCriteria": {
      "Filters": [
        {
          "Pattern": "{\"body\":{\"orderType\":[\"premium\"]}}"
        }
      ]
    }
  },
  "Enrichment": "arn:aws:lambda:ap-northeast-1:123456789:function:enrich-order",
  "Target": "arn:aws:states:ap-northeast-1:123456789:stateMachine:process-order",
  "TargetParameters": {
    "StepFunctionStateMachineParameters": {
      "InvocationType": "FIRE_AND_FORGET"
    }
  }
}

Scheduler(スケジューラー)

EventBridge Schedulerは、定期的またはワンタイムのタスク実行をスケジュールするサービス。従来のEventBridgeスケジュールルールの後継で、より高機能。

スケジュールの種類

種類説明
Rate式一定間隔rate(5 minutes)
Cron式細かい時刻指定cron(0 9 * * ? *) 毎日9時
ワンタイム1回だけ実行at(2026-04-01T09:00:00)

Cron式の形式

cron(分 時 日 月 曜日 年)
フィールド
0-590
0-239(UTC)
1-31*
1-12 or JAN-DEC*
曜日1-7 or SUN-SATMON-FRI
1970-2199*

Scheduler vs EventBridge スケジュールルール

項目Schedulerスケジュールルール(旧)
ワンタイムスケジュール対応非対応
タイムゾーン指定対応非対応(UTCのみ)
スケジュール数の制限100万300
リトライポリシー設定可能限定的
DLQ設定可能可能
推奨度推奨既存環境のみ

Scheduler の実装例

{
  "Name": "daily-report-schedule",
  "ScheduleExpression": "cron(0 0 * * ? *)",
  "ScheduleExpressionTimezone": "Asia/Tokyo",
  "FlexibleTimeWindow": {
    "Mode": "FLEXIBLE",
    "MaximumWindowInMinutes": 15
  },
  "Target": {
    "Arn": "arn:aws:lambda:ap-northeast-1:123456789:function:GenerateDailyReport",
    "RoleArn": "arn:aws:iam::123456789:role/scheduler-role",
    "RetryPolicy": {
      "MaximumRetryAttempts": 3,
      "MaximumEventAgeInSeconds": 3600
    },
    "DeadLetterConfig": {
      "Arn": "arn:aws:sqs:ap-northeast-1:123456789:scheduler-dlq"
    }
  }
}

イベントバス

イベントバスの種類

種類説明
デフォルトイベントバス各AWSアカウントに自動作成。AWSサービスのイベントはここに送信される
カスタムイベントバスアプリケーション独自のイベント用に作成
パートナーイベントバスSaaSパートナー(Datadog、Zendesk等)からのイベント受信用

カスタムイベントの発行

import {
  EventBridgeClient,
  PutEventsCommand,
} from '@aws-sdk/client-eventbridge';

const client = new EventBridgeClient({ region: 'ap-northeast-1' });

await client.send(
  new PutEventsCommand({
    Entries: [
      {
        EventBusName: 'my-app-events',
        Source: 'my-app.orders',
        DetailType: 'OrderCreated',
        Detail: JSON.stringify({
          orderId: 'ORD-12345',
          customerId: 'CUST-001',
          amount: 15000,
          items: [
            { productId: 'PROD-A', quantity: 2 },
            { productId: 'PROD-B', quantity: 1 },
          ],
        }),
      },
    ],
  })
);

イベントの構造

{
  "version": "0",
  "id": "12345678-1234-1234-1234-123456789012",
  "source": "my-app.orders",
  "account": "123456789012",
  "time": "2026-04-02T10:00:00Z",
  "region": "ap-northeast-1",
  "detail-type": "OrderCreated",
  "detail": {
    "orderId": "ORD-12345",
    "customerId": "CUST-001",
    "amount": 15000
  }
}

versionidaccounttimeregionはEventBridgeが自動的に付与する。開発者が設定するのはsourcedetail-typedetail


多段構成(マルチステージ)

複数のEventBridgeルールやバスを組み合わせて、段階的なイベント処理パイプラインを構築するパターン。

マルチアカウント・マルチリージョン構成

graph LR subgraph "アカウントA(東京)" A1[アプリ] --> B1[イベントバスA] end subgraph "アカウントB(東京)" B1 -->|クロスアカウント| B2[イベントバスB] B2 --> C1[Lambda: 処理] B2 --> C2[SQS: キューイング] end subgraph "アカウントA(大阪)" B1 -->|クロスリージョン| B3[イベントバスA-DR] B3 --> D1[Lambda: DR処理] end

イベントチェーンパターン

イベントA → Lambda 1 → EventBridge → イベントB → Lambda 2 → EventBridge → イベントC → Lambda 3

各Lambdaが処理結果をイベントとしてEventBridgeに発行し、次の処理がそれをトリガーとして動く。

アーカイブとリプレイ

EventBridgeはイベントをアーカイブし、後で再生(リプレイ)できる。

機能説明
アーカイブ特定のイベントパターンに合致するイベントを保存
リプレイアーカイブしたイベントを指定時間範囲で再生
保持期間無制限または日数指定

障害復旧やデバッグに非常に有用。本番環境のイベントをテスト環境にリプレイすることも可能。


API Destinations

外部のHTTP APIをEventBridgeのターゲットとして呼び出す機能。

サポートされる認証方式

方式説明
Basic認証ユーザー名/パスワード
OAuthクライアントクレデンシャル
API KeyヘッダーにAPIキーを付与

設定例

{
  "Name": "slack-webhook",
  "HttpMethod": "POST",
  "InvocationEndpoint": "https://hooks.slack.com/services/xxx/yyy/zzz",
  "InvocationRateLimitPerSecond": 10,
  "ConnectionArn": "arn:aws:events:ap-northeast-1:123456789:connection/slack-connection"
}

スキーマレジストリ

EventBridgeスキーマレジストリは、イベントの構造(スキーマ)を管理・検索できる機能。

機能

  • スキーマ検出: イベントバスに流れるイベントから自動的にスキーマを生成
  • コード生成: スキーマからイベントの型定義(TypeScript、Python、Java等)を自動生成
  • バージョン管理: スキーマの変更履歴を追跡

イベント駆動アーキテクチャにおいて、イベントの「契約」を明確にするために重要。


料金体系

EventBridge ルール

項目料金
カスタムイベント$1.00 / 100万イベント
AWSサービスイベント無料
パートナーイベント$1.00 / 100万イベント
クロスアカウント/リージョン$1.00 / 100万イベント

EventBridge Pipes

料金 = リクエスト料金 + 実行時間料金
リクエスト料金 = $0.40 / 100万リクエスト
実行時間料金(64KB単位) = $0.000012 / GB秒

EventBridge Scheduler

料金 = $1.00 / 100万スケジュール呼び出し
無料枠 = 月1,400万呼び出し

ベストプラクティス

イベント設計

  • イベント名はsourcedetail-typeで一意に識別できるように設計する
  • sourceは逆ドメイン表記を推奨(例: com.mycompany.orders
  • イベントには必要十分な情報を含める(過多でも過少でもなく)
  • スキーマレジストリを活用してイベントの構造を管理する
  • イベントのバージョニング戦略を事前に決める

信頼性

  • DLQを設定して配信失敗を捕捉する
  • アーカイブを有効にして障害復旧に備える
  • リトライポリシーを適切に設定する
  • CloudWatchメトリクスで配信失敗を監視する(FailedInvocations

セキュリティ

  • イベントバスにリソースポリシーを設定して、許可されたソースのみ受信する
  • IAMポリシーでevents:PutEventsを最小限のイベントバス・ソースに制限する
  • 機密情報はイベントに含めず、参照IDのみを含める

コスト

  • イベントパターンのフィルタリングを活用して不要なターゲット呼び出しを削減する
  • Pipesのフィルタリング機能で不要な処理を除外する
  • AWSサービスのイベント(EC2状態変更など)は無料なので積極的に活用する

IaC での定義

Terraform

resource "aws_cloudwatch_event_bus" "orders" {
  name = "orders-event-bus"
}

resource "aws_cloudwatch_event_rule" "order_created" {
  name           = "order-created-rule"
  event_bus_name = aws_cloudwatch_event_bus.orders.name

  event_pattern = jsonencode({
    source      = ["my-app.orders"]
    detail-type = ["OrderCreated"]
    detail = {
      amount = [{ numeric = [">=", 10000] }]
    }
  })
}

resource "aws_cloudwatch_event_target" "process_order" {
  rule           = aws_cloudwatch_event_rule.order_created.name
  event_bus_name = aws_cloudwatch_event_bus.orders.name
  arn            = aws_lambda_function.process_order.arn
}

resource "aws_pipes_pipe" "sqs_to_sfn" {
  name     = "sqs-to-step-functions"
  role_arn = aws_iam_role.pipe_role.arn
  source   = aws_sqs_queue.orders.arn
  target   = aws_sfn_state_machine.process.arn

  source_parameters {
    sqs_queue_parameters {
      batch_size = 10
    }
    filter_criteria {
      filter {
        pattern = jsonencode({
          body = {
            orderType = ["premium"]
          }
        })
      }
    }
  }
}

resource "aws_scheduler_schedule" "daily_report" {
  name       = "daily-report"

  flexible_time_window {
    mode                      = "FLEXIBLE"
    maximum_window_in_minutes = 15
  }

  schedule_expression          = "cron(0 0 * * ? *)"
  schedule_expression_timezone = "Asia/Tokyo"

  target {
    arn      = aws_lambda_function.report.arn
    role_arn = aws_iam_role.scheduler_role.arn

    retry_policy {
      maximum_retry_attempts       = 3
      maximum_event_age_in_seconds = 3600
    }

    dead_letter_config {
      arn = aws_sqs_queue.scheduler_dlq.arn
    }
  }
}

参考リンク