在上一篇，我們已經完成了 Cognito + API Gateway + Lambda 的串接。 當前端帶著 Token 呼叫 API Gateway，Lambda 就能知道「這是誰」並回傳結果。

不過，事情常常不是這麼順利，常常我們需要花一大堆時間來debug
你可能遇到過這些問題：

• API Gateway 回傳 401 Unauthorized
• Lambda 沒有如預期執行
• API 呼叫超時，卻不知道問題在哪裡

這時候，我們就需要 CloudWatch，來幫助我們「看到系統裡發生了什麼」。

什麼是 CloudWatch？

CloudWatch 是 AWS 的 監控與觀測服務，主要包含三大功能：

1. Metrics（指標）
   • 像是 Lambda 的執行次數、耗時、錯誤率
   • API Gateway 的延遲、4xx/5xx 錯誤率

如果有正在活動中的資源，可以透過CloudWatch DashBoard 輕鬆創立 Metrics 監控儀錶板

2. Logs（日誌）
   • Lambda console.log() 、print() 之類的 output 的輸出會自動寫進 CloudWatch Logs
   • API Gateway 也可以設定存取日誌，幫助追蹤請求
3. Alarms（告警）
   • 當某個指標超過閾值（例如 Lambda 錯誤率 > 5%），可以觸發通知（例如 SNS 或 Email）

今天我們主要聚焦在 Logs，因為這是 debug API Gateway + Lambda 的關鍵。

什麼是 CloudWatch Logs？

當我們的系統（例如 Lambda、API Gateway）有輸出 log 時，AWS 會自動把這些 log 丟到 CloudWatch Logs。
但在 CloudWatch 裡，log 的組織方式有一些專有名詞需要先理解：

Log Group

• 可以把它想成「資料夾」。
• 每個服務的 log 會被放到不同的 Log Group 裡。
• 例如：
  • Lambda 的 Log Group 會長得像 /aws/lambda/MyFunctionName
  • API Gateway 的 Log Group 會長得像 /aws/api-gateway/MyApiName

• 保留時間 (Retention period) 是設定在 Log Group 上的，用於管理 Events 的生命週期，例如只保留 30 天。

Log Stream

• 在 Log Group 裡面，會有一堆「檔案」一樣的東西，這就是 Log Stream。
• 每個 Log Stream 代表一段時間或一個實例的輸出。
  • Lambda：每次啟動一個新 container，就會建立新的 Log Stream。
  • EC2：每台機器會有不同的 Log Stream。
• 當你要 Debug Lambda 的某次執行，就要進到 對應的 Log Stream。

圖為一個 API Gateway 資源的 Log Streams，而 Stream 之中即是 Events

Event

• 最細節的 log 記錄就是 Event，也就是每一行 log 訊息。
• 例如你在 Lambda 裡面 print("Hello World")，這行會出現在 Event。

這兩個 Event 分別紀錄 API Gateway 將請求轉發給 Lambda 並成功獲取回覆

簡單比喻

• Log Group = 資料夾
• Log Stream = 檔案
• Event = 檔案裡的一行文字

這樣一層一層的結構，可以幫助我們快速找到 log，並且設定 Alarm（例如某個 Log Group 裡面出現「ERROR」字樣就通知）。

Lambda 與 CloudWatch Logs

當你建立一個 Lambda 資源時 AWS 會自動幫你開一個 Log Group (如果不小心刪掉了 只要 Lambda Function 被觸發 AWS 又會幫你開回來)

當你在 Lambda 裡面寫下：

def handler(event, context):
    print("收到的事件：", event)
    return {"statusCode": 200, "body": "Hello"}

這些輸出會自動被收集到 CloudWatch Logs。
你可以在 Console 中：

1. 打開 CloudWatch → Logs → Log groups
2. 找到 /aws/lambda/你的Function名稱
3. 點進去就能看到每次執行的 log

API Gateway 與 CloudWatch Logs

API Gateway 預設不會打 log，需要手動開啟：

其實在開啟 CloudWatch Logs 的時候 AWS 實際上做的事情是:
1.給這個資源 (API Gateway) 上傳東西到 CloudWatch 的權限
2.幫你創建 Log Group 方便你看傳了哪一些東西

於是乎為了手動開啟，首先我們要搞定權限問題，也就是創造 IAM Role (如果已經有創建過任意一個就可以跳過)
1.

在創建頁面選擇 Web Service 並輸入 API Gateway

創建完畢之後就可以直接到 AWS Console進行後續設定了 AWS 會根據設定自動幫你套用 IAM Role

1. 打開 API Gateway Console → Stages → Logs/Tracing
2. 啟用 CloudWatch Logs 並選擇一個 Log Group
3. 設定 Log level（例如 INFO 或 ERROR）

如果你用的是 HTTP API 而不是 REST API 設定會更加簡單

這樣你就能看到：

• 誰呼叫了 API
• API Gateway 有沒有正確把 Token 傳給 Lambda
• 如果失敗，是卡在 API Gateway 還是 Lambda

用 CloudWatch Insights 查詢

當 log 多了起來，用肉眼翻很累。
這時候可以用 CloudWatch Logs Insights，像 SQL 一樣查詢 log。

但這部分我今天就不介紹啦 有興趣的可以去讀讀看 AWS Document

常見錯誤與 CloudWatch 的排查方式

1. 401 Unauthorized

   • 看 API Gateway 的 log，確認 JWT 有沒有正確帶入
   • 看 Cognito 的設定 Callback URL 是否一致

2. Lambda 超時

   • 看 Lambda log 裡 event 參數，確認資料格式正確
   • 調整 Lambda 的 Timeout（預設只有 3 秒）

3. CORS 問題

   • 看 API Gateway log，是否有回傳 Access-Control-Allow-Origin
   • 在 API Gateway 或 Lambda 裡正確設定 header

結語

• CloudWatch Logs：用來 debug Lambda 和 API Gateway
• CloudWatch Metrics：幫助你追蹤服務的健康狀態
• CloudWatch Alarms：自動通知異常

有了 CloudWatch，就可以看見系統裡發生什麼事，只看前端 Debug 遲早會發瘋的

下一篇，我們將回到專案開發，來看看怎麼用 DynamoDB 幫後端 API 加上資料儲存功能