好啦，恭喜你完成了人生第一次 Lambda 執行，感覺是不是很像第一次 Deploy 上 production？「能動就是成功」，然後趕快截圖存證。

不過別急著太開心，Lambda 這東西看起來很好用，但設定沒搞清楚，也是會把人逼到失心瘋的。以下幫大家整理幾個最常見的設定雷區，讓你少一點 Debug，少一點加班，多一點時間去茶水間聊八卦。

記憶體大小（Memory Size）與 CPU 分配

首先，Lambda 自稱 Serverless，但你我心裡都知道，後面還是有 Server，只是 AWS 幫你藏起來罷了。那我們能不能決定 CPU 幾核？答案是：不能，別想了。
Lambda 的規則是：記憶體越大，CPU 就分配越多。所以如果你的 function 執行得比 PM 開會還慢，請檢查是不是還在用 128MB 的骨灰級方案。

記憶體可以從 128MB 開到 10GB，價格也會跟老闆心情一樣浮動──多一點記憶體就多花一點錢，執行快一點但月底報表也會爆一點。
建議新手一開始就從 128MB 測起，慢慢加，直到你的程式跑起來不像 PPT 在放慢速動畫。

小提醒：
設定路徑是 → Configuration → General configuration → Edit

然後你就會發現那個小紅框裡顯示的「128MB 記憶體 / 512MB 暫存空間」，嗯，這不是 bug，是 feature。

執行權限（IAM Role）

權限問題通常會是跨服務整合時遇到的第一個問題，Log 永遠是權限不足。
而且這邊就真的像是 AWS 的暗黑魔法：
Lambda 要存取 S3？要不要設定權限：要。
要連 DynamoDB？要不要設定權限：也要。
那要怎麼給？ 這個時候就是 IAM Role 出場了。

至於權限的用，官方永遠建議用最小權限原則（Least Privilege），聽起來超棒，實際操作起來超痛苦。

• 權限設太小 → Code 一跑就「Access Denied」。
• 權限設太大 → 資安部門來敲你桌子：「這誰寫的 policy？」
• 還有一個問題是 AWS 每個服務的權限都切分得超級細，有多細，等各位入世後就知道了。

最佳實務：

• 開一個專屬角色給 Lambda。
• 只給必要權限，像是 S3 就給 s3:GetObject，不要整個 s3:* 都丟上去。
• 如果真的懶得管……好啦，大家懂的，重點是 production 不要被抓包。
  以下截圖中的紅色框框，就是用來決定 Lambda 要用哪一個角色來執行的設定。可以自訂一個具有足夠權限的角色，再到這裡來變更成指定的角色，抑或者是直接將這個角色的權限擴張，也是可以的。
  

執行時間（Timeout）

要特別注意每個 Lambda 函數的執行時間預設值只有 3 秒，對，你沒聽錯，AWS 大概覺得大家的程式都像 Hello World 一樣秒殺。
可是現實是：

• 你要等 API 回應 → Timeout。
• 你要等外部服務起來 → Timeout。
• 你要等老闆回覆 → 抱歉，Lambda 沒有這麼長的耐心。

所以真的要開始用時，很多人踩到的第二個問題就是這個。執行時間最大能設定到 15 分鐘，超過就直接掰掰。這代表什麼？代表你不能拿 Lambda 來跑那種「公司月報表 SQL 報表查三小時」的東西。要嘛拆小任務搭配，要嘛乖乖去用其他服務。

設定方法：
同樣在記憶體那頁紅框 → 把秒數改大一點。
如果直接拉滿 15 分鐘，如果執行的次數多了就要注意帳單會不會爆哦！

結論

Lambda 新手的三大地雷

1. 記憶體太小跑不動 → 「在我的環境是正常的呀。」
2. Timeout 太短 → 「不是我 code 爛，是 AWS 沒等我。」
3. 權限設錯 → 「跑到一半又掛了，LOG 一看又是權限不足，開始進入最小權限測試的無輪迴」

設定權限是有一些比較簡單的小技巧，這個之後有空再說。

只要踩過這幾個坑，你就可以光明正大地說：「Lambda 很簡單啦！」

今天先聊 Lambda 的基本設定。明天開始，我們來玩點進階的 —— EventBridge。這東西就像老闆一樣，什麼都要管、什麼都要通知你，但如果搭配 Lambda，卻能玩出不少自動化花樣。

參考資料：AWS Lambda 開發人員指南 - https://docs.aws.amazon.com/zh_tw/lambda/latest/dg/welcome.html