延續 Day9 提到的，使用Serverless之後，我們只要把程式碼交付出去，有需要使用的時候呼叫它即可! 可是這麼方便的功能，到底是把程式碼給了誰呢? Lambda 就是那個「平常不存在、被叫才出現」的司機本人。這篇想要討論的就是—→這個司機長什麼樣子？要怎麼把他交給 AWS 保管，讓他隨時待命？

一支 Lambda function，本質上就是一個函式

拿掉所有雲端的包裝，Lambda 的核心其實只是一個函式，長得像這樣（TypeScript）：

export const handler = async (event, context) => {
  // 這裡放後端邏輯
  // event 裡面裝著「這次被叫醒的原因」，例如使用者送來的請求內容
  return {
    statusCode: 200,
    body: JSON.stringify({ message: "算好了" }),
  };
};

就這樣。沒有 app.listen(3000)，沒有常駐的 server 物件——因為根本沒有一個「一直開著等連線」的東西存在。AWS 只認得這個叫 handler 的函式：有事件進來，就呼叫這個函式一次，函式跑完回傳結果，就結束。

如果用其後端程式碼來比喻的話，例如用 Spring Boot Controller 對照一下會更好懂：Controller 的方法平常「活」在一個一直運行的 Tomcat 裡；Lambda 的 handler 函式平常不活在任何地方，是 AWS 在事件進來的當下，才臨時生出一個環境把它跑一次。

那我要怎麼把這個函式交給 AWS？

這裡要用一套叫 AWS SAM（Serverless Application Model） 的工具，專門用來建立、打包、部署 Lambda。整個流程只有三步：

1. 建立骨架：sam init

跑這個指令，選 Quick Start Templates → Hello World Example → Runtime 選 nodejs20.x。它會直接生出一個資料夾，裡面已經有一支能動的 Lambda 範例（就是上面那種 handler 函式）跟必要的設定檔，你不用從零生出一個雲端專案的骨架。

2. 把自己的邏輯寫進 handler

把 sam init 生出來的範例函式，換成自己真正的後端邏輯——這一步跟平常寫程式沒有兩樣，差別只在「入口」固定是這個 handler 函式，event 是輸入、return 的東西是輸出。

3. 打包並上傳：sam build → sam deploy

這裡有個很容易搞錯的地方：不是把邏輯直接貼上去就能跑，一定要先打包。用 Angular 比喻一下就懂：平常寫的 .ts、.html 當然不能直接上線，得先 ng build 打包成 dist 裡少少幾支 .js 檔案才能部署；Lambda 也是同樣道理，只是打包工具換成 esbuild：

• sam build：把你的程式碼跟用到的套件（node_modules）打包成 AWS 看得懂的格式（就像 ng build 產出 dist）。
• sam deploy：把打包好的東西真正上傳到 AWS，在雲端建立出這支 Lambda。

也因為這樣，你在 AWS Console 上的 Code 頁籤看到的，會是打包後的成品（一支壓縮過的 app.js），而不是你寫的原始多檔案程式碼。

跑完這兩個指令，你的後端邏輯就實際「存在」於 AWS 上了——雖然此刻還沒有人能連到它（那是 Day11 API Gateway 要解決的事）。

AWS 怎麼知道要建立「什麼樣」的 Lambda？template.yaml

sam init 生出來的骨架裡，有一個 template.yaml 檔案，這是整個部署的關鍵——它用文字描述「我要建立一個什麼樣的 Lambda」，例如：

MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    Handler: app.handler
    Runtime: nodejs20.x
    MemorySize: 256
    Timeout: 30

換句話說，你不用自己打開 AWS 網站介面、一個一個欄位手動點設定，只要改這份設定檔、重新 sam deploy，AWS 就會照著描述去建立或更新資源。這個做法有個名字叫 Infrastructure as Code——基礎設施用程式碼描述，而不是用滑鼠點出來，也因此這份設定可以跟程式碼一起進版控、一起被追蹤異動。

這份設定檔裡，有三個第一次接觸就該知道在幹嘛的欄位：

這三個數字現在不用想得太複雜，先知道「它們存在、且是我自己設的」就夠了——之後如果遇到函式跑太久被中斷、或效能不夠用，回頭調的就是這幾個值。

AWS裡面的Lambda實際樣貌

• Functions裡面放著邏輯方法
  

• 在code頁籤可看到打包後的後端邏輯
  (這是打包壓縮後的樣子，不是實際的程式碼量)
  

• 這支函式實際的 Runtime / Memory / Timeout 設定，對照前面表格看，數字就是這樣對上的：
  

小結

到這裡，「我的後端邏輯放去哪裡」這個問題已經有答案了：寫成一支 handler 函式，用 SAM 打包部署上去，它就存在於 AWS 裡，安靜待命。但此刻它還是一支「養在深宮無人問」的函式——沒有網址、外面連不進來。下一篇要解決的，就是怎麼幫它接上一個大家都打得到的入口。