訊息、解耦與事件驅動模式

AWS 訊息傳遞與解耦服務讓你把單體式應用程式拆分成獨立的元件，透過非同步、可靠的通道彼此溝通。SAA-C03 考試指南的任務敘述 2.1 要求你「設計可擴展且鬆散耦合的架構」，而 AWS 訊息傳遞與解耦服務正是完成這項任務的最大工具箱。本章逐一介紹 Amazon SQS、Amazon SNS、Amazon EventBridge、AWS Step Functions 與 Amazon MQ，以及解決方案架構師在考場壓力下必須能夠辨識的各種模式。在真實的 SAA-C03 考試中，預計會有 6–9 道情境題涉及 AWS 訊息傳遞與解耦。

什麼是 AWS 訊息傳遞與解耦？

AWS 訊息傳遞與解耦是 AWS 上負責在元件之間傳遞資料、事件與指令的服務家族，而且不強迫生產者與消費者同時上線。在 SAA-C03 考試中，只要情境提到「鬆散耦合」、「非同步」、「應對流量峰值」、「層間緩衝」、「重試失敗工作」或「扇出至多個訂閱者」，AWS 訊息傳遞與解耦就是答案。只要生產者能夠交出工作後就離開，這就是訊息傳遞與解耦的題型。

在 Associate 等級，SAA-C03 考試指南期望你能夠：

• 以名稱與一句話使用情境認出每一個 AWS 訊息傳遞與解耦服務。
• 在情境題中區分 Amazon SQS（佇列）、Amazon SNS（發布訂閱）與 Amazon EventBridge（事件匯流排）。
• 了解何時以 AWS Step Functions 取代手刻的編排邏輯，以及何時在 lift-and-shift 遷移中以 Amazon MQ 取代 Apache ActiveMQ 或 RabbitMQ。
• 正確選擇 SQS Standard vs FIFO、Step Functions Standard vs Express，以及 SNS vs EventBridge 的扇出場景。
• 將解耦模式——佇列式負載平衡、扇出、協作式 vs 編排式——套用至真實架構。

AWS 訊息傳遞與解耦的範疇與 serverless-and-containers（任務 2.1，Lambda 是最常見的消費者）以及 streaming-data-kinesis（任務 3.5，Kinesis 處理 SQS 無法重播的即時分析串流）有所重疊。本筆記頁聚焦在「選擇正確整合模式」這一層，串流分析則留給專屬主題討論。

為什麼 AWS 訊息傳遞與解耦在 SAA-C03 至關重要

AWS 訊息傳遞與解耦在歷史上是 Domain 2 測驗最重的領域之一。社群資料顯示「SQS vs SNS vs EventBridge」穩居 SAA-C03 最常考主題群的前三名。掌握 AWS 訊息傳遞與解耦，能鎖定 Domain 2（佔考試 26%）的大量分數，並直接串連 high-availability-multi-az、serverless-and-containers 與 api-gateway-and-edge 等題目。精通 AWS 訊息傳遞與解耦，也是在情境題中「以解決方案架構師的思維作答」最快的途徑——架構師幾乎永遠偏好解耦設計而非緊密耦合。

白話文解釋 AWS 訊息傳遞與解耦

AWS 訊息傳遞與解耦是 AWS 上把系統「拆開、非同步溝通」的服務家族。要直覺理解它，最好的方法是套用三個完全不同領域的類比。

類比一——夜市攤位生態系統

把 AWS 訊息傳遞與解耦想成一個台灣夜市的運作系統：

• Amazon SQS = 叫號單（取餐號碼牌）。客人（生產者）點完餐後拿一張號碼牌離開等候。廚師（消費者）備好餐點後呼叫號碼。如果廚師中途出包（失敗），號碼牌會重新被放回等候區（visibility timeout 到期），由其他人重新處理。每張號碼牌只屬於一個客人。這就是點對點傳訊。
• Amazon SNS = 廣播喇叭（攤位廣播）。攤主拿起麥克風廣播一聲，整條夜市所有訂閱這個頻道的人（手機 App 通知、簡訊、Lambda、SQS）同時收到同一則訊息。這就是發布訂閱扇出。
• Amazon EventBridge = 智慧管理中心（夜市總管）。每筆事件都帶著標籤說明內容（誰的攤位、什麼事件）。總管讀取標籤後依規則把事件送往對應的處理單位——熱食區插隊觸發警示、VIP 訂位取消觸發道歉簡訊、POS 刷卡超過特定金額觸發財務記錄。這就是事件路由。
• AWS Step Functions = 夜市活動流程主持人。主持人手持完整的流程表：報名、抽籤、備料、競賽、頒獎、散場。每一步都有明確的負責人，任何一步出問題，主持人知道要重試、替補還是中止。
• Amazon MQ = 老店的傳統廣播電台。老攤主用的收音機頻道（AMQP、MQTT、STOMP、JMS），因為設備還沒換，所以繼續保留著。

這個類比清楚說明了為什麼 SQS 是一對一而 SNS 是一對多，以及為什麼 EventBridge 比 SNS「更聰明」——總管會讀標籤；廣播喇叭不會。

類比二——台鐵票務系統

現在把 AWS 訊息傳遞與解耦對應到台鐵的票務流程：

• Amazon SQS = 購票待辦窗口（排隊叫號）。旅客（訊息）在窗口前排隊，輪到哪個窗口（消費者）就由哪個窗口服務。如果窗口中途當機（失敗），這張票（訊息）在 visibility timeout 到期後重新排回隊伍，讓下一個窗口處理。如果同一張票反覆處理失敗，就送往「問題票務回報台」（dead-letter queue）供主管（開發者）調查。
• Amazon SNS = 全站廣播系統。一列火車誤點，總站廣播同時通知月台旅客、App 推播、SMS 簡訊、客服系統，所有訂閱這個頻道的對象同時收到。
• Amazon EventBridge = 調度控制中心。來自各車站的感測器、第三方平台（訂票網站、旅遊 App）不斷把事件送進控制中心。規則決定誰要行動：某班車延誤超過 30 分鐘，觸發候補旅客通知；某張票被退票，觸發候補名單補位流程；跨站事件也能透過 SaaS 夥伴事件匯流排整合進來。
• AWS Step Functions = 鐵路調度長（手持完整調度令）。多步驟事故應變：接獲回報、判斷等級、調度備用車廂、通知後續站點、記錄日誌、結案。調度長掌握整個狀態機，知道任何一步超時該怎麼辦。
• Amazon MQ = 舊式無線對講機系統。調度員與司機還在用，因為車載設備還沒全面汰換。

這個類比抓住了為什麼各個 AWS 訊息傳遞與解耦服務形狀各異——排隊叫號根本不同於全站廣播，也根本不同於調度令。

類比三——城市交通系統

最後，把 AWS 訊息傳遞與解耦想像成城市的交通基礎設施：

• Amazon SQS = 計程車招呼站。旅客（訊息）在招呼站依序等候，下一輛空車（消費者工作者）接走一位旅客，不重複。FIFO 佇列保證先到先服務的順序；Standard 佇列偶爾順序略有不同，但每秒能承載更多旅客。
• Amazon SNS = 緊急廣播系統。一個警報聲同時觸發所有廣播電台、電視台和手機的緊急通知——一對多廣播。
• Amazon EventBridge = 城市交通控制中心。感測器、攝影機和第三方 App（Google Maps、Waze）都把事件送入同一個控制中心。規則決定誰行動：車輛拋錨觸發拖吊規則；火災觸發消防規則；VIP 車隊觸發警察護送規則。
• AWS Step Functions = 救護車調度員。多步驟緊急應變：接線、分類、派車、通知醫院、追蹤抵達。調度員掌握整個狀態機，知道任何一步超時要怎麼處理。
• Amazon MQ = 舊式無線電波段。計程車司機和調度員還在用，因為車載對講機還沒換新。

三個不同的類比強化了同一套決策框架：一對一佇列（SQS）、一對多廣播（SNS）、規則路由（EventBridge）、多步驟編排（Step Functions）、舊協定相容（MQ）。記住這五個定位，大多數 SAA-C03 訊息傳遞與解耦情境題就會自動浮現答案。

AWS 訊息傳遞與解耦的核心運作原則

每個 AWS 訊息傳遞與解耦服務都共享相同的底層原則。記住這些原則有助於在 SAA-C03 中回答模糊的情境題。

原則一——生產者與消費者永遠不互相等待

解耦系統意味著生產者交出訊息後就繼續做自己的事。消費者以自己的速度處理，可能在幾分鐘或數小時後才處理，也可能與其他 10,000 個消費者工作者並行進行。這就是為什麼每當題目提到「流量峰值」、「下游系統速度慢」或「處理速率不穩定」，AWS 訊息傳遞與解耦就是 SAA-C03 的答案。

原則二——訊息持久且可重播（在限制範圍內）

所有 AWS 訊息傳遞與解耦服務預設提供至少一次（at-least-once）的持久性。SQS 最多保留訊息 14 天（預設 4 天）。SNS 持久儲存訊息，直到成功傳遞給每個訂閱者並完成失敗重試。EventBridge 的重試時間最多 24 小時。Step Functions Standard 保留執行歷史 90 天。Amazon MQ 根據你的 broker 設定保留訊息。當題目問到「重試失敗工作」或「在中斷期間緩衝」，AWS 訊息傳遞與解耦就是正確的方向。

原則三——恰好一次代價高昂；至少一次是預設值

SQS Standard、SNS 與 EventBridge 預設以至少一次（at-least-once）傳遞——也就是說，同一則訊息偶爾可能被傳送兩次，消費者必須具備冪等性（idempotent）。SQS FIFO 以及 Step Functions Express（搭配冪等性 token）和 Standard 可以達到恰好一次（exactly-once）處理，但代價是較低的吞吐量。在 SAA-C03 中，留意「不能允許重複處理」或「金融交易」等信號——這些指向 FIFO 或明確的冪等性設計。

Amazon SQS — Simple Queue Service 深度解析

Amazon SQS 是最古老的 AWS 訊息傳遞與解耦服務，也是 SAA-C03 中測驗最多的一個。每當情境需要在兩個層之間建立持久、點對點的佇列，SQS 就是預設答案。Amazon SQS 保存訊息，讓一個消費者恰好取得每則訊息一次（Standard 是至少一次），若消費者崩潰則透明地重試。

Amazon SQS 是什麼？

Amazon SQS 是一個完全受管的拉取式（pull-based）訊息佇列服務。生產者呼叫 SendMessage 將訊息放入佇列；消費者呼叫 ReceiveMessage 拉取訊息。SQS 按百萬次請求計費，而非按訊息保留時間計費，因此即使在高吞吐量下也具成本效益。Amazon SQS 是無伺服器的——不需要調整 broker 大小，也沒有叢集需要修補。

SQS 有兩種佇列類型：Standard（預設）與 FIFO（先進先出，有序）。正確選擇兩者是 SAA-C03 AWS 訊息傳遞與解耦中最常見的陷阱之一。

SQS Standard vs SQS FIFO

SQS Visibility Timeout

當消費者呼叫 ReceiveMessage 時，SQS 會將該訊息對其他消費者隱藏一段可設定的時間，稱為 visibility timeout（預設 30 秒，最長 12 小時）。如果消費者在這段時間內完成處理並呼叫 DeleteMessage，訊息就會消失。如果消費者崩潰或 timeout 先到期，訊息會重新變為可見，讓另一個消費者接手。

調整 visibility timeout 是 SAA-C03 的經典信號：

• 太短：處理速度慢的消費者還在處理，但 timeout 已到期，第二個工作者已開始處理同一則訊息 → 重複。
• 太長：如果消費者崩潰，訊息在重新被重試之前會保持隱藏數小時 → 延遲。
• 解法：將 visibility timeout 設定為大約 99th percentile 處理時間，或在長時間工作處理途中呼叫 ChangeMessageVisibility 延長時間。

SQS Dead-Letter Queue（DLQ）

**dead-letter queue（DLQ）**是第二個 SQS 佇列，用於接收在 N 次嘗試後仍未成功處理的訊息（maxReceiveCount 重送門檻）。DLQ 是 SAA-C03 中「在不阻塞主佇列的情況下調查毒藥訊息」的答案。

必須記住的 DLQ 重點：

• Standard 佇列的 DLQ 也必須是 Standard；FIFO 佇列的 DLQ 也必須是 FIFO。
• DLQ 中的訊息保留原始的接收計數，讓你調查哪些訊息反覆失敗。
• 底層 bug 修復後，可以透過 SQS redrive API 將訊息從 DLQ 重新導回來源佇列。
• 對於一般工作負載，maxReceiveCount 設定在 5 到 10 之間。太低會讓不穩定的訊息過早被丟棄；太高則讓真正有問題的訊息持續消耗消費者資源。

SQS Long Polling vs Short Polling

SQS 消費者有兩種拉取訊息的方式：

• Short polling（預設）：ReceiveMessage 立即返回，即使佇列為空。每次請求成本較低，但如果頻繁輪詢，會浪費 API 呼叫。
• Long polling：將 WaitTimeSeconds 設為 1–20 秒。呼叫會阻塞，直到有訊息到達或 timeout 到期。Long polling 大幅減少空回應和 API 總成本，並降低消費者延遲。

對於幾乎所有生產工作負載，請啟用 20 秒等待時間的 long polling。在 SAA-C03 中，「減少 SQS API 成本」或「減少空回應」→ long polling。

SQS 訊息保留、大小與批次

記住這些 SAA-C03 必考的 SQS 數字：

• 訊息保留：1 分鐘到 14 天（預設 4 天）。
• 最大訊息大小：256 KB。若需傳送更大的酬載，使用 Extended Client Library 儲存至 S3 並只傳送參考（支援最多 2 GB）。
• 批次操作：SendMessageBatch、ReceiveMessage（最多 10 則訊息）、DeleteMessageBatch——每批次最多 10 則訊息，256 KB 聚合上限。
• 延遲佇列：訊息最多可延遲 15 分鐘後才變為可見。
• Visibility timeout：0 秒到 12 小時（預設 30 秒）。

何時使用 Amazon SQS

• 在使用者面向層與處理速度較慢的工作者層之間做緩衝。
• 解耦不應同步互相呼叫的微服務。
• 平滑流量峰值，讓下游系統能以自己的速度處理。
• 將工作分配給 Auto Scaling Group 背後的消費者工作者群。
• 為不穩定的下游系統實作 retry-with-DLQ 模式。

Amazon SNS — Simple Notification Service 深度解析

Amazon SNS 是 SQS 的推送式兄弟服務。SQS 是拉取式佇列、一對一消費；Amazon SNS 則是發布訂閱主題、一對多廣播。SNS 是扇出情境下 AWS 訊息傳遞與解耦的預設答案。

Amazon SNS 是什麼？

Amazon SNS 將每則發布的訊息傳遞給主題的每一個訂閱者。一次 Publish 呼叫可以同時送達 100+ 個訂閱者，每個都是不同的協定（SQS 佇列、Lambda 函數、HTTP/S 端點、電子郵件地址、SMS 號碼、行動推播通知、Kinesis Data Firehose 或其他 AWS 服務）。SNS 是推送式的——你不需要輪詢主題；訂閱者會主動收到訊息。

SNS 主題與訂閱

SNS 中的兩個主要物件：

• 主題（Topic）：生產者發布訊息的命名頻道。主題有 ARN 與存取政策。
• 訂閱（Subscription）：主題與傳遞目標（SQS 佇列、Lambda 函數、電子郵件等）之間的綁定。每個訂閱有自己的過濾政策與傳遞重試設定。

SNS 支援兩種主題類型：

• Standard 主題：高吞吐量、盡力排序、至少一次傳遞。
• FIFO 主題：嚴格排序與恰好一次發布，但限制 300 TPS。FIFO 主題只能傳遞至 SQS FIFO 佇列（不支援 Lambda、HTTP 或電子郵件）。

SNS 扇出模式

經典的 SNS 扇出模式將一個 SNS 主題與多個 SQS 佇列作為訂閱者配對。每個下游服務擁有自己的佇列，以自己的速度處理，可以離線而不阻塞發布者。日後新增訂閱者是零程式碼的變更——只需再訂閱一個佇列。這是 AWS 訊息傳遞與解耦中最常考的 SAA-C03 模式。

生產者 → SNS 主題 → SQS 佇列 A → 工作者群 A
                  → SQS 佇列 B → 工作者群 B
                  → SQS 佇列 C → Lambda 函數 C

SNS 訊息過濾

若不設定過濾，每個訂閱者都會收到每則訊息。訊息過濾（訂閱上的過濾政策）讓訂閱者可以說「只傳遞 eventType=OrderCreated 的訊息」。過濾發生在 SNS 端，被過濾掉的訊息永遠不會產生下游成本。

過濾政策是匹配訊息屬性（非訊息主體，除非你啟用主體過濾）的 JSON 文件。典型的 SAA-C03 信號：

• 「多個下游服務各自只對部分事件感興趣」→ SNS 過濾政策。
• 「避免傳送工作者不在乎的訊息」→ SNS 過濾政策。

SNS 傳遞協定

SNS 可以傳遞至：

• Amazon SQS（Standard 與 FIFO 皆支援）。
• AWS Lambda（同步調用，SNS 在失敗時重試）。
• HTTP / HTTPS 端點（webhook，具指數退避重試）。
• Email / Email-JSON（人工通知）。
• SMS（向電話號碼傳送簡訊；依地區而定）。
• 行動推播（APNs、FCM、ADM、Baidu）。
• Amazon Kinesis Data Firehose（用於封存與分析）。

SNS 傳遞重試與 DLQ

SNS 以指數退避方式重試失敗的傳遞。HTTP/HTTPS 預設重試 3 次快速 + 50,000 次慢速，持續 22 天。Lambda 重試 3 次。重試後仍失敗的訊息可以送往 SNS dead-letter queue（實際上是 SQS 佇列）供調查。生產環境的 SNS 訂閱務必設定 DLQ。

何時使用 Amazon SNS

• 一個事件必須觸發多個獨立的下游動作。
• 同時向電子郵件、SMS 與工單系統廣播操作警示。
• 除了系統之外，還需要通知人類（電子郵件、SMS、行動推播）。
• 與 SQS 結合建構彈性的扇出管線。

Amazon EventBridge — 事件驅動整合深度解析

Amazon EventBridge 是 SNS 更新、更精密的兄弟服務。SNS 最適合簡單廣播；Amazon EventBridge 最適合跨多個事件來源的規則路由——包括 AWS 服務、SaaS 夥伴與你自己的應用程式。

Amazon EventBridge 是什麼？

Amazon EventBridge 是一個無伺服器事件匯流排，從生產者擷取事件，並根據宣告式規則將事件路由至目標。EventBridge 可擴展至每秒數百萬個事件，支援跨帳號與跨區域路由，並原生整合 200+ 個 AWS 服務作為來源與目標。

事件匯流排（Event Buses）

事件匯流排是 EventBridge 內部的命名頻道。三種類型：

• 預設事件匯流排：每個 AWS 帳號每個區域各一個，自動接收 AWS 服務的事件（EC2 狀態變化、S3 事件、CodePipeline 事件等）。
• 自訂事件匯流排：你為自己的應用程式事件建立。適合隔離不同領域或團隊。
• 夥伴事件匯流排：當你訂閱 SaaS 夥伴（Zendesk、Datadog、Auth0、Shopify 等）時自動建立。夥伴直接發布至你的 EventBridge。

規則（Rules）

規則匹配匯流排上的事件並將其路由至一個或多個目標。規則使用 JSON 事件模式，可匹配 source、detail-type 與 detail 內部任意欄位的組合。一條規則最多可有 5 個目標。目標包括 Lambda 函數、SQS 佇列、SNS 主題、Step Functions 狀態機、Kinesis 串流、ECS 任務、SSM Run Command、跨帳號事件匯流排等。

兩種規則類型：

• 事件模式規則：匹配傳入事件（最常見的情況）。
• 排程規則：cron 或 rate 表達式（取代舊版「CloudWatch Events Scheduler」）。對於更豐富的排程需求，新工作負載現在優先使用 EventBridge Scheduler。

EventBridge Schema Registry

EventBridge Schema Registry 自動從流經匯流排的事件中發現 schema，並產生程式碼綁定（Java、Python、TypeScript、Go），讓開發者在撰寫事件處理器時能獲得自動完成與型別安全。在 SAA-C03 中，你只需認識這個概念——「schema registry = 集中式事件 schema 目錄，含程式碼綁定」。

跨帳號與跨區域事件路由

EventBridge 支援：

• 跨帳號：帳號 A 的匯流排上的規則可以指向帳號 B 的匯流排。這是在多帳號 AWS Organization 中集中事件的方式。
• 跨區域：EventBridge 全球端點自動將事件複寫到次要區域以進行災難復原。
• 封存與重播：EventBridge 可以按可設定的保留期封存事件，然後重播這些事件以重建下游系統的狀態。

SNS vs EventBridge — 重大決策

SNS 與 EventBridge 都能做扇出。SAA-C03 考試期望你正確選擇。

經驗法則：

• 選 SNS：純粹扇出至 SQS、Lambda、電子郵件/SMS 與行動推播。SNS 更便宜且更簡單。
• 選 EventBridge：需要消費原生 AWS 服務事件、SaaS 夥伴事件、豐富的內容過濾、schema 發現或事件封存/重播。
• 兩者都有效：許多扇出模式兩者皆可——依事件來源多樣性與過濾需求做選擇。

AWS Step Functions — 工作流程編排深度解析

AWS Step Functions 將多步驟工作流程編排為視覺化狀態機。它是 AWS 訊息傳遞與解耦中「多個服務各做一件事，以特定順序呼叫，具分支、重試與錯誤處理」的答案。

AWS Step Functions 是什麼？

AWS Step Functions 讓你以 JSON 狀態機（Amazon States Language，ASL）定義工作流程。每個狀態代表一個工作單元：Lambda 調用、ECS 任務執行、DynamoDB 操作、人工審批、平行分支、選擇、等待、映射。Step Functions 自動處理重試、超時與錯誤轉換。視覺化主控台逐步顯示執行歷史，對除錯非常有幫助。

Step Functions Standard vs Express 工作流程

Step Functions 提供兩種工作流程類型，SAA-C03 考試可靠地測驗兩者的邊界。

選 Standard 的情況：ETL 編排、訂單履行、ML 訓練管線、人工審批工作流程、任何執行時間超過 5 分鐘或需要稽核品質執行歷史的情境。

選 Express 的情況：高量 IoT 事件處理、串流資料轉換、規模化的微服務編排——任何在 5 分鐘內且需要極高吞吐量的情境。

服務整合

Step Functions 透過以下方式整合 200+ 個 AWS 服務：

• 最佳化整合：Lambda、DynamoDB、SQS、SNS、ECS、Batch、Glue、SageMaker、EMR、API Gateway、EventBridge 等。這些是內建連接器，只需少量黏合程式碼。
• AWS SDK 整合：直接從狀態機呼叫任何 AWS API，無需撰寫 Lambda 包裝器。
• HTTP 任務：透過 EventBridge API destinations 呼叫外部 API。

常見的 Step Functions 模式

• Saga 模式：編排多步驟的分散式交易，在失敗時執行補償動作（退款、取消、回滾）。
• 回呼與任務 token：暫停工作流程，等待外部系統回報（例如：人工審批、長時間執行的 ECS 任務）。
• Map 狀態：以可設定並行度對陣列中的每個項目進行平行扇出處理。
• Parallel 狀態：並行執行獨立分支並合併結果。

何時選擇 Step Functions vs 其他替代方案

• 「有分支與重試的步驟序列」→ Step Functions（而非一堆互相呼叫的 Lambda）。
• 「長時間執行、多階段的業務工作流程」→ Step Functions Standard。
• 「每天數百萬個短暫事件工作流程」→ Step Functions Express。
• 「扇出至多個獨立服務」→ SNS 或 EventBridge（Step Functions 對一次性扇出而言過於複雜）。
• 「點對點持久佇列」→ SQS（Step Functions 過於複雜）。

Amazon MQ — 遷移用受管訊息 Broker

Amazon MQ 是 Apache ActiveMQ 與 RabbitMQ 的受管訊息 broker 服務。它的存在主要是為了讓使用標準訊息協定（JMS、AMQP 0-9-1、AMQP 1.0、MQTT、OpenWire、STOMP）的現有應用程式能夠遷移至 AWS，而無需重寫訊息層。

Amazon MQ 是什麼？

Amazon MQ 為你佈建與管理 ActiveMQ 或 RabbitMQ broker——修補、容錯移轉、備份、網路整合。你使用與本地相同的協定和客戶端程式庫連接應用程式。對於新應用程式，優先使用 SQS、SNS 或 EventBridge——它們更便宜、無伺服器且更具彈性。對於遷移現有 JMS/AMQP 應用程式，Amazon MQ 是正確答案。

ActiveMQ vs RabbitMQ 選擇

• ActiveMQ：支援 JMS、AMQP 1.0、OpenWire、STOMP、MQTT。當遷移使用 JMS 的 Java 應用程式或需要廣泛協定支援時選擇。
• RabbitMQ：支援 AMQP 0-9-1。當你的應用程式是在本地基於 RabbitMQ 建構且使用 AMQP 原生功能（exchanges、bindings、routing keys）時選擇。

Amazon MQ 部署選項

• 單一執行個體 broker：開發/測試。不具 HA。
• 主動/待機 broker：雙 AZ HA，具自動容錯移轉（ActiveMQ 的典型生產選擇）。
• 叢集部署（RabbitMQ）：多節點，提供 HA 與擴展性。

SAA-C03 何時選 Amazon MQ

只有當題目明確提到以下情況，Amazon MQ 才是正確答案：

• 「將現有 ActiveMQ / RabbitMQ 應用程式遷移至 AWS。」
• 「應用程式使用 JMS / AMQP / MQTT / STOMP / OpenWire。」
• 「無法重寫訊息層。」
• 「Lift-and-shift 基於訊息 broker 的工作負載。」

如果題目沒有提到這些信號，選 SQS/SNS/EventBridge——它們更便宜且更原生 AWS。

SAA-C03 考生必知的解耦模式

AWS 訊息傳遞與解耦服務是積木。將它們組合成命名模式，才是工程師與解決方案架構師的分水嶺。

模式一——佇列式負載平衡

生產者可能暫時產生比消費者能處理更多的工作時，推入 SQS 佇列。Auto Scaling Group 背後的消費者工作者在 ApproximateNumberOfMessagesVisible 超過門檻時自動擴展。這將尖峰流量平滑為穩定的處理速率，是考試中最常見的 AWS 訊息傳遞與解耦模式。

模式二——SNS + SQS 扇出

一個生產者，多個獨立消費者。生產者發布至 SNS 主題。每個消費者擁有自己訂閱該主題的 SQS 佇列。每個消費者以自己的速度處理，可以獨立失敗，日後可以在不更改生產者的情況下新增。這是事件驅動微服務的標準 SAA-C03 模式。

模式三——EventBridge 事件驅動路由

多個生產者（包括 AWS 服務與 SaaS 夥伴），多條規則，多個目標。生產者將事件發送至 EventBridge 匯流排。規則匹配事件並路由至 Lambda、SQS、Step Functions 等。與 SNS 扇出不同，每個目標由規則把關——目標只接收它們在意的事件。

模式四——Step Functions 編排（工作流程即程式碼）

將多步驟業務工作流程定義為狀態機。Step Functions 驅動流程、調用服務、處理重試、記錄完整歷史。當需要重試邏輯、分支、平行或長時間等待時，以此取代互相透過 SNS/SQS 呼叫的 Lambda 鏈。

模式五——協作式 vs 編排式

多服務工作流程的兩種競爭哲學：

• 協作式（Choreography）：每個服務訂閱事件匯流排（EventBridge 或 SNS）上的事件並獨立反應。沒有中央協調者。鬆散耦合、有彈性，但端對端流程難以理解。
• 編排式（Orchestration）：中央控制器（Step Functions）逐步驅動工作流程。易於理解、易於稽核，但引入了單一編排者。

SAA-C03 情境有時會問要選哪種哲學。經驗法則：協作式適合鬆散、持續演化的系統；編排式適合需要合規稽核的工作流程。

模式六——多個 SQS 佇列實作優先佇列

SQS 不支援每則訊息的優先順序。標準 AWS 模式是建立兩個佇列——high-priority 與 low-priority——並讓消費者永遠先清空高優先佇列。簡單、便宜、有效。

SQS vs SNS vs EventBridge vs Step Functions vs Amazon MQ — 主要比較

以下五方比較是 SAA-C03 AWS 訊息傳遞與解耦題目中最有價值的單一表格。請記熟它。

AWS 訊息傳遞與解耦的常見考試陷阱

SAA-C03 一次又一次重複相同的 AWS 訊息傳遞與解耦陷阱。快速認出它們。

陷阱一——有序處理時 SQS Standard vs FIFO

「金融交易必須按順序處理」→ SQS FIFO。「順序不重要的高量日誌」→ SQS Standard。考生會因 Standard 更常見而選它；考試獎勵仔細閱讀題目中的排序要求。

陷阱二——扇出時 SNS vs EventBridge

兩者都能扇出。簡單廣播選 SNS；當來源是 AWS 服務、SaaS 夥伴，或需要豐富過濾/封存重播/schema 發現時選 EventBridge。

陷阱三——串流處理時 SQS vs Kinesis

SQS 是佇列，不是串流。如果題目提到「重播」、「多個並行消費者讀取相同資料」或「有序的高量即時分析」，答案是 Kinesis Data Streams（參見 streaming-data-kinesis 主題）。SQS 允許恰好一個工作者處理每則訊息。

陷阱四——把 Step Functions 當訊息佇列

Step Functions 不是佇列。不要在「用持久緩衝解耦服務 A 與服務 B」的情境中選它——那是 SQS 的工作。

陷阱五——在新應用程式中選 Amazon MQ

Amazon MQ 是遷移服務。對於新設計，SQS/SNS/EventBridge 更便宜且更具彈性。只有當情境說「現有 JMS / AMQP / MQTT / RabbitMQ / ActiveMQ 應用程式」時才選 MQ。

陷阱六——Visibility Timeout 太短

SQS 經典情境：「消費者重複處理同一則訊息。」最可能的原因：visibility timeout 短於處理時間。解法：延長 visibility timeout 或在處理途中呼叫 ChangeMessageVisibility。

陷阱七——忘記掛 DLQ

任何生產環境的 SQS/SNS 設計若沒有 dead-letter queue，在 SAA-C03 中都應被質疑。預期考試選項只在「有掛 DLQ」與「沒有掛 DLQ」上有所不同——選有掛 DLQ 的那個。

關鍵數字與必背事實

• SQS 訊息保留：1 分鐘至 14 天，預設 4 天。
• SQS 最大訊息大小：256 KB（搭配 Extended Client Library + S3 最多 2 GB）。
• SQS visibility timeout：0 秒至 12 小時，預設 30 秒。
• SQS FIFO 吞吐量：預設 300 TPS，批次處理 3,000，高吞吐量模式 70,000+。
• SQS FIFO 名稱後綴：必須以 .fifo 結尾。
• SQS 批次大小：每次 API 呼叫最多 10 則訊息，256 KB 聚合。
• SQS 延遲佇列：訊息可延遲 0–15 分鐘後才變為可見。
• SNS 訊息大小：最多 256 KB。
• SNS FIFO 吞吐量：300 TPS；只能傳遞至 SQS FIFO 佇列。
• SNS 每主題訂閱者數：最多 1,250 萬。
• EventBridge 每匯流排規則數：每個事件匯流排最多 300 條。
• EventBridge 每規則目標數：最多 5 個。
• EventBridge 事件大小：最多 256 KB。
• EventBridge 重試時間：預設 24 小時。
• Step Functions Standard 最長執行時間：1 年。
• Step Functions Express 最長執行時間：5 分鐘。
• Step Functions Standard 歷史保留：90 天。
• Step Functions Express 吞吐量：每秒 100,000+ 次執行。
• Amazon MQ 協定：JMS、AMQP 0-9-1、AMQP 1.0、MQTT、STOMP、OpenWire。
• Amazon MQ broker 引擎：ActiveMQ（廣泛協定支援）與 RabbitMQ（AMQP 0-9-1）。

AWS 訊息傳遞與解耦 vs 相關主題——邊界線

SAA-C03 仔細區分 AWS 訊息傳遞與解耦（任務 2.1）與鄰近主題。了解邊界。

• 訊息 vs 串流（2.1 vs 3.5） — SQS/SNS/EventBridge 是訊息傳遞：每則訊息一個消費者，無重播。Kinesis/MSK 是串流：多個消費者、有序重播。當題目提到「即時分析」、「多個並行消費者」或「重播 24 小時窗口」，選串流。
• 訊息 vs API（2.1 vs 2.1） — 客戶端等待回答的同步請求/回應是 API Gateway + Lambda 或 API Gateway + ALB。非同步即發即忘是 SQS/SNS/EventBridge。
• 訊息 vs 無伺服器與容器（2.1 vs 2.1） — Lambda、ECS 與 EKS 是訊息服務的消費者。訊息服務是解耦緩衝；Lambda 是處理器。它們幾乎總是在 SAA-C03 中一起出現。
• 訊息 vs 高可用性（2.1 vs 2.2） — 訊息傳遞提供解耦（時間獨立性）；HA 提供冗餘（空間獨立性）。SQS 本質上是多 AZ 的；SNS 與 EventBridge 本質上是區域性高可用的。加入訊息傳遞不會自動讓你的應用程式跨區域 HA——你仍然需要跨區域複寫或 Route 53 容錯移轉。
• 訊息 vs Step Functions vs Lambda 鏈 — 透過 SNS 或直接調用串接 Lambda 是脆弱的。如果工作流程有超過 2–3 個步驟且有分支或重試，改選 Step Functions。

練習題信號——任務 2.1 對應練習

使用這些信號對服務的對應關係來練習 AWS 訊息傳遞與解耦情境題。

1. 「將 Web 層與非同步處理工作的緩慢工作者層解耦。」→ Amazon SQS（Standard）。
2. 「金融交易必須以嚴格順序處理且不能有重複。」→ Amazon SQS FIFO。
3. 「一個訂單事件必須更新庫存、向客戶發送電子郵件，並記錄至分析系統。」→ Amazon SNS 扇出至 3 個 SQS 佇列。
4. 「消費原生 AWS 服務事件（EC2 狀態變化、S3 物件建立），並根據事件內容路由至 Lambda。」→ Amazon EventBridge 搭配事件模式規則。
5. 「將 Datadog、Zendesk 或 Shopify 事件整合至 AWS 工作流程。」→ Amazon EventBridge 夥伴事件匯流排。
6. 「編排一個 10 步驟的訂單履行工作流程，包含重試、分支與人工審批。」→ AWS Step Functions Standard。
7. 「每秒處理 500,000 個 IoT 事件，流程時間僅 3 秒。」→ AWS Step Functions Express。
8. 「將現有基於 JMS 的 Java 應用程式從本地遷移至 AWS，無需重寫。」→ Amazon MQ（ActiveMQ）。
9. 「調查處理失敗 10 次的訊息，且不阻塞主佇列。」→ SQS Dead-Letter Queue，maxReceiveCount = 10。
10. 「在低流量期間減少空的 SQS 回應與 API 成本。」→ SQS long polling（20 秒 WaitTimeSeconds）。
11. 「工作者偶爾重複處理每則訊息。」→ 增加 SQS visibility timeout 或呼叫 ChangeMessageVisibility。
12. 「在訊息到達訂閱者之前，過濾掉 90% 訂閱者不在意的 SNS 訊息。」→ SNS 訊息過濾政策。
13. 「將 20 個 AWS 帳號的事件集中至單一可觀測性帳號。」→ EventBridge 跨帳號事件匯流排路由。
14. 「在修復下游 bug 後重播最近 7 天的事件。」→ EventBridge 封存與重播。
15. 「在需要合規稽核的工作流程中選擇協作式或編排式。」→ 編排式（Step Functions）。

FAQ — AWS 訊息傳遞與解耦熱門問題

Q1. SAA-C03 的主要 AWS 訊息傳遞與解耦服務有哪些？

SAA-C03 的核心 AWS 訊息傳遞與解耦服務為：Amazon SQS（點對點佇列）、Amazon SNS（發布訂閱廣播）、Amazon EventBridge（具規則路由的事件匯流排）、AWS Step Functions（工作流程編排）以及 Amazon MQ（遷移用受管 ActiveMQ / RabbitMQ broker）。記住這五個加上標準模式——佇列式負載平衡、SNS 扇出、EventBridge 規則路由、Step Functions 編排——你就能應對幾乎所有任務 2.1 情境題。

Q2. 何時應選 Amazon SQS FIFO 而非 SQS Standard？

當需要在 MessageGroupId 內保持嚴格順序且不能允許重複處理時（金融交易、庫存扣減、依序訂單步驟），選 Amazon SQS FIFO。當吞吐量比嚴格排序更重要且消費者具冪等性時（日誌、遙測、通用工作佇列），選 Amazon SQS Standard。記住：FIFO 吞吐量預設上限為 300 TPS（批次 3,000，高吞吐量模式 70,000+），Standard 則近乎無限。FIFO 佇列名稱必須以 .fifo 結尾。

Q3. Amazon SNS 與 Amazon EventBridge 有什麼區別？

兩者都是推送式的 AWS 訊息傳遞與解耦服務，將一則訊息扇出至多個訂閱者。Amazon SNS 更簡單且更便宜——適合將你自己的應用程式訊息廣播至 SQS 佇列、Lambda 函數、電子郵件、SMS 和行動推播。Amazon EventBridge 更豐富——適合消費原生 AWS 服務事件、SaaS 夥伴事件、對任意欄位套用 JSON 模式過濾、封存事件以供重播，以及跨帳號路由。經驗法則：簡單扇出用 SNS；當事件來源是 AWS 服務或 SaaS 夥伴，或需要豐富過濾與事件封存/重播時用 EventBridge。

Q4. 何時應使用 AWS Step Functions 而非串接 Lambda 函數？

只要工作流程有超過 2–3 個步驟、根據中間結果分支、需要指數退避重試、包含人工審批、執行超過幾分鐘，或必須可稽核，就使用 AWS Step Functions。透過直接調用或 SNS 串接 Lambda 是脆弱的——你會失去可見性、重試邏輯與集中的錯誤處理。長時間執行或需要合規稽核的工作流程選 Step Functions Standard；高量、短時間的事件處理選 Step Functions Express。

Q5. Amazon MQ 何時優於 SQS/SNS/EventBridge？

只有當你在遷移使用標準訊息協定（JMS、AMQP 0-9-1、AMQP 1.0、MQTT、STOMP、OpenWire）且無法重寫訊息層的現有應用程式時，Amazon MQ 才是正確的 AWS 訊息傳遞與解耦答案。對於全新應用程式，SQS/SNS/EventBridge 更便宜、無伺服器且更具彈性。如果考試情境說「lift-and-shift 一個 ActiveMQ 或 RabbitMQ 工作負載」，選 Amazon MQ。否則，預設使用 AWS 原生三人組。

Q6. SQS dead-letter queue 如何運作，何時必須掛上它？

**dead-letter queue（DLQ）**是一個次要的 SQS 佇列，收集在 maxReceiveCount 次嘗試後仍未成功處理的訊息。當消費者接收訊息、計數增加，且在 visibility timeout 內未刪除訊息時，計數就會上升。一旦達到 maxReceiveCount，SQS 便將訊息路由至 DLQ，而非將其返回主佇列。請為每個生產環境 SQS 佇列掛上 DLQ，這樣毒藥訊息才不會阻塞正常流量。典型的 maxReceiveCount 值為 5 到 10。Standard 佇列必須使用 Standard DLQ；FIFO 佇列必須使用 FIFO DLQ。

Q7. Amazon SQS 的 long polling 與 short polling 有什麼區別？

Short polling（預設）從 ReceiveMessage 立即返回，即使佇列為空。Long polling（設定 WaitTimeSeconds 1–20 秒）阻塞，直到訊息到達或 timeout 到期。Long polling 減少空的 API 回應、降低成本並減少消費者延遲。對於幾乎所有生產工作負載，請啟用 20 秒等待時間的 long polling。在 SAA-C03 中，「減少空回應」或「降低 SQS API 成本」→ long polling。

Q8. 如何為多服務工作流程選擇協作式與編排式？

協作式讓每個服務訂閱事件匯流排（EventBridge 或 SNS）上的事件並獨立反應——沒有中央協調者，服務最大程度解耦，但端對端工作流程難以理解。編排式讓中央控制器（AWS Step Functions）逐步驅動工作流程——易於理解、可稽核、集中的重試與錯誤處理，但引入了單一編排者。鬆散耦合、持續演化的微服務選協作式；複雜、有分支或需要合規稽核的工作流程選編排式。

延伸閱讀——AWS 訊息傳遞與解耦參考資料

如需深入了解超出 SAA-C03 範疇的 AWS 訊息傳遞與解耦：

• AWS Well-Architected Framework — 可靠性與效能效率支柱，解耦章節。
• Amazon SQS Developer Guide — visibility timeout、DLQ、FIFO 深度解析。
• Amazon SNS Developer Guide — 過濾政策、FIFO 主題、訊息傳遞重試。
• Amazon EventBridge User Guide — 事件模式、schema registry、封存/重播。
• AWS Step Functions Developer Guide — Amazon States Language、模式（saga、callback、map）。
• Amazon MQ Developer Guide — ActiveMQ 與 RabbitMQ 引擎細節。
• AWS Messaging 部落格 — AWS 訊息傳遞與解耦服務的新功能與深度模式解析。

這些資源超出了 SAA-C03 的深度，但能建立應對 Solutions Architect Professional 考試與真實架構決策所需的心智模型。

總結——AWS 訊息傳遞與解耦一覽

• AWS 訊息傳遞與解耦涵蓋佇列（Amazon SQS）、發布訂閱（Amazon SNS）、事件路由（Amazon EventBridge）、工作流程編排（AWS Step Functions）與舊協定 broker（Amazon MQ）。
• Amazon SQS 是用於緩衝與工作者池的點對點佇列；順序重要時選 FIFO，吞吐量重要時選 Standard。
• Amazon SNS 是扇出廣播器；與 SQS 配對，建構對多個獨立消費者的彈性扇出。
• Amazon EventBridge 是規則路由事件匯流排；用於 AWS 原生事件、SaaS 夥伴事件、豐富過濾與封存/重播。
• AWS Step Functions 將多步驟工作流程編排為狀態機；長時間稽核流程選 Standard，高量短暫事件處理選 Express。
• Amazon MQ 用於遷移現有 ActiveMQ / RabbitMQ / JMS / AMQP 工作負載——不適用於新設計。
• 生產環境務必掛上 dead-letter queue，務必將 SQS visibility timeout 調整至符合實際處理時間，務必啟用 long polling。
• 了解訊息傳遞（SQS/SNS/EventBridge）與串流（Kinesis/MSK）的邊界——前者是每則訊息一個消費者，後者是多個消費者可以重播。

精通 AWS 訊息傳遞與解耦這一章，你就能在 SAA-C03 的 6–9 道 Domain 2 訊息傳遞題目中胸有成竹應對——而相同的心智模型也能直接延伸至 SAP-C02 與 DVA-C02。AWS 訊息傳遞與解耦是 AWS 上每個鬆散耦合、有彈性、事件驅動架構的核心，在考試結束後仍將持續為你服務。