甚麼 EventBridge

傳統在執行指令時都是等待完整的指令後才執行

這些批次執行的程式雖然沒有其他問題

但是對於越來越多複雜的功能

大家開始思考有沒有可能根據不同事件來執行這些指令

事件驅動架構也就因應而生

在 AWS 中 EventBridge 就是很經典的例子

一個基於事件驅動架構的全託管式服務

傳統的系統維護我們都必須按需執行指令

在事件驅動架構下

我們可以基於事件來執行程式

對於系統的維運更簡潔也更有效率。

EventBridge 的應用場景

EventBridge 有兩大應用場景

一個是事件匯流排

也就是抓取事件後執行相對應的動作

另一個則是排程器

也就是大家所知道的 Cronjob

其實官網有提到三個，不過那個我並不清楚

事件匯流排

事件匯流排大家可以理解成 IFTTT

當 A Event 發生時

我們需要去執行 B 這個 Bridge 的動作

排程器

而排程器相信許多維運過系統的就更不陌生

近年來許多企業爭相導入 ESG

在節能減碳的背景下

如果大家要實作週五半夜關機、週一凌晨開機

就會是相當實用的一個功能

使用 EventBridge 實作 Patch Manager 上完 Patch 後需要重新開機的通知

建立 SNS 主題和訂閱

這個有點簡單

就交給各位自己設定了

建立 EventBridge 規則

在 EventBridge 的首頁

就可以很快地看到建立規則的頁面

在事件匯流排中

有個設定非常重要

如果要抓取 AWS 上的事件

一定只能選擇 default

在建立方法中我們可以無視上方的設定

上方的設定只是提供相對應的範本

主要是下方的設定

當 Patch Manager 更新完 EC2 後

如果 EC2 是需要重新開機的

會將這台 EC2 標示為不合規

而我們就可以透過抓到這個上完 Patch 後的不合規事件

做到即時的通知

{
  "source": ["aws.ssm"],
  "detail-type": ["Configuration Compliance State Change"],
  "detail": {
    "compliance-type": ["Patch"],
    "compliance-status": ["non_compliant"],
    "resource-type": ["managed-instance"],
    "resource-id": ["{填入你的 EC2 ID}"]
  }
}

在最後一步選擇要執行的步驟就好了

我們可以選擇 SNS 服務

因為 SNS 的設定有些簡單

這部分大家就自己做完後

再按下重新整理就可以選到 SNS 的主題了

參考資料：

1. 什麼是事件驅動型架構？
2. Amazon EventBridge
3. 什麼是亞馬遜EventBridge?
4. 從理論到實踐！以事件驅動架構打造現代化應用程式 - 深入探索 Amazon EventBridge 的 Event 及 Scheduler