前言

隨著陸續開發，做出了會員系統，加強了一些資安管控後，欸？ 不知道是哪裡出了問題，不能動了！
針對無伺服器的架構，要去哪裡查 Log ?!

Lambda Function

在雲端世界裡，Lambda 是無伺服器 (Serverless) 的代表作，但同時也是「黑盒子」——程式怎麼跑、哪裡出錯，如果沒有好的觀測工具，很容易 Debug 到崩潰。
這時候，CloudWatch 就是你 Lambda 的顯微鏡。今天就來聊聊：如何利用 CloudWatch 把 Lambda 的行為看得一清二楚。

為什麼要用 CloudWatch Debug Lambda？

在開發或上線的過程中，你一定會遇到這些狀況：

• Lambda 呼叫後 API Gateway 只回 500 Internal Server Error
• event payload 的格式跟預期不一樣
• boto3 SDK 報錯，但你不知道參數長什麼樣
• token 驗證失敗，不知道是哪一段爆掉

這時候，CloudWatch 就是唯一能讓你看見 Lambda 實際運作的地方。

啟用

其實不用額外設定，只要 Lambda 有基本的 CloudWatch Logs 權限（通常角色會帶 AWSLambdaBasicExecutionRole），就會自動把 log 丟進 CloudWatch。

偵錯流程

偵錯技巧一：印出 event

Lambda 的 event 格式會因為觸發來源不同而改變：

• API Gateway v1 → event["httpMethod"]
• API Gateway v2 → event["requestContext"]["http"]["method"]
• S3 → event["Records"][0]["s3"]["bucket"]["name"]
• DynamoDB → event["Records"][0]["eventName"]

所以第一件事就是 print(event)，直接從 CloudWatch 看清楚長相。

偵錯技巧二：善用 print()

• print() 在 Lambda 裡不是小學生才用的，而是 Debug 的救命工具。

偵錯技巧三：用 CloudWatch Insights 查詢

• 如果你的 Lambda 量很大，光是翻 log 會眼花。這時候可以用 CloudWatch Logs Insights：

fields @timestamp, @message
| filter @message like "❌"
| sort @timestamp desc
| limit 20

偵錯技巧四：設計結構化 Log

如果你的系統會跑很多 Lambda，建議統一 log 格式

結論

1. print(event) → 永遠是第一步
2. 善用 CloudWatch Logs Insights → 快速定位錯誤
3. 結構化 log → 系統越大越好用
4. 確保 Lambda 有 CloudWatch Logs 權限，否則你會一片空白

CloudWatch 就是你的 Lambda 偵錯雷達，學會用它，就不怕「黑盒子」Lambda 出狀況了。