AWS國際帳號服務 AWS EventBridge 實戰：建構事件驅動的應用架構

# AWS EventBridge 實戰：建構事件驅動的應用架構

在搜尋「AWS EventBridge 實戰：建構事件驅動的應用架構」時，多數使用者通常不是想了解抽象概念，而是希望直接完成以下任務：

- 把 AWS 服務產生的事件串接到 Lambda、SQS、SNS 或 Step Functions
- 建立一套低耦合的事件通知流程
- 讓應用在資源狀態變更後自動執行處理邏輯
- 排查「規則已建立但目標沒觸發」這類常見問題
- 配置可觀察性、重試機制與失敗保護

這篇文章不講泛泛而談的原理，直接從控制台與實際配置切入，帶你完成一個可用的 AWS EventBridge 事件驅動架構，並補充排錯方法與配置建議。

---

## 一、這篇教程要解決什麼問題？

在實際專案中，常見需求包括：

1. EC2 狀態變更後自動通知或執行腳本
2. S3 上傳檔案後自動觸發處理程序
3. 訂單建立後將事件分發給多個後端服務
4. 定時執行任務取代傳統 crontab
5. 跨帳號、跨服務傳遞事件

很多人在操作時會卡在以下步驟：

- 不知道該用預設事件總線還是自訂事件總線
- 規則條件寫錯，導致事件根本沒被匹配
- EventBridge 有收到事件，但 Lambda 沒被觸發
- 權限不足，目標資源拒絕執行
- 事件格式不統一，後續服務難以消費
- 發生錯誤後沒有重試與死信佇列，導致事件遺失

下面我們用一個完整案例來操作。

---

AWS國際帳號服務 ## 二、實戰場景：用 EventBridge 串接訂單事件與 Lambda

### 場景目標

假設你有一個電商系統，當訂單建立時，應用程式會送出一筆事件到 EventBridge，接著由 EventBridge 根據規則觸發 Lambda 進行後續處理，例如：

- 寫入審計日誌
- 發送通知
- 呼叫下游服務

這種做法的關鍵是：前端應用只負責送事件，不需要直接依賴所有下游服務。

---

## 三、實作前的資源準備

開始前請先確認 AWS 帳號中具備以下權限：

- `events:*` 或至少具備 EventBridge 建立與管理規則的權限
- `lambda:*` 或至少具備建立函數、設定觸發器與權限的權限
- `iam:PassRole` 與相關 IAM 角色建立權限
- 如需 DLQ，還需要 SQS 建立與存取權限

建議準備以下資源：

- 一個 AWS Region，例如 `ap-northeast-1`
- 一個 Lambda 函數
- 一條 SQS 佇列作為死信佇列（可選但建議）
- 一個自訂 EventBridge Event Bus

> 建議先固定在單一 Region 操作。EventBridge、Lambda、SQS 多數情況下要位於相同 Region，避免初期因跨區域配置增加排錯難度。

---

## 四、建立 Lambda 處理函數

先建立事件接收端，避免 EventBridge 規則建立後沒有目標可測。

### 1. 在 AWS Lambda 建立函數

進入 AWS Console：

**Lambda → Create function**

選擇：

- Author from scratch
- Function name：`order-event-processor`
- Runtime：`Python 3.12`（也可用 Node.js）
- Execution role：建立新的基本執行角色

### 2. 範例程式碼

將函數程式碼改成以下內容：

```python
import json

def lambda_handler(event, context):
print("Received event:")
print(json.dumps(event))

detail = event.get("detail", {})
order_id = detail.get("orderId", "unknown")
status = detail.get("status", "unknown")

return {
"statusCode": 200,
"body": json.dumps({
"message": f"Processed order {order_id} with status {status}"
})
}
```

部署後，先不用手動測試，後續會由 EventBridge 觸發。

---

## 五、建立自訂 Event Bus

雖然很多 AWS 原生服務事件會送到預設 Event Bus，但如果你的應用事件來自自家系統，建議使用自訂 Event Bus，方便隔離不同業務事件。

### 1. 建立流程

進入：

**Amazon EventBridge → Event buses → Create event bus**

填寫：

- Name：`custom-app-bus`
- Description：可填 `Application events for order workflow`

建立完成後，記下 ARN，後續可能會用於程式發送事件與權限配置。

AWS國際帳號服務 ### 2. 什麼情況用預設 Bus？

以下情況多數使用預設 Bus：

- 監聽 EC2 狀態變更
- 監聽 CodePipeline 或 ECS 事件
- 監聽來自 AWS 服務的系統事件

以下情況建議用自訂 Bus：

- 自家應用透過 SDK 主動發送業務事件
- 不同團隊需要獨立管理事件規則
- 想隔離測試環境與正式環境事件流

---

## 六、從應用程式發送事件到 EventBridge

接下來建立事件來源。你可以用程式透過 AWS SDK 呼叫 `PutEvents`。

### Python 範例

```python
import boto3
import json

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

response = client.put_events(
Entries=[
{
'Source': 'custom.order-service',
'DetailType': 'OrderCreated',
'Detail': json.dumps({
'orderId': 'ORD-10001',
'status': 'CREATED',
'amount': 1200,
'customerId': 'CUST-9001'
}),
'EventBusName': 'custom-app-bus'
}
]
)

AWS國際帳號服務 print(response)
```

### 參數填寫建議

- `Source`：建議用固定命名，例如 `custom.order-service`
- `DetailType`：用業務事件名稱，例如 `OrderCreated`
- `Detail`：必須是 JSON 字串，不是 Python 字典
- `EventBusName`：填自訂 Bus 名稱或 ARN

### 常見錯誤

#### 錯誤 1：`Detail` 直接傳字典

錯誤示例：

```python
'Detail': {
'orderId': 'ORD-10001'
}
```

這會失敗，因為 `Detail` 必須是字串。請改成 `json.dumps()`。

#### 錯誤 2：Region 不一致

如果 SDK 呼叫的 Region 與 Event Bus 所在 Region 不同，事件不會送到你預期的資源。

#### 錯誤 3：權限不足

發送端 IAM 角色需具備：

```json
{
"Effect": "Allow",
"Action": "events:PutEvents",
"Resource": "arn:aws:events:ap-northeast-1:123456789012:event-bus/custom-app-bus"
}
```

---

## 七、建立 EventBridge 規則並綁定 Lambda

事件有了，接著建立匹配規則。

### 1. 建立規則

進入：

**Amazon EventBridge → Rules → Create rule**

填寫：

- Name：`match-order-created`
- Description：`Trigger Lambda when order is created`
- Event bus：選擇 `custom-app-bus`
- Rule type：`Rule with an event pattern`

### 2. 設定事件模式

選擇 **Custom pattern (JSON editor)**，填入：

```json
{
"source": ["custom.order-service"],
"detail-type": ["OrderCreated"],
"detail": {
"status": ["CREATED"]
}
}
```

AWS國際帳號服務 ### 3. 設定目標

Target 選擇：

- Target type：`AWS service`
- Select a target：`Lambda function`
- Function：`order-event-processor`

建立規則後，EventBridge 會自動嘗試為 Lambda 添加觸發權限。

---

## 八、測試整個事件流程

現在重新執行一次 `PutEvents` 程式。

### 驗證位置

#### 1. EventBridge 指標

進入規則頁面查看：

- Matched events
- Invocations
- Failed invocations

AWS國際帳號服務 #### 2. Lambda 日誌

進入：

**CloudWatch → Log groups → /aws/lambda/order-event-processor**

應能看到類似輸出：

```json
{
"version": "0",
"id": "xxxxx",
"detail-type": "OrderCreated",
"source": "custom.order-service",
"account": "123456789012",
"time": "2026-10-21T10:00:00Z",
"region": "ap-northeast-1",
"resources": [],
"detail": {
"orderId": "ORD-10001",
"status": "CREATED",
"amount": 1200,
"customerId": "CUST-9001"
}
}
```

如果這裡有事件內容，代表主流程已打通。

---

AWS國際帳號服務 ## 九、加上重試與死信佇列，避免事件丟失

實務上不能只做到「能觸發」，還要考慮目標執行失敗時怎麼處理。

### 1. 建立 SQS 死信佇列

進入：

**Amazon SQS → Create queue**

選擇：

- Type：Standard
- Name：`eventbridge-order-dlq`

建立完成後記下 ARN。

### 2. 在 EventBridge 規則中配置 DLQ

回到規則 `match-order-created`：

- Edit target
- Dead-letter queue：選擇剛建立的 SQS
- Retry policy：可設定最大重試次數與最長事件存活時間

### 3. 建議值

對多數一般業務事件，可先採用：

- Maximum retry attempts：`3`
- Maximum age of event：`1 hour`

如果你的 Lambda 是短時間偶發失敗，3 次重試通常足夠。

### 4. 適用場景

AWS國際帳號服務 以下情況建議一定要開 DLQ：

- 目標是 Lambda，但函數可能因依賴服務超時而失敗
- 下游偶發流量尖峰導致暫時錯誤
- 某些事件必須人工追查，不可直接遺失

---

## 十、設定 Input Transformer，讓目標只接收必要欄位

有些時候你不想讓 Lambda 收到完整 EventBridge 標準事件，而只想傳遞精簡資料。這時可使用 Input Transformer。

### 操作方式

編輯規則目標時，找到：

- Additional settings
- Configure input transformer

### 範例設定

#### Input paths

```json
{
"orderId": "$.detail.orderId",
"status": "$.detail.status",
"amount": "$.detail.amount"
}
```

#### Template

```json
{
"orderId": ,
"status": ,
"amount":
}
```

AWS國際帳號服務 ### 注意事項

- 模板格式錯誤會導致目標接收異常
- JSON 字串與數值類型要對應正確
- 若後端邏輯依賴 EventBridge 原始欄位，例如 `source`、`time`，就不要過度裁剪

如果你後面還要做審計、追蹤或除錯，建議先保留完整事件格式。

---

## 十一、實戰二：監聽 AWS 原生服務事件

除了應用自定義事件，EventBridge 也常用來接 AWS 資源變更事件。

下面示範監聽 EC2 實例狀態變更。

### 1. 建立規則

進入：

**EventBridge → Rules → Create rule**

選擇：

- Event bus：`default`
- Rule type：`Rule with an event pattern`

### 2. 事件模式

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

AWS國際帳號服務 ### 3. 設定目標

目標可以是：

- Lambda：執行後續自動化
- SNS：發送郵件通知
- SQS：交給後端異步處理

### 常見用途

- EC2 啟動後自動註冊到資產系統
- EC2 停止後通知維運人員
- 依狀態變更執行標籤同步或審計記錄

---

## 十二、EventBridge 排程任務配置

很多人會用 EventBridge 取代傳統伺服器上的 crontab，尤其在無伺服器架構中很常見。

### 建立方式

建立規則時可選擇：

- Rule type：`Schedule`

### 常見表示式

#### 每 5 分鐘執行

```text
rate(5 minutes)
```

#### 每天 UTC 1 點執行

```text
cron(0 1 * * ? *)
```

### 操作建議

- 若你預期的是台北時間，請記得 EventBridge 排程預設以 UTC 為主
- 若任務具備冪等性要求，Lambda 內部要避免重複執行造成資料重覆寫入
- 如任務很重要，也建議加上 DLQ 與 CloudWatch Alarm

---

## 十三、常見故障排查：規則建立好了，但 Lambda 沒觸發

這是最常見的問題。建議按下面順序檢查。

AWS國際帳號服務 ### 1. 先確認事件是否真的送到正確 Event Bus

檢查項目：

AWS國際帳號服務 - `EventBusName` 是否正確
- Region 是否一致
- `PutEvents` 回傳中 `FailedEntryCount` 是否為 0

範例：

```python
print(response)
```

如果看到 `FailedEntryCount` 大於 0，先修正發送端問題。

### 2. 檢查事件模式是否匹配

最容易出錯的是以下欄位：

- `source`
- `detail-type`
- `detail` 內部欄位值大小寫

例如你送出的事件是：

```json
{
"source": "custom.order-service",
"detail-type": "OrderCreated",
"detail": {
"status": "created"
}
}
```

但規則寫的是：

```json
"status": ["CREATED"]
```

這樣不會匹配，因為大小寫不同。

### 3. 檢查 Lambda 資源政策

EventBridge 需要被允許呼叫 Lambda。正常在控制台新增目標時會自動處理，但若你透過 IaC 或手動調整過，可能缺失。

你可以在 Lambda 的 Resource-based policy 中確認是否存在類似：

```json
{
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "lambda:InvokeFunction"
}
```

### 4. 檢查 Lambda 本身是否報錯

如果 EventBridge 已成功調用，但 Lambda 內部錯誤，請查看 CloudWatch Logs：

- 程式碼異常
- 權限不足
- 連接資料庫失敗
- 超時
- 記憶體不足

### 5. 檢查規則是否啟用

看似簡單，但很多測試環境問題就出在 Rule 被設成 `Disabled`。

---

## 十四、常見故障排查：事件過濾條件寫不對

事件模式是 EventBridge 使用中最常踩雷的部分。

### 問題 1：欄位層級寫錯

如果事件實際結構是：

```json
{
"detail": {
"order": {
"status": "CREATED"
}
}
}
```

那規則就不能寫成：

```json
"detail": {
"status": ["CREATED"]
}
```

要改成：

```json
"detail": {
"order": {
"status": ["CREATED"]
}
}
```

### 問題 2：數值與字串型別不一致

例如事件內容：

```json
"amount": 1200
```

規則卻寫成：

```json
"amount": ["1200"]
```

AWS國際帳號服務 也可能不匹配。建議確保發送端與規則中的型別一致。

### 問題 3：過濾條件寫太死

如果測試環境事件內容經常變動，不要一開始就加很多限制欄位。先只匹配：

- `source`
- `detail-type`

等主鏈路驗證成功，再逐步細化條件。

AWS國際帳號服務 ---

## 十五、權限配置建議

EventBridge 架構中，權限通常分成兩段。

AWS國際帳號服務 ### 1. 發送事件的權限

應用或 Lambda 若要呼叫 `PutEvents`，需要：

```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "events:PutEvents",
"Resource": "arn:aws:events:ap-northeast-1:123456789012:event-bus/custom-app-bus"
}
]
}
```

### 2. 目標接收事件的權限

- Lambda：需允許 `events.amazonaws.com` 呼叫
- SQS：需允許 EventBridge 傳送訊息
- SNS：需允許 EventBridge 發佈訊息
- Step Functions：需允許啟動狀態機執行

AWS國際帳號服務 ### 最佳實踐

- 不要直接給 `Resource: *`，盡量限定特定 Event Bus 或目標 ARN
- 測試環境與正式環境分開 IAM Role
- 若跨帳號發送事件，需同時處理資源政策與角色授權

---

## 十六、用 Terraform 或 CloudFormation 管理會更穩定

在團隊環境中，不建議長期只靠控制台手動建立規則。原因很直接：

- 規則多了之後難追蹤
- 權限設定容易遺漏
- 換人維護時不清楚誰改過什麼
- 測試與正式環境難保持一致

如果你已經在用 Terraform，建議至少把以下資源納入：

- Event Bus
- Rule
- Target
- Lambda permission
- SQS DLQ
- CloudWatch Alarm

這樣在重建環境、版本回滾與審計時都更省事。

---

## 十七、架構設計上的實用建議

這裡補充幾個在實務中很有用的做法。

### 1. 事件名稱保持穩定

建議統一格式：

- `Source`：`custom.order-service`
- `DetailType`：`OrderCreated`

不要今天叫 `create-order`，明天叫 `order_created`，否則規則會變得難維護。

### 2. Detail 內容保留必要上下文

至少建議包含：

- 業務主鍵，如 `orderId`
- 狀態，如 `status`
- 發生時間，如 `occurredAt`
- 追蹤欄位，如 `traceId`

這些資訊對排錯非常有幫助。

### 3. 消費端邏輯做冪等處理

Event-driven 架構下，重試與重送是常見情況。Lambda 或後端服務應能處理重複事件，不要收到兩次就寫出兩筆資料。

### 4. 不要在單一規則塞過多責任

若一個事件要通知三個系統，讓 EventBridge 綁定多個目標，或拆多條規則，不要把所有邏輯都寫死在一個 Lambda 中。

這樣後續擴充與維護都更容易。

---

## 十八、從零到可用的最小落地流程回顧

如果你現在要快速上線一個 EventBridge 流程，可以照這個順序：

1. 建立 Lambda 處理函數
2. 建立自訂 Event Bus
3. 用 SDK 呼叫 `PutEvents` 發送測試事件
4. 建立 EventBridge Rule，匹配 `source` 與 `detail-type`
5. 將 Rule 綁定到 Lambda
6. 測試事件流是否能在 CloudWatch Logs 中看到
7. 補上 DLQ、重試策略與告警
8. 最後再收斂事件過濾條件與輸入格式

這樣能先保證流程通，再逐步優化，而不是一開始就陷入複雜配置。

---

## 十九、結語

AWS EventBridge 真正的價值不在於「把事件發出去」，而在於你能不能把事件流配置得可維護、可排錯、可重試。

在實際操作中，最常見的問題不是服務本身不可用，而是：

- 事件送錯 Bus
- 規則模式不匹配
- 權限缺失
- 目標失敗後沒有保護機制

因此，建議你在建構事件驅動架構時，優先把以下四件事做好：

- 命名規範固定
- 規則條件先簡後繁
- 失敗重試與 DLQ 補齊
- CloudWatch 日誌與指標能快速定位問題

只要這些基礎配置做好，EventBridge 在 AWS 內部串接 Lambda、SQS、SNS、Step Functions 會非常順手，也更適合逐步把原本耦合的同步流程拆成事件驅動流程。

如果你下一步準備把 EventBridge 串接到 SQS、Step Functions，或想做跨帳號事件路由，也可以在這套配置基礎上繼續擴展。