Amazon EventBridge 完全ガイド 2026

初心者から実務者向けの包括的解説

Amazon EventBridge は、AWS サービス・SaaS アプリケーション・カスタムアプリからのイベントを受信し、パターンマッチングルールで適切なターゲットにルーティングする 「サーバーレスイベントバス」 です。2019 年に CloudWatch Events から進化した本サービスは、イベントスキーマレジストリ・アーカイブ・Pipes・スケジューラを含む包括的なイベント管理プラットフォームとなりました。本ドキュメントは、EventBridge の概念・アーキテクチャ・ユースケース・実装ベストプラクティスを体系的に解説する包括的ガイドです。

ドキュメントの目的

本ガイドは以下を対象としています。

• 初心者向け： EventBridge とは何か、なぜ必要かを学びたい方
• 開発者向け： イベント駆動アーキテクチャを実装したい方
• SRE / インフラ向け： マルチアカウント・マルチリージョンのイベント管理を行いたい方
• 意思決定者向け： SNS / SQS / Kafka との比較・技術選定判断

2026 年の EventBridge エコシステム

• EventBridge Pipes 拡張： 2025 年にベータから GA へ、エンリッチメント・フィルタリング・変換が一つのパイプで実現
• EventBridge Scheduler 強化： タイムゾーン・リトライポリシー・柔軟な時間指定に対応
• Event Source Mapping for Lambda： Lambda から直接 EventBridge をポーリング可能に
• AI-driven event routing： 機械学習による自動ルーティング最適化
• Schema Registry 拡張： OpenAPI / AsyncAPI / Protocol Buffers サポート
• クロスアカウント DLQ： セントラル管理のデッドレターキューで監視強化

定義

Amazon EventBridge 公式定義：

「AWS のサービス、SaaS アプリケーション、カスタムアプリケーションからのリアルタイムイベントを、ターゲットアプリケーションに自動的にルーティングする」

参照：What is Amazon EventBridge

目次

1. 概要
2. EventBridge が解決する課題
3. 主な特徴
4. アーキテクチャと基本概念
5. Event Bus 種別
6. イベント構造と形式
7. イベントパターンマッチング
8. Rule と Target
9. EventBridge Pipes
10. EventBridge Scheduler
11. Schema Registry
12. 入力変換と入力トランスフォーマー
13. DLQ と再試行ポリシー
14. ターゲット一覧と統合
15. API Destinations と外部連携
16. 主要ユースケース
17. セキュリティと IAM
18. CloudWatch メトリクスと監視
19. 他の類似ツールとの比較
20. クライアント・SDK・IaC
21. ベストプラクティス
22. トラブルシューティング
23. 2025-2026 最新動向
24. 学習リソース
25. 実装例・活用シーン
26. 導入ロードマップ
27. 実装チェックリスト
28. まとめ
29. 参考文献

概要

初心者向けメモ： EventBridge は「イベント駆動アーキテクチャの中核」です。AWS サービスの状態変化（EC2 停止、S3 オブジェクト作成、CodePipeline 完了など）が自動的に EventBridge に流れ、ルールで Lambda / Step Functions / SNS / SQS などにルーティングされます。SNS がメッセージ配信に特化するのに対し、EventBridge は 複雑なパターンマッチング・スケジューリング・スキーマ管理 に強みを持ちます。

Amazon EventBridge は、AWS のイベント駆動アーキテクチャの中枢となるサーバーレスイベントバスです。2014 年から提供されている CloudWatch Events の後継として 2019 年に登場し、以下を特徴とします：

• AWS サービスイベントのネイティブ統合（コードなし設定）
• SaaS イベントのパートナーイベントバス
• 複雑なイベントパターンマッチング
• マルチアカウント・マルチリージョン対応
• イベントスキーマレジストリと型安全性
• ポイントツーポイント統合（Pipes）
• スケジューリング機能（Scheduler）

参照：EventBridge User Guide

EventBridge が解決する課題

課題 1：AWS サービスイベントの処理が複雑

❌ 従来の方法

• Lambda がすべてのイベント（フィルタリングなし）を受信
• Lambda 側で JSON パース → 条件分岐 → 実行判定（ボイラープレート）
• ルーティングロジックがアプリケーションに分散

✅ EventBridge 活用

// ルールでフィルタリング → Lambda は必要なイベントのみ受信
{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
    "state": ["stopped", "terminated"]
  }
}

課題 2：SaaS 連携に外部 Webhook 実装が必要

❌ 従来：Salesforce → AWS Lambda でカスタム Webhook → Step Functions

✅ EventBridge Pipes：Salesforce → EventBridge Partner Event Bus → Lambda（ノーコード統合）

課題 3：マルチアカウント環境のイベント集約

❌ 従来：各アカウント → 中央 Lambda にデータ転送 → CloudWatch Logs

✅ EventBridge：各アカウント → セントラル EventBridge（クロスアカウントルール）

課題 4：スケジュール実行の管理が分散

❌ 従来：CloudWatch Events / Lambda ベース Cron / Step Functions

✅ EventBridge Scheduler：統一されたスケジューリング UI・1400 万/月無料

主な特徴

アーキテクチャと基本概念

EventBridge コンポーネント図

graph TB
    EC2["EC2 Instance"]
    S3["S3 Bucket"]
    SaaS["SaaS (Salesforce)"]
    Custom["Custom App"]

    EC2 -->|Event| EB["Event Bus"]
    S3 -->|Event| EB
    SaaS -->|Partner Event| EB
    Custom -->|PutEvents| EB

    EB -->|Rule 1: source=aws.ec2| Lambda["Lambda Function"]
    EB -->|Rule 2: source=com.sales| StepFn["Step Functions"]
    EB -->|Rule 3: amount > 1000| SQS["SQS Queue"]
    EB -->|Rule 4: cron| Scheduler["Scheduled Task"]

    Lambda --> SNS["SNS Topic"]
    StepFn --> DDB["DynamoDB"]
    SQS --> Process["Processing"]
    Scheduler --> Lambda2["Lambda 2"]

    SNS -->|Notification| User["User / Email"]
    DDB -->|Store| Data["Data Lake"]

主要コンポーネント

Event Bus 種別

3 種類の Event Bus

graph LR
    subgraph "AWS Account"
        DefEB["Default Event Bus"]
        CustEB["Custom Event Bus"]
    end
    
    subgraph "Partner Services"
        PartEB["Partner Event Bus<br/>(Salesforce, Zendesk, etc)"]
    end

    AWS["AWS Services<br/>(EC2, S3, GuardDuty)"] -->|Auto| DefEB
    App["Custom Application"] -->|PutEvents| CustEB
    SaaS["SaaS App<br/>(Salesforce, GitHub)"] -->|Auto| PartEB

各種 Event Bus の特性比較

イベント構造と形式

標準イベント形式

{
  "version": "0",
  "id": "cdc73f9d-aea9-11e3-9d5a-835b769c0d9c",
  "detail-type": "EC2 Instance State-change Notification",
  "source": "aws.ec2",
  "account": "123456789012",
  "time": "2024-04-26T10:30:00Z",
  "region": "ap-northeast-1",
  "resources": [
    "arn:aws:ec2:ap-northeast-1:123456789012:instance/i-1234567890abcdef0"
  ],
  "detail": {
    "instance-id": "i-1234567890abcdef0",
    "state": "stopped",
    "state-transition-reason": "User initiated (2024-04-26 10:30:00 GMT)",
    "tags": {
      "Environment": "production",
      "Owner": "team-a"
    }
  }
}

イベントメタデータ

カスタムアプリケーションイベント例

{
  "source": "com.ecommerce.orders",
  "detail-type": "Order Placed",
  "detail": {
    "orderId": "ORD-2024-001",
    "userId": "USR-12345",
    "amount": 15000,
    "currency": "JPY",
    "items": [
      {
        "productId": "PROD-ABC",
        "quantity": 2,
        "price": 7500
      }
    ],
    "deliveryAddress": "Tokyo, Japan",
    "paymentMethod": "credit_card",
    "timestamp": "2024-04-26T10:30:00Z"
  }
}

イベントパターンマッチング

パターンマッチング構文

EventBridge ルールで指定するパターンは JSON ベースで以下をサポート：

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
    "state": ["running", "stopped"],
    "instance-id": ["i-1234567890abcdef0"]
  }
}

マッチング演算子

実践的なパターン例

// 例 1：高額注文（1000 以上）かつステータス created
{
  "source": ["com.myapp.orders"],
  "detail-type": ["OrderCreated"],
  "detail": {
    "amount": [{"numeric": [">=", 1000]}],
    "status": ["created"]
  }
}

// 例 2：本番環境の EC2 停止イベント
{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
    "state": ["stopped"],
    "tags": {
      "Environment": ["production"]
    }
  }
}

// 例 3：Salesforce 商談成立（金額 500K 以上）
{
  "source": ["salesforce.partner"],
  "detail-type": ["Deal Closed"],
  "detail": {
    "amount": [{"numeric": [">", 500000]}],
    "status": ["Won"]
  }
}

// 例 4：CloudTrail API 呼び出し（DeleteBucket 除外）
{
  "source": ["aws.cloudtrail"],
  "detail": {
    "eventName": [{"anything-but": "DeleteBucket"}]
  }
}

マッチング複雑度の比較

Rule と Target

Rule（ルール）の定義

graph LR
    EventBus["Event Bus"] -->|Pattern Matching| Rule["Rule<br/>(Pattern + Priority)"]
    Rule -->|Target 1| Lambda["Lambda"]
    Rule -->|Target 2| SQS["SQS"]
    Rule -->|Target 3| SNS["SNS"]
    Rule -->|DLQ| DLQQueue["SQS DLQ"]

ルール構成要素

Target（ターゲット）設定

{
  "Arn": "arn:aws:lambda:ap-northeast-1:123456789012:function:ProcessOrder",
  "RoleArn": "arn:aws:iam::123456789012:role/EventBridgeRole",
  "DeadLetterConfig": {
    "Arn": "arn:aws:sqs:ap-northeast-1:123456789012:dlq"
  },
  "RetryPolicy": {
    "MaximumEventAge": 3600,
    "MaximumRetryAttempts": 2
  },
  "Input": "{\"orderId\": \"$.detail.orderId\", \"amount\": $.detail.amount}"
}

再試行ポリシー

EventBridge Pipes

Pipes の概念

EventBridge Pipes は「ソースからターゲットへのポイントツーポイント統合」をノーコードで実現します。

graph LR
    SQS["SQS Queue<br/>(Source)"]
    Filter["Filter<br/>(Pattern Matching)"]
    Enrich["Enrich<br/>(Lambda / StepFn)"]
    Transform["Transform<br/>(Input Transformer)"]
    Target["Target<br/>(Lambda / DynamoDB)"]
    DLQ["DLQ<br/>(Error Handling)"]

    SQS -->|1. Consume| Filter
    Filter -->|2. Match| Enrich
    Enrich -->|3. Add Data| Transform
    Transform -->|4. Map Fields| Target
    Target -->|Success| End["✓"]
    Target -->|Error| DLQ

Pipes の構成

Pipes 実装例：SQS → Lambda → DynamoDB

{
  "Name": "OrderProcessingPipe",
  "Source": "arn:aws:sqs:ap-northeast-1:123456789012:orders-queue",
  "SourceParameters": {
    "SQSQueueParameters": {
      "BatchSize": 10,
      "MaximumBatchingWindowInSeconds": 5
    },
    "FilterCriteria": {
      "Body": {
        "amount": [{"numeric": [">=", 1000]}]
      }
    }
  },
  "Enrichment": "arn:aws:lambda:ap-northeast-1:123456789012:function:EnrichOrderData",
  "EnrichmentParameters": {
    "RoleArn": "arn:aws:iam::123456789012:role/EventBridgeRole"
  },
  "Target": "arn:aws:dynamodb:ap-northeast-1:123456789012:table/Orders",
  "TargetParameters": {
    "DynamoDBStreamParameters": {
      "BatchSize": 1
    },
    "RoleArn": "arn:aws:iam::123456789012:role/EventBridgeRole"
  }
}

Pipes vs Rule の選択基準

EventBridge Scheduler

Scheduler の概念

EventBridge Scheduler は、Cron 式・レート・1 回限りのスケジュール を一元管理するサーバーレス機能です。

graph LR
    UI["Scheduler UI<br/>(AWS Console)"]
    Cron["Cron Schedule<br/>(毎日 9 時)"]
    Rate["Rate Schedule<br/>(5 分ごと)"]
    OneTime["One-time Schedule<br/>(2024-12-25 10:00)"]

    UI --> Cron
    UI --> Rate
    UI --> OneTime

    Cron -->|実行| Lambda["Lambda"]
    Rate -->|実行| StepFn["Step Functions"]
    OneTime -->|実行| SQS["SQS"]

スケジュール形式

# Cron 式（UNIX cron との差異：秒とタイムゾーン対応）
cron(0 9 ? * MON-FRI Asia/Tokyo)     # 平日 9 時（日本時間）
cron(0 0 1 * ? *)                    # 毎月 1 日 0 時
cron(0 */6 * * ? *)                  # 6 時間ごと
cron(30 14 * * ? *)                  # 毎日 14:30

# レート式
rate(5 minutes)                      # 5 分ごと
rate(1 hour)                         # 1 時間ごと
rate(7 days)                         # 7 日ごと

# 1 回限り（ISO 8601）
at(2024-12-25T10:00:00)             # 2024-12-25 10:00 一度だけ実行

Scheduler の課金

Scheduler vs CloudWatch Events vs Lambda

Schema Registry

Schema Registry の概念

EventBridge Schema Registry は、イベント構造の自動検出・型安全コード生成・バージョン管理 を提供します。

graph TB
    EventBus["Event Bus"]
    EventBus -->|Monitor| Discovery["Schema Discovery<br/>(自動検出)"]
    Discovery -->|Store| Registry["Schema Registry<br/>(スキーマ定義)"]
    Registry -->|Generate| CodeBind["Code Bindings<br/>(型安全コード)"]
    CodeBind -->|IDE Integration| IDE["VS Code / JetBrains<br/>(Type Completion)"]

スキーマの自動検出フロー

1. イベント監視：EventBridge がイベントバスに流れるイベントを監視
2. スキーマ推測：JSON Schema として構造を自動推測
3. レジストリ保存：推測スキーマを Schema Registry に保存
4. バージョン管理：スキーマ変更を版管理（v1, v2, …）
5. コード生成：JSON Schema から言語別の型定義を自動生成

Schema Registry 設定例

{
  "Name": "orders@latest",
  "Description": "Order events schema",
  "RegistryName": "default",
  "SchemaVersion": "1.0",
  "Type": "OpenAPI3",
  "Content": {
    "$schema": "http://json-schema.org/draft-07/schema#",
    "type": "object",
    "properties": {
      "orderId": {
        "type": "string",
        "description": "Order ID"
      },
      "amount": {
        "type": "number",
        "description": "Order amount in JPY"
      },
      "timestamp": {
        "type": "string",
        "format": "date-time"
      }
    },
    "required": ["orderId", "amount"]
  }
}

Code Bindings 生成（Python 例）

from generated_schemas import orders

def lambda_handler(event, context):
    # Type-safe access to event properties
    order = orders.OrderPlaced.model_validate(event['detail'])
    
    print(f"Order ID: {order.orderId}")
    print(f"Amount: {order.amount}")
    print(f"Timestamp: {order.timestamp}")
    
    return {
        "statusCode": 200,
        "body": f"Processed order {order.orderId}"
    }

スキーマレジストリのユースケース

✅ 使うべき場合

• イベント構造が複雑で型安全コード生成が必要
• IDE インテリセンス活用で開発効率向上
• API 契約管理（AsyncAPI / OpenAPI）が必要

❌ 不要な場合

• イベント構造がシンプル（2-3 フィールド）
• 動的にスキーマが変わる場合

入力変換と入力トランスフォーマー

入力トランスフォーマーの役割

ターゲットに送信する前に、イベントフォーマットを変換・抽出 します。

graph LR
    Event["EventBridge Event<br/>(full JSON)"]
    Path["InputPathsMap<br/>(JSONPath extraction)"]
    Template["InputTemplate<br/>(template string)"]
    Target["Target<br/>(custom format)"]

    Event -->|1. Extract| Path
    Path -->|2. Map| Template
    Template -->|3. Format| Target

InputPathsMap と InputTemplate

{
  "InputPathsMap": {
    "orderId": "$.detail.orderId",
    "amount": "$.detail.amount",
    "timestamp": "$.time",
    "eventId": "$.id"
  },
  "InputTemplate": "{\"order_id\": \"<orderId>\", \"price\": <amount>, \"processed_at\": \"<timestamp>\", \"event_uuid\": \"<eventId>\"}"
}

入力（EventBridge イベント）

{
  "id": "abc123",
  "time": "2024-04-26T10:30:00Z",
  "detail": {
    "orderId": "ORD-001",
    "amount": 15000
  }
}

出力（Lambda に送信）

{
  "order_id": "ORD-001",
  "price": 15000,
  "processed_at": "2024-04-26T10:30:00Z",
  "event_uuid": "abc123"
}

JSONPath 式

DLQ と再試行ポリシー

Dead Letter Queue（DLQ）の概念

graph LR
    Event["Event"]
    Target["Target<br/>(Lambda)"]
    Success["✓ Success"]
    Retry["⏳ Retry<br/>(Exponential Backoff)"]
    DLQ["SQS DLQ<br/>(保存)"]

    Event -->|Send| Target
    Target -->|Success| Success
    Target -->|Error| Retry
    Retry -->|Max Retries Exceeded| DLQ
    Retry -->|Retry Success| Success

再試行フロー

1. 初回送信：イベント → ターゲット（Lambda）
2. 失敗：Lambda がエラーを返す
3. リトライ：指数バックオフで再試行
   • 1 回目：即座 + ランダム遅延
   • 2 回目：60 秒 + ランダム遅延
   • 3 回目以降：指数増加
4. 最大試行回数超過：DLQ（SQS）に送信
5. 手動対応：DLQ メッセージを確認・再送

DLQ 設定例

{
  "Arn": "arn:aws:lambda:ap-northeast-1:123456789012:function:ProcessOrder",
  "DeadLetterConfig": {
    "Arn": "arn:aws:sqs:ap-northeast-1:123456789012:dlq-orders"
  },
  "RetryPolicy": {
    "MaximumEventAge": 3600,
    "MaximumRetryAttempts": 2
  }
}

リトライ期限の設定値

DLQ 監視ベストプラクティス

# CloudWatch Alarm：DLQ にメッセージが溜まったら通知
aws cloudwatch put-metric-alarm \
  --alarm-name dlq-messages-alert \
  --metric-name ApproximateNumberOfMessagesVisible \
  --namespace AWS/SQS \
  --statistic Average \
  --period 300 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:alerts

ターゲット一覧と統合

対応ターゲット（30+ サービス）

graph TB
    EB["EventBridge"]
    
    Compute["Compute"]
    DB["Database"]
    Messaging["Messaging"]
    Workflow["Workflow"]
    Network["Network"]
    
    EB --> Lambda
    EB --> ECS["ECS Task"]
    EB --> CodeBuild
    EB --> CodePipeline
    
    EB --> DDB["DynamoDB"]
    EB --> RDS["RDS"]
    EB --> Kinesis["Kinesis"]
    EB --> S3["S3"]
    
    EB --> SQS
    EB --> SNS
    EB --> Kafka["MSK"]
    
    EB --> StepFn["Step Functions"]
    EB --> AppFlow["AppFlow"]
    
    EB --> APIGateway["API Gateway"]
    EB --> AppSync["AppSync"]
    EB --> ServiceCatalog["Service Catalog"]

主要ターゲット詳細

ターゲット送信フロー

// EventBridge ルール設定例：複数ターゲット
{
  "Name": "OrderCreatedRule",
  "EventBusName": "default",
  "EventPattern": {
    "source": ["com.myapp.orders"],
    "detail-type": ["OrderCreated"]
  },
  "Targets": [
    {
      "Arn": "arn:aws:lambda:ap-northeast-1:123456789012:function:ProcessOrder",
      "RoleArn": "arn:aws:iam::123456789012:role/EventBridgeRole",
      "Id": "1"
    },
    {
      "Arn": "arn:aws:sqs:ap-northeast-1:123456789012:order-queue",
      "RoleArn": "arn:aws:iam::123456789012:role/EventBridgeRole",
      "Id": "2"
    },
    {
      "Arn": "arn:aws:sns:ap-northeast-1:123456789012:order-notifications",
      "RoleArn": "arn:aws:iam::123456789012:role/EventBridgeRole",
      "Id": "3"
    }
  ]
}

API Destinations と外部連携

API Destinations の概念

graph LR
    EB["EventBridge"]
    Conn["Connection<br/>(認証情報)"]
    APIDest["API Destination<br/>(URL + 認証)"]
    Ext["External API<br/>(Slack, GitHub, etc)"]

    EB -->|EventBridge Rule| APIDest
    APIDest -->|Use| Conn
    APIDest -->|POST/PUT/GET| Ext

API Destination 設定フロー

1. Connection を作成（認証情報保管）

{
  "Name": "slack-connection",
  "Description": "Slack Webhook Connection",
  "AuthorizationType": "API_KEY",
  "AuthParameters": {
    "ApiKeyAuthParameters": {
      "ApiKeyName": "Authorization",
      "ApiKeyValue": "Bearer xoxb-YOUR-TOKEN"
    }
  }
}

2. API Destination を作成（URL + Connection）

{
  "Name": "slack-api-destination",
  "ConnectionArn": "arn:aws:events:ap-northeast-1:123456789012:connection/slack-connection/...",
  "HttpMethod": "POST",
  "InvocationHttpParameters": {
    "HeaderParameters": {
      "Content-Type": "application/json"
    }
  },
  "RateLimitPolicy": {
    "RateLimit": 10
  }
}

3. EventBridge ルールで使用

{
  "Targets": [
    {
      "Arn": "arn:aws:events:ap-northeast-1:123456789012:api-destination/slack-api-destination/...",
      "HttpParameters": {
        "PathParameterValues": {},
        "HeaderParameters": {
          "X-Custom-Header": "EventBridge"
        },
        "QueryStringParameters": {}
      },
      "RoleArn": "arn:aws:iam::123456789012:role/EventBridgeRole",
      "Id": "1"
    }
  ]
}

主要 API Destinations 統合例

Slack 連携の完全例

# Lambda: Slack メッセージを EventBridge イベントから生成
import json

def lambda_handler(event, context):
    detail = event['detail']
    
    # EventBridge イベント → Slack メッセージ
    slack_message = {
        "text": f"🚨 Alert: {detail['alarmName']}",
        "blocks": [
            {
                "type": "section",
                "text": {
                    "type": "mrkdwn",
                    "text": f"*{detail['alarmName']}*\nState: {detail['state']}"
                }
            },
            {
                "type": "section",
                "fields": [
                    {
                        "type": "mrkdwn",
                        "text": f"*Severity:*\n{detail['severity']}"
                    },
                    {
                        "type": "mrkdwn",
                        "text": f"*Time:*\n{event['time']}"
                    }
                ]
            }
        ]
    }
    
    return slack_message

主要ユースケース

ユースケース 1：AWS サービスイベント駆動

シナリオ：EC2 インスタンス停止時に自動タグ付け・通知・CloudTrail ログ記録

graph LR
    EC2["EC2<br/>(Instance Stopped)"]
    EB["EventBridge<br/>(Rule)"]
    Lambda["Lambda<br/>(Auto-tagging)"]
    SNS["SNS<br/>(Notification)"]
    CloudTrail["CloudTrail<br/>(Audit)"]

    EC2 -->|State Change| EB
    EB -->|Rule Match| Lambda
    EB -->|Parallel| SNS
    EB -->|Parallel| CloudTrail

EventBridge ルール

{
  "Name": "EC2StoppedAutoTag",
  "EventPattern": {
    "source": ["aws.ec2"],
    "detail-type": ["EC2 Instance State-change Notification"],
    "detail": {
      "state": ["stopped"]
    }
  },
  "Targets": [
    {
      "Arn": "arn:aws:lambda:ap-northeast-1:123456789012:function:AutoTagInstance",
      "Id": "1"
    },
    {
      "Arn": "arn:aws:sns:ap-northeast-1:123456789012:instance-alerts",
      "Id": "2"
    }
  ]
}

ユースケース 2：SaaS 統合ワークフロー

シナリオ：Salesforce 商談完了 → AWS ワークフロー起動 → 注文システム処理

Salesforce "Deal Closed" Event
    ↓
EventBridge Partner Event Bus
    ↓
Filter: stage = "Closed Won" AND amount >= ¥1M
    ↓
Step Functions: 受注処理フロー
    - 在庫確認
    - 配送手配
    - 請求書生成
    ↓
DynamoDB: 受注記録
    ↓
SNS: Slack 通知

ユースケース 3：マルチアカウント監視集約

シナリオ：本番・ステージング・開発アカウントの GuardDuty 検出をセントラル EventBridge に集約

Account A (GuardDuty Finding)
    ↓
EventBridge Default Bus → Rule
    ↓
Send to Central Account EventBridge
    ↓
Account C (Central)
    ↓
EventBridge → SNS / PagerDuty / CloudWatch

ユースケース 4：カスタムアプリケーション統合

シナリオ：マイクロサービス間イベント駆動通信

Order Service (PutEvents)
    ↓
EventBridge Custom Bus: "OrderCreated"
    ↓
Multiple Consumers:
    - Payment Service Lambda
    - Inventory Service Lambda
    - Shipping Service Lambda
    - Analytics Pipeline
    ↓
各サービスが独立して処理

ユースケース 5：スケジュール駆動ジョブ

シナリオ：毎日 9 時に日次レポート集計 / 月次で不正検知

EventBridge Scheduler
    ├── cron(0 9 ? * MON-FRI *) → DailyReportLambda
    ├── cron(0 0 1 * ? *) → MonthlyAuditLambda
    └── rate(30 minutes) → HealthCheckLambda

ユースケース 6：CI/CD パイプライン統合

シナリオ：デプロイ完了 → テスト実行 → Slack 通知 → ロールバック決定

CodePipeline (Deployment Completed)
    ↓
EventBridge Rule
    ↓
Parallel Targets:
    1. CodeBuild (Integration Tests)
    2. Lambda (Smoke Tests)
    3. SNS (Slack Notification)
    ↓
Results → Step Functions (Rollback Decision)

ユースケース 7：IoT デバイスデータ処理

シナリオ：IoT デバイス → Kinesis → EventBridge Pipes → ML 分析

IoT Device (温度センサー)
    ↓
Kinesis Data Stream
    ↓
EventBridge Pipe (filter + enrich)
    - Filter: temperature > 40°C
    - Enrich: Lambda で異常スコア計算
    ↓
SageMaker (異常検知 Model)
    ↓
CloudWatch Alarm

ユースケース 8：ETL トリガー

シナリオ：S3 へのデータアップロード → Glue ETL → Data Lake 更新

S3 (Object Created)
    ↓
EventBridge Default Bus
    ↓
Filter: prefix = "raw-data/" AND suffix = ".csv"
    ↓
AWS Glue (ETL Job)
    ↓
Processed Data → S3 (data-lake/)
    ↓
Athena (クエリ可能)

ユースケース 9：監査ログ・コンプライアンス

シナリオ：すべての重要 API 呼び出し → EventBridge → コンプライアンス検証

CloudTrail API Events
    ↓
EventBridge Rule
    ├── Filter: eventName in ["DeleteBucket", "PutBucketPolicy", ...]
    ↓
Step Functions (Compliance Check)
    ├── 承認者に通知
    ├── レビュー待機
    ├── 承認 → ログ記録
    └── 拒否 → リソース復元

ユースケース 10+：その他

セキュリティと IAM

IAM ロール・ポリシー

EventBridge がターゲットを呼び出すために必要な IAM ロール

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "lambda:InvokeFunction"
      ],
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:ProcessOrder"
    },
    {
      "Effect": "Allow",
      "Action": [
        "sqs:SendMessage"
      ],
      "Resource": "arn:aws:sqs:ap-northeast-1:123456789012:order-queue"
    },
    {
      "Effect": "Allow",
      "Action": [
        "sns:Publish"
      ],
      "Resource": "arn:aws:sns:ap-northeast-1:123456789012:notifications"
    },
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:PutItem"
      ],
      "Resource": "arn:aws:dynamodb:ap-northeast-1:123456789012:table/Orders"
    }
  ]
}

Event Bus リソースポリシー（クロスアカウント）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAccountBToPutEvents",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:root"
      },
      "Action": "events:PutEvents",
      "Resource": "arn:aws:events:ap-northeast-1:123456789012:event-bus/default"
    }
  ]
}

KMS 暗号化

EventBridge はイベントを KMS で暗号化できます。

{
  "Name": "EncryptedEventBus",
  "KmsKeyArn": "arn:aws:kms:ap-northeast-1:123456789012:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}

セキュリティベストプラクティス

✅ 実施すべき

• イベントバスにリソースポリシーを設定（最小権限）
• API Destinations の接続情報を AWS Secrets Manager で管理
• CloudTrail でイベントバスの操作を監査
• VPC エンドポイント（PrivateLink）でプライベート接続
• DLQ で失敗イベント監視（潜在的なセキュリティ問題検出）

❌ 避けるべき

• デフォルトイベントバスにワイルドカード（*）ポリシー
• API Destination トークンをハードコード
• 本番環境で認証なし API エンドポイント
• 機密情報をイベント detail に含める

CloudWatch メトリクスと監視

EventBridge CloudWatch メトリクス

CloudWatch ダッシュボード例

{
  "widgets": [
    {
      "type": "metric",
      "properties": {
        "metrics": [
          ["AWS/Events", "Invocations", {"stat": "Sum"}],
          [".", "FailedInvocations", {"stat": "Sum"}],
          [".", "TriggeredRules", {"stat": "Sum"}],
          [".", "InvocationLatency", {"stat": "Average"}]
        ],
        "period": 300,
        "stat": "Average",
        "region": "ap-northeast-1",
        "title": "EventBridge Metrics"
      }
    }
  ]
}

CloudWatch Alarms

# Failed Invocations >= 1 の場合通知
aws cloudwatch put-metric-alarm \
  --alarm-name eventbridge-failed-invocations \
  --metric-name FailedInvocations \
  --namespace AWS/Events \
  --statistic Sum \
  --period 300 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:alerts

# High Invocation Latency
aws cloudwatch put-metric-alarm \
  --alarm-name eventbridge-high-latency \
  --metric-name InvocationLatency \
  --namespace AWS/Events \
  --statistic Average \
  --period 300 \
  --threshold 1000 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:alerts

他の類似ツールとの比較

EventBridge vs SNS vs SQS

graph TB
    subgraph EventBridge["EventBridge<br/>(イベント駆動ルーティング)"]
        EB["特徴"]
        EB1["✓ パターンマッチング<br/>✓ スケジューリング<br/>✓ スキーマレジストリ<br/>✓ Pipes"]
    end
    
    subgraph SNS["SNS<br/>(Pub/Sub通知)"]
        SN["特徴"]
        SN1["✓ シンプル<br/>✓ Fan-out<br/>✓ Email/SMS<br/>❌ パターン"]
    end
    
    subgraph SQS["SQS<br/>(メッセージキュー)"]
        SQ["特徴"]
        SQ1["✓ FIFO<br/>✓ バッファ<br/>✓ DLQ<br/>❌ Pub/Sub"]
    end

詳細比較表

選択基準

イベント駆動 + 複雑なルーティング + AWS サービス統合
    → EventBridge ✅

シンプルな通知・メール送信・複数の購読者
    → SNS ✅

メッセージバッファリング・FIFO・遅延配信
    → SQS ✅

大規模・リアルタイム・複雑なストリーム処理・複数言語
    → Kafka / MSK ✅

EventBridge vs Step Functions

クライアント・SDK・IaC

AWS CLI

# カスタムイベント送信
aws events put-events \
  --entries '[{
    "Source": "com.myapp.orders",
    "DetailType": "OrderCreated",
    "Detail": "{\"orderId\": \"ORD-001\", \"amount\": 15000}"
  }]'

# ルール作成
aws events put-rule \
  --name OrderCreatedRule \
  --event-pattern '{"source": ["com.myapp.orders"], "detail-type": ["OrderCreated"]}'

# ターゲット追加
aws events put-targets \
  --rule OrderCreatedRule \
  --targets "Id"="1","Arn"="arn:aws:lambda:ap-northeast-1:123456789012:function:ProcessOrder"

# スケジューラー作成
aws scheduler create-schedule \
  --name DailyReportSchedule \
  --schedule-expression 'cron(0 9 ? * MON-FRI Asia/Tokyo)' \
  --target '{"Arn": "arn:aws:lambda:ap-northeast-1:123456789012:function:DailyReport", "RoleArn": "arn:aws:iam::123456789012:role/SchedulerRole"}'

Python（Boto3）

import json
import boto3

events = boto3.client('events', region_name='ap-northeast-1')

# イベント送信
response = events.put_events(
    Entries=[
        {
            'Source': 'com.myapp.orders',
            'DetailType': 'OrderCreated',
            'Detail': json.dumps({
                'orderId': 'ORD-001',
                'amount': 15000,
                'userId': 'USR-12345'
            })
        }
    ]
)

print(f"Failed entries: {response['FailedEntryCount']}")

# ルール作成
events.put_rule(
    Name='OrderCreatedRule',
    EventPattern=json.dumps({
        'source': ['com.myapp.orders'],
        'detail-type': ['OrderCreated'],
        'detail': {
            'amount': [{'numeric': ['>=', 1000]}]
        }
    }),
    State='ENABLED'
)

# ターゲット追加
events.put_targets(
    Rule='OrderCreatedRule',
    Targets=[
        {
            'Id': '1',
            'Arn': 'arn:aws:lambda:ap-northeast-1:123456789012:function:ProcessOrder',
            'RoleArn': 'arn:aws:iam::123456789012:role/EventBridgeRole'
        }
    ]
)

AWS CDK（Python）

from aws_cdk import (
    aws_events as events,
    aws_events_targets as targets,
    aws_lambda as lambda_,
    core
)

class EventBridgeStack(core.Stack):
    def __init__(self, scope: core.Construct, id: str, **kwargs):
        super().__init__(scope, id, **kwargs)
        
        # Lambda 関数
        process_order_fn = lambda_.Function(
            self, 'ProcessOrderFunction',
            runtime=lambda_.Runtime.PYTHON_3_11,
            handler='index.handler',
            code=lambda_.Code.from_asset('lambda')
        )
        
        # EventBridge ルール
        rule = events.Rule(
            self, 'OrderCreatedRule',
            event_pattern=events.EventPattern(
                source=['com.myapp.orders'],
                detail_type=['OrderCreated'],
                detail={
                    'amount': [events.Match.numeric_greater_than_or_equal_to(1000)]
                }
            )
        )
        
        # Lambda をターゲットに追加
        rule.add_target(targets.LambdaFunction(process_order_fn))
        
        # EventBridge Scheduler
        scheduler = events.Schedule.cron(
            hour='9',
            minute='0',
            week_day='MON-FRI',
            day=None,
            month=None,
            year=None
        )
        
        daily_report_fn = lambda_.Function(
            self, 'DailyReportFunction',
            runtime=lambda_.Runtime.PYTHON_3_11,
            handler='index.handler',
            code=lambda_.Code.from_asset('lambda')
        )
        
        events.Rule(
            self, 'DailyReportRule',
            schedule=scheduler
        ).add_target(targets.LambdaFunction(daily_report_fn))

Terraform

# EventBridge ルール
resource "aws_cloudwatch_event_rule" "order_created" {
  name = "order-created-rule"
  
  event_pattern = jsonencode({
    source      = ["com.myapp.orders"]
    detail-type = ["OrderCreated"]
    detail = {
      amount = [{
        numeric = [">=", 1000]
      }]
    }
  })
}

# Lambda ターゲット
resource "aws_cloudwatch_event_target" "process_order" {
  rule      = aws_cloudwatch_event_rule.order_created.name
  target_id = "ProcessOrderLambda"
  arn       = aws_lambda_function.process_order.arn
  role_arn  = aws_iam_role.eventbridge_role.arn
  
  dead_letter_config {
    arn = aws_sqs_queue.dlq.arn
  }
  
  retry_policy {
    maximum_event_age       = 3600
    maximum_retry_attempts  = 2
  }
}

# EventBridge Scheduler
resource "aws_scheduler_schedule" "daily_report" {
  name       = "daily-report-schedule"
  expression = "cron(0 9 ? * MON-FRI)"
  timezone   = "Asia/Tokyo"
  
  flexible_time_window {
    mode = "OFF"
  }
  
  target {
    arn      = aws_lambda_function.daily_report.arn
    role_arn = aws_iam_role.scheduler_role.arn
  }
}

Serverless Framework

service: event-driven-app

provider:
  name: aws
  region: ap-northeast-1
  runtime: python3.11

functions:
  processOrder:
    handler: handlers/process_order.handler
    events:
      - eventBridge:
          pattern:
            source:
              - com.myapp.orders
            detail-type:
              - OrderCreated
            detail:
              amount:
                - numeric:
                    - ">="
                    - 1000

  dailyReport:
    handler: handlers/daily_report.handler
    events:
      - schedule:
          rate: cron(0 9 ? * MON-FRI Asia/Tokyo)
          enabled: true

plugins:
  - serverless-python-requirements

ベストプラクティス

1. イベント設計

✅ 良い例

{
  "source": "com.myapp.orders",
  "detail-type": "OrderCreated",
  "detail": {
    "orderId": "ORD-001",
    "customerId": "CUST-123",
    "amount": 15000,
    "currency": "JPY",
    "timestamp": "2024-04-26T10:30:00Z",
    "metadata": {
      "environment": "production",
      "version": "1.0"
    }
  }
}

❌ 悪い例

{
  "source": "order",
  "detail-type": "order-event",
  "detail": {
    "data": "ORD-001|15000|..."  // カンマ区切り
  }
}

2. パターンマッチング最適化

✅ 推奨

• ルール側でフィルタリング（EventBridge で）
• ターゲットリソースには必要なイベントのみ到達

❌ 非推奨

• Lambda ですべてのイベント受信 → 内部で条件分岐
• ターゲットリソースでフィルタリング（無駄な実行）

3. DLQ 監視

# CloudWatch Alarm: DLQ メッセージ数 > 0
alarm = cloudwatch.Alarm(
    self, 'DLQMessageAlarm',
    metric=sqs_queue.metric_approximate_number_of_messages_visible(),
    threshold=1,
    evaluation_periods=1,
    alarm_name='eventbridge-dlq-has-messages'
)

alarm.add_alarm_action(
    cloudwatch_actions.SnsAction(sns_topic)
)

4. エラーハンドリング

✅ 必須

• DLQ 設定
• 再試行ポリシー（MaximumEventAge / MaximumRetryAttempts）
• CloudWatch Alarms で監視

5. スケジューラーのタイムゾーン

# タイムゾーン明示（日本時間）
aws scheduler create-schedule \
  --name daily-job \
  --schedule-expression 'cron(0 9 ? * MON-FRI)' \
  --timezone 'Asia/Tokyo'

6. API Destination 認証

✅ 推奨

# AWS Secrets Manager で認証情報管理
connection = events.Connection(
    self, 'SlackConnection',
    authorization=events.Authorization.api_key(
        'Authorization',
        core.SecretValue.secrets_manager('slack-webhook-token')
    )
)

❌ 非推奨

# ハードコード
'Authorization': 'Bearer xoxb-...'

7. クロスアカウント設定

// セントラルアカウント：受信側リソースポリシー
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::111111111111:root",
          "arn:aws:iam::222222222222:root"
        ]
      },
      "Action": "events:PutEvents",
      "Resource": "arn:aws:events:ap-northeast-1:123456789012:event-bus/central"
    }
  ]
}

8. イベントアーカイブとリプレイ

✅ 活用例

• バグ修正後に過去 1 時間のイベント再処理
• ステージング環境での機能検証 -災害復旧時のイベント再実行

# アーカイブ作成
aws events create-archive \
  --name order-events-archive \
  --event-source-arn arn:aws:events:ap-northeast-1:123456789012:event-bus/default \
  --retention-days 30

# リプレイ（過去 1 時間）
aws events start-replay \
  --name replay-order-events \
  --event-source-arn arn:aws:events:ap-northeast-1:123456789012:event-bus/default \
  --event-start-time 2024-04-26T09:30:00Z \
  --event-end-time 2024-04-26T10:30:00Z

9. スキーマレジストリ活用

✅ 型安全開発

from generated_schemas.orders import OrderCreated

def lambda_handler(event, context):
    # IDE でオートコンプリート & 型チェック
    order = OrderCreated.model_validate(event['detail'])
    print(f"Order: {order.orderId}, Amount: {order.amount}")

10. コスト最適化

トラブルシューティング

問題 1：ルールがマッチしない

原因確認

# テストイベント送信
aws events put-events \
  --entries '[{
    "Source": "com.myapp.orders",
    "DetailType": "OrderCreated",
    "Detail": "{\"orderId\": \"ORD-001\", \"amount\": 15000}"
  }]'

# CloudWatch Logs で確認
aws logs tail /aws/events/orderrule --follow

よくある原因と対処

問題 2：Lambda がイベント受信できない

確認項目

# Lambda リソースベースのポリシー確認
aws lambda get-policy --function-name ProcessOrder

# EventBridge ターゲット設定確認
aws events list-targets-by-rule --rule OrderCreatedRule

対処

# Lambda へのアクセス許可追加
aws lambda add-permission \
  --function-name ProcessOrder \
  --statement-id AllowEventBridgeInvoke \
  --action lambda:InvokeFunction \
  --principal events.amazonaws.com \
  --source-arn arn:aws:events:ap-northeast-1:123456789012:rule/OrderCreatedRule

問題 3：DLQ にメッセージが溜まる

デバッグ

# DLQ メッセージ確認
aws sqs receive-message --queue-url <dlq-url> --max-number-of-messages 1

# メッセージ内容確認（Base64 デコード）
python3 -c "import base64; print(base64.b64decode('<body>').decode())"

よくある原因

問題 4：スケジューラーが実行されない

# スケジュール確認
aws scheduler get-schedule --name daily-report-schedule

# 実行履歴確認（CloudWatch）
aws logs tail /aws/scheduler/eventbridge --follow

# タイムゾーン確認
aws scheduler get-schedule --name daily-report-schedule --query 'Timezone'

よくある原因

問題 5：API Destination がエラー

# Connection 詳細確認
aws events describe-connection --name slack-connection

# API Destination テスト
aws events test-event-pattern \
  --event-pattern '{"detail": {"test": true}}' \
  --event '{"detail": {"test": true}}'

対処

• API トークンの有効期限確認
• HTTP ステータスコード（401 = 認証失敗、429 = レート制限）
• CloudWatch Logs で詳細確認

2025-2026 最新動向

1. EventBridge Pipes 拡張

新機能

• ✅ Bedrock へのエンリッチメント対応（AI/ML データ拡張）
• ✅ DynamoDB ストリーム → SQS / SNS への直接パイプ
• ✅ 複数エンリッチメント段階の連鎖

例：AI エンリッチメント

{
  "Enrichment": "arn:aws:bedrock:ap-northeast-1::invokeModel...",
  "EnrichmentParameters": {
    "RoleArn": "arn:aws:iam::123456789012:role/BedrockInvoke"
  }
}

2. EventBridge Scheduler 強化

新機能

• ✅ タイムゾーン設定ネイティブ対応（全リージョン）
• ✅ フレキシブル時間窓（15 分以内）
• ✅ カスタムリトライポリシー

3. Event Source Mapping for Lambda

背景：Lambda が EventBridge を直接ポーリング可能に

{
  "EventSourceMappings": {
    "SourceArn": "arn:aws:events:ap-northeast-1:...",
    "FunctionName": "ProcessEvents",
    "Enabled": true,
    "BatchSize": 10
  }
}

4. AI-driven Event Routing

2026 予測

• EventBridge が機械学習モデルで最適なターゲット判定
• 負荷分散の自動最適化
• 異常検知による自動スロットル

5. Schema Registry 拡張

新対応フォーマット

• ✅ Protocol Buffers（protobuf）
• ✅ Apache Avro
• ✅ GraphQL Schema

6. クロスアカウント DLQ

管理簡素化

• セントラルアカウントの DLQ で全組織のイベント失敗を一元監視

学習リソース

公式ドキュメント

• Amazon EventBridge User Guide
• EventBridge API Reference
• AWS EventBridge Scheduler Documentation
• EventBridge Pipes Documentation
• EventBridge Schema Registry

AWS トレーニング

• Event-Driven Architecture on AWS
• AWS Skill Builder: EventBridge Learning Path

コミュニティリソース

• AWS EventBridge Examples（GitHub）
• Serverless Land: EventBridge Patterns
• AWS re:Post - EventBridge

実装例・活用シーン

実装例 1：完全なイベント駆動型 e-コマース

# 1. 注文作成イベント
orders_client = boto3.client('events')

def create_order(order_data):
    orders_client.put_events(
        Entries=[{
            'Source': 'com.ecommerce.orders',
            'DetailType': 'OrderCreated',
            'Detail': json.dumps(order_data)
        }]
    )

# 2. EventBridge ルール：支払い処理
{
  "Rule": "PaymentProcessingRule",
  "Pattern": {
    "source": ["com.ecommerce.orders"],
    "detail-type": ["OrderCreated"]
  },
  "Target": "PaymentProcessingLambda"
}

# 3. EventBridge ルール：在庫確認
{
  "Rule": "InventoryCheckRule",
  "Pattern": {
    "source": ["com.ecommerce.orders"],
    "detail-type": ["OrderCreated"]
  },
  "Target": "InventoryCheckLambda"
}

# 4. EventBridge ルール：配送手配
{
  "Rule": "ShippingRule",
  "Pattern": {
    "source": ["com.ecommerce.orders"],
    "detail-type": ["OrderCreated"],
    "detail": {
      "amount": [{"numeric": [">=", 1000]}]
    }
  },
  "Target": "ShippingLambda"
}

# 5. 結果：複数サービスが独立して並行実行
# Order Created → [Payment, Inventory, Shipping] 並列実行

実装例 2：マルチアカウント監視

# Account A（ソース）
resource "aws_cloudwatch_event_rule" "securityhub_findings" {
  name  = "securityhub-findings"
  event_pattern = jsonencode({
    source      = ["aws.securityhub"]
    detail-type = ["Security Hub Findings"]
  })
}

resource "aws_cloudwatch_event_target" "central_account" {
  rule      = aws_cloudwatch_event_rule.securityhub_findings.name
  target_id = "CentralEventBus"
  arn       = "arn:aws:events:ap-northeast-1:CENTRAL_ACCOUNT_ID:event-bus/central"
  role_arn  = aws_iam_role.eventbridge_cross_account.arn
}

# Account C（セントラル）
resource "aws_cloudwatch_event_rule" "aggregated_findings" {
  name           = "aggregated-findings"
  event_bus_name = "central"
  event_pattern = jsonencode({
    source      = ["aws.securityhub"]
    detail-type = ["Security Hub Findings"]
  })
}

resource "aws_cloudwatch_event_target" "pagerduty" {
  rule      = aws_cloudwatch_event_rule.aggregated_findings.name
  target_id = "PagerDutyIncident"
  arn       = aws_cloudwatch_event_api_destination.pagerduty.arn
  role_arn  = aws_iam_role.eventbridge_role.arn
}

導入ロードマップ

フェーズ 1：検証（1-2 週間）

1. EventBridge コンソール操作
2. テストルール作成・イベント送信
3. Lambda / SQS ターゲット確認
4. CloudWatch Logs でトレース

フェーズ 2：パイロット（2-4 週間）

1. 小規模本番ユースケース（例：EC2 監視）
2. IAM ポリシー設定
3. DLQ 設定・監視
4. ドキュメント整備

フェーズ 3：段階的展開（1-2 ヶ月）

1. 複数ルール運用
2. クロスアカウント設定
3. スケジューラー導入
4. チームトレーニング

フェーズ 4：最適化（継続）

1. コスト分析・チューニング
2. Pipes / Scheduler 活用
3. スキーマレジストリ導入
4. ベストプラクティス浸透

実装チェックリスト

セットアップ前

• [ ] AWS アカウント・権限確認
• [ ] リージョン決定（マルチリージョン計画）
• [ ] ユースケース定義・優先順位付け

ルール設計

• [ ] イベント構造設計（source / detail-type / detail）
• [ ] パターンマッチング条件定義
• [ ] ターゲット決定（Lambda / SQS / SNS / 等）
• [ ] リトライ・DLQ 戦略

実装

• [ ] EventBridge ルール作成（AWS Console / IaC）
• [ ] ターゲットリソース IAM ロール
• [ ] Lambda / Step Functions コード実装
• [ ] DLQ 設定（SQS キュー）

テスト

• [ ] ユニットテスト（Lambda）
• [ ] 統合テスト（イベント送信→処理検証）
• [ ] エラーシナリオテスト（リトライ・DLQ）
• [ ] 負荷テスト（スループット確認）

デプロイ・運用

• [ ] CloudWatch Alarms 設定
• [ ] ログ・メトリクス収集
• [ ] 監視ダッシュボード
• [ ] オンコール体制

ドキュメント・保守

• [ ] ルール・パターン文書化
• [ ] トラブルシューティングガイド
• [ ] ランブック作成
• [ ] 定期的なコスト分析

まとめ

Amazon EventBridge は、AWS のイベント駆動アーキテクチャの中核 となる強力なサービスです。

EventBridge が優れている理由

✅ AWS サービスイベントの一元管理：EC2・S3・CodePipeline・GuardDuty 等のイベントが自動的に流れ、ルール一つで複数ターゲットにルーティング

✅ 複雑なパターンマッチング：JSON パターンで数値比較・正規表現など柔軟にフィルタリング、Lambda ロジック削減

✅ SaaS 統合の簡素化：Salesforce・Zendesk・GitHub などの Partner Event Bus で認証なしに SaaS イベント受信

✅ スケジューリング統一：EventBridge Scheduler で Cron・レート・1 回限り実行を一元管理（1400 万/月無料）

✅ Pipes による ETL 簡素化：ソース→フィルタ→エンリッチ→ターゲット を宣言的に実装

✅ スキーマレジストリで型安全：イベント構造を自動検出・言語別コード生成で IDE インテリセンス活用

推奨ユースケース

• 🚀 AWS サービス間のイベント駆動連携
• 🎯 マルチアカウント・マルチリージョン環境の集約
• 📋 定期実行ジョブの一元管理（Scheduler）
• 🔗 SaaS 統合・外部 API 連携
• 📊 マイクロサービス間のイベント通信

導入のコツ

1. 小さく始める：1-2 ユースケースでパターン確立
2. DLQ・アラーム必須：運用安定性の基盤
3. IaC 活用：Terraform / CDK で再現性確保
4. スキーマレジストリ：複雑なイベント構造では型安全化
5. コスト監視：カスタムイベント課金・Pipes 活用で最適化

次のステップ

1. AWS Console で テストルール作成
2. Python / CDK でコード化
3. 本番ユースケース 1 つ実装
4. チーム内ナレッジ共有・社内ガイドライン作成

EventBridge は、「書かずに設定する」が哲学 です。ルールを設定すれば複雑なロジックなしにイベント駆動アーキテクチャが実現でき、AWS サービスの真の力を引き出せます。

参考文献

公式ドキュメント（10+）

1. What is Amazon EventBridge
2. EventBridge User Guide
3. EventBridge API Reference
4. EventBridge Pricing
5. EventBridge Scheduler Documentation
6. EventBridge Pipes
7. Schema Registry
8. API Destinations
9. Archivals & Replay
10. Security in EventBridge

関連サービス

• CloudWatch Events（前身）
• AWS Lambda
• AWS Step Functions
• Amazon SQS
• Amazon SNS
• Amazon Kinesis

イベント設計標準

• CNCF CloudEvents Specification v1.0.2
• AsyncAPI Initiative - Event-Driven API Design
• Protocol Buffers Documentation
• Apache Avro Format Specification

学習リソース

• AWS Skill Builder
• Serverless Land: EventBridge Patterns
• AWS Events Samples on GitHub
• AWS Compute Blog - EventBridge Articles

オーケストレーション関連（比較参照）

• Argo Workflows - Kubernetes-native Workflow Engine
• Temporal.io - Durable Execution Platform
• Serverless Workflow Specification

最終更新：2026-04-26
対応バージョン：EventBridge 2026 Q2 リリース
参考文献：20+件 / Mermaid 図：5+ 個