簡單的一句話區分：
- SQS (Queue)：是用來 「排隊與緩衝」 的（解耦、一對一）。
- SNS (Topic)：是用來 「廣播」 的（發布/訂閱、一對多）。
- SES (Email)：是用來 「寄 Email」 的（行銷信、驗證信）。
以下是詳細的比較與架構設計重點：
1. 快速比較表 (Comparison Table)
2. 詳細解析
A. Amazon SQS (緩衝區)
- 角色：就像銀行的 「取號排隊系統」。
- 運作：生產者 (Producer) 把資料丟進去，資料乖乖排隊。消費者 (Consumer) 有空時過來 「拉取 (Poll)」 一個任務去處理。
- 關鍵功能：解耦 (Decoupling)：前端發送請求後就可以走了，後端慢慢處理。削峰填谷：雙 11 流量暴增，SQS 負責暫存請求，保護後端資料庫不被沖垮。DLQ (死信佇列)：處理失敗的訊息會被隔離，方便除錯。
B. Amazon SNS (廣播塔)
- 角色：就像 「里長的廣播大喇叭」 或 「訂閱 YouTube 頻道」。
- 運作：發布者 (Publisher) 只要對著 Topic (主題) 喊一聲，所有 訂閱者 (Subscribers) 都會同時收到訊息。
- 關鍵功能：Fan-out (扇出)：這是 SNS 最重要的架構模式。發送一次，同時觸發 Lambda、寫入 SQS、寄送簡訊。行動推播：支援 Apple (APNS), Google (FCM) 推播通知。SMS 簡訊：發送手機簡訊。
C. Amazon SES (郵差)
- 角色：就是 「企業級的 Gmail / Mailchimp」。
- 運作：專門處理大量的 Email 發送，並確保信件不會被丟到垃圾桶 (高送達率)。
- 關鍵功能：交易型郵件：註冊驗證信、重設密碼信、訂單收據。行銷郵件：電子報 (EDM)。收信功能：也可以用來接收 Email 並觸發 S3 存檔或 Lambda 處理。
3. 常見混淆點 (VS. Battles)
Q1: SNS 也可以寄 Email，為什麼還需要 SES？
- SNS 的 Email：只能寄 純文字 (Plain Text) (JSON 格式)。目的是給系統管理員看的「警報通知」(Ops Alert)。無法排版、無法放圖片、無法追蹤開信率。
- SES 的 Email：支援 HTML (圖片、CSS、漂亮的排版)。目的是給終端客戶看的「商業信件」。提供開信率、點擊率分析、專屬 IP。
Q2: 什麼時候該用 SQS？什麼時候用 SNS？
- 如果你希望 「這條訊息一定要被處理，不能遺失，且處理速度不用即時」 →→ SQS (存起來慢慢做)。
- 如果你希望 「這條訊息發生時，要立刻通知所有人/系統」 →→ SNS (即時廣播)。
4. 經典架構模式：SNS + SQS Fan-out (扇出)
這是 AWS 考試和架構設計中最常考的組合技。
情境：使用者上傳一張頭貼。
需求：
- 系統要產生縮圖 (Thumbnail)。
- 系統要進行 AI 人臉辨識。
- 系統要發 Email 通知管理員。
錯誤做法：程式碼依序呼叫 A
→→B
→→C。如果 C 掛了，前面都卡住。
正確做法 (SNS + SQS Fan-out)：
- 程式碼發送訊息到 SNS Topic (事件：圖片上傳了)。
- SQS Queue A (縮圖用) 訂閱了這個 Topic。
- SQS Queue B (分析用) 訂閱了這個 Topic。
- Lambda (發信用) 訂閱了這個 Topic。
- SNS 一收到訊息，同時推給 SQS A, SQS B 和 Lambda。
- 後端的縮圖伺服器慢慢從 SQS A 拿任務；分析伺服器從 SQS B 拿任務。
優點：各做各的，互不影響，系統高度解耦。
5. 考試關鍵字 (Keywords)
- Decouple / Buffer / Poll / Queue →→ SQS
- Publish-Subscribe / Broadcast / Push / Fan-out →→ SNS
- Marketing Emails / High deliverability / HTML Email / Incoming Email →→ SES
