Lambda 與應用程式效能優化

AWS Lambda 效能優化是 DVA-C02 考試指南 Task 4.3「使用 AWS 服務與功能優化應用程式」的核心主題。這個階段的考題不再問「什麼是 Lambda？」，而是問「這個 Lambda 為何緩慢、費用過高或遭到節流，哪個調校方式能解決？」本章銜接 Lambda 基礎 主題，深入探討運維層面的調校槓桿：使用 AWS Lambda Power Tuning 進行記憶體與 CPU 調校、冷啟動三階段剖析與三大緩解策略（縮小 init、SnapStart、Provisioned Concurrency）、Reserved Concurrency 節流、執行環境重用連線池化、Hyperplane ENI 改善 VPC 函式效能、arm64 Graviton2 降低 20% 費用效能比、Lambda Layers 與 Lambda Extensions 的取捨、Function URL 與 API Gateway 延遲比較、並行暴增數學、6 MB / 256 KB 超量酬載透過 Amazon S3 的繞道方案、高效封裝，以及非同步重試控制中 Destinations 與 DLQ 的差異。DVA-C02 考題可能從上述任何一個點出題——徹底掌握 AWS Lambda 效能優化，Task 4.3 的分數幾乎手到擒來。

AWS Lambda 效能優化在 DVA-C02 的定義

DVA-C02 的 AWS Lambda 效能優化並非單一旋鈕，而是橫跨四個維度的決策樹：延遲、吞吐量、成本與可靠性。考題中每一個 AWS Lambda 效能優化情境，最終都要求你為正確的限制選出正確的槓桿。Lambda 基礎主題教你服務表面；本主題教你上線後的調校旋鈕。

為何 AWS Lambda 效能優化獨立成一個 Task Statement

DVA-C02 考試指南將 Task 4.3 單獨列出，因為這些技能與撰寫函式本身不同。開發 Lambda 函式問的是「handler(event, context) 裡該放什麼？」AWS Lambda 效能優化問的是「函式已正常運作，我如何將 p99 從 2 秒壓到 200 毫秒、帳單從 $400 降到 $80？」這是兩組不同的肌肉，而考試兩者都會測試。

AWS Lambda 效能優化的四個維度

• 延遲 — p50 / p95 / p99 呼叫時間，直接影響透過 API Gateway 或 Function URL 對外的使用者體驗。
• 吞吐量 — 帳號或函式在不觸發節流的情況下，每秒可維持的呼叫次數。
• 成本 — 計費的 GB-seconds，加上 Provisioned Concurrency 費用、網路輸出與 X-Ray 取樣費用。
• 可靠性 — 負載下的錯誤率、非同步來源的重試行為、串流的毒丸訊息處理。

本章每一個 AWS Lambda 效能優化槓桿，都會拉動上述四個維度中的一個或多個。DVA-C02 的典型陷阱是：某個槓桿修復了一個維度，卻悄悄惡化了另一個（例如 Provisioned Concurrency 大幅壓低延遲，卻同時提高成本；增大記憶體縮短執行時間，但費用是否降低，取決於工作負載的 CPU 密集程度）。

白話文解釋 AWS Lambda 效能優化

AWS Lambda 效能優化將六個詞彙結——冷啟動、記憶體調校、執行環境重用、並行、Graviton2 與酬載限制——串成一棵運維決策樹。以下三個類比分別從不同角度切入：冷啟動的物理特性、隱藏的記憶體對 CPU 比例，以及隨需並行與預留並行的差異。選擇最能讓你記住的那一個，DVA-C02 的 Lambda 題型就會變成模式比對。

類比一——夜市攤車開爐（冷啟動物理）

想像一輛夜市攤車，只有客人點餐才會開火。第一位客人必須等爐子點燃、鐵板升溫到可以煎蛋、油鍋從冷油熱到噴香——這段等待就是 Lambda 的冷啟動，由套件下載、執行環境啟動和 init 程式碼組成。SnapStart 的技巧是把攤車熱好的狀態拍成快照存下來，下次重新開攤時直接還原那個熱鍋狀態，省掉重新點火升溫的時間。Provisioned Concurrency 則是花錢讓攤車整晚保持熱鍋——第一位客人隨時都能立刻拿到熱食，但你得持續燃燒瓦斯付費。

類比二——熱氣球充氣（記憶體對 CPU 比例）

調校 Lambda 記憶體就像為熱氣球加大噴火器火力。128 MB 只有小火苗——氣球（你的函式）爬升緩慢，但每一秒租賃費都在計。火力調到 1769 MB，解鎖完整一個 vCPU；繼續往 10 GB 推，你能獲得最多六個 vCPU 加上等比例的網路頻寬。對 CPU 密集型工作負載而言，記憶體加倍往往讓執行時間減半，總 GB-seconds 反而下降，即使每毫秒單價提高了。AWS Lambda Power Tuning 就是那個自動找出最省錢飛行高度的風洞測試工具。

類比三——機場安檢通道（隨需並行 vs Provisioned Concurrency）

Lambda 的並行機制就像機場的安檢通道。帳號暴增限制是航廈最多能開幾條通道——初始 500 至 3000 條立即可用，之後每分鐘增加 1000 條，直到觸及上限。Reserved Concurrency 是為你的航空公司圍出 100 條專屬通道：保障容量，同時也是硬性上限。Provisioned Concurrency 是預付加班費讓安檢員提前就位、X 光機已開機，讓最早的旅客不用排隊等待冷開機的掃描儀。隨需並行是預設模式——通道反應式開啟，最省錢，但最早的旅客難免要等一等。

把這三個畫面放在一起——熱鍋物理、氣球火力比例、安檢通道分配——DVA-C02 上的每一道 AWS Lambda 效能優化題都能對應到其中之一。

AWS Lambda 執行環境生命週期

每一個 AWS Lambda 效能優化技術都作用於三個生命週期階段之一，因此掌握生命週期是必要的前提。

階段一——Init 階段（INIT）

AWS Lambda 建立新執行環境時，會依序執行三個步驟：

1. Extension init — 啟動 /opt/extensions/ 中每一個 Lambda Extension。
2. Runtime init — AWS Lambda 啟動語言執行環境（Node.js、Python、JVM、.NET CLR、Ruby、自訂 provided.al2023）。
3. Function init — AWS Lambda 執行你的模組層級程式碼：import 陳述式、SDK client 建構、資料庫連線池、載入 ML 模型。

階段一就是考試所說的「冷啟動」。AWS Lambda 對標準函式的 INIT 時間計費（以函式記憶體費率計算）；使用 SnapStart 時，每次還原只收一次性的還原費用。

階段二——Invoke 階段（INVOKE）

AWS Lambda 將事件傳送給執行環境，執行環境呼叫你的 handler，handler 執行至完成（回傳或未處理的例外）或逾時。每一次暖呼叫都只有階段二。

階段三——Shutdown 階段（SHUTDOWN）

AWS Lambda 回收閒置的執行環境時，執行環境和 Extensions 會收到關閉訊號（最多 2 秒）。Extensions 可利用這個時間窗口刷出遙測資料；大多數 handler 沒有關閉鉤子。

AWS Lambda 記憶體設定：首要效能旋鈕

記憶體是最重要的 AWS Lambda 效能優化設定，因為它同時控制 CPU 與成本。

128 MB 到 10,240 MB 的範圍

AWS Lambda 允許你將記憶體設定在 128 MB 至 10,240 MB（10 GB） 之間，以 1 MB 為單位遞增。CPU 與記憶體線性對應：在約 1,769 MB 時達到完整一個 vCPU，在 10,240 MB 時約有六個 vCPU。這意味著透過記憶體進行 AWS Lambda 效能優化，本質上是 CPU 優化——CPU 密集型工作負載在更高記憶體下往往更快且更便宜，因為執行時間的降幅超過 GB-seconds 的漲幅。

反直覺的成本曲線

AWS Lambda 計費公式是 GB-seconds × 請求次數 × 區域費率。沒有經驗的工程師會假設最小記憶體等於最低成本。但對 CPU 密集型程式碼（圖片轉換、PDF 渲染、加密、大型酬載的 JSON 解析），從 512 MB 提升到 1,792 MB 可能讓執行時間縮短 3 倍，而每毫秒成本只增加一倍——淨節省 33%。透過記憶體調校進行 AWS Lambda 效能優化，是 AWS 上少數能同時購買更快速度又省錢的場景之一。

AWS Lambda Power Tuning

AWS Lambda Power Tuning 是一個開源的 AWS Step Functions 狀態機（可從 AWS Serverless Application Repository 部署），以實測方式找出函式的最佳記憶體設定。你需要傳入：

• 函式 ARN（及別名）。
• 具代表性的呼叫酬載。
• 要測試的記憶體大小清單（例如 [128, 256, 512, 1024, 1536, 3008, 5120, 10240]）。
• 每個記憶體設定的呼叫次數（統計信心）。
• 策略：speed、cost 或 balanced。

狀態機在每個記憶體大小下呼叫函式 N 次，測量執行時間並計算成本，最後回傳一個視覺化結果，標出最佳甜蜜點。只要考題問「如何選出最佳記憶體」，AWS Lambda Power Tuning 就是 DVA-C02 認可的答案。

記憶體調校決策規則

• I/O 密集型（函式大部分時間等待 DynamoDB、S3、HTTP）→ 小記憶體（128–512 MB）通常最佳；額外 CPU 閒置無用。
• CPU 密集型（圖片/PDF/加密/壓縮）→ 在完整範圍內執行 AWS Lambda Power Tuning；通常落在 1,792 MB 或 3,008 MB 附近。
• 記憶體密集型（大型記憶體資料結構、ML 模型）→ 依工作集大小加 20% 頭部空間調整。
• 混合型 → 使用 balanced 策略執行 AWS Lambda Power Tuning。

AWS Lambda 冷啟動解剖

AWS Lambda 冷啟動是三個子延遲的複合體，AWS Lambda 效能優化必須針對正確的子延遲下手。

子延遲一——執行環境啟動

AWS Lambda 啟動一個 Firecracker micro-VM、掛載部署套件，並啟動語言執行環境。這段子延遲由 AWS 控制，基本不變：Node.js 和 Python 約 50–100 毫秒、Ruby 和 Go 約 150–300 毫秒、.NET 約 300–500 毫秒、Java 約 400–800 毫秒。你無法縮短執行環境啟動時間，除非選擇更輕量的執行環境——這就是為什麼 Java 冷啟動最長，也是 SnapStart 最初為 Java 設計（現已擴展至 Python/.NET）的原因。

子延遲二——部署套件載入

AWS Lambda 將部署套件下載並解壓縮至沙箱。耗時與解壓縮後的大小及檔案數量成正比。250 MB 解壓縮的 ZIP 需要數百毫秒載入；5 MB 的精簡套件只需數十毫秒。這就是為什麼 AWS Lambda 效能優化幾乎都從「縮小部署套件」開始。

子延遲三——函式 Init 程式碼

你在模組層級執行的程式碼——import boto3、const dynamodb = new DynamoDBClient()、載入 Hugging Face 模型——全都在 INIT 期間執行。對資料科學和 ML 工作負載而言，大量的 import 和積極初始化主導了冷啟動時間。只有在某些呼叫不需要的情況下，才將昂貴的工作移入 handler 內部的延遲載入器。

各執行環境冷啟動排名

從最短到最長（在 1,024 MB 下一個簡單 handler 的典型 p50）：

• Node.js 20.x — 80–150 毫秒。
• Python 3.12 — 100–200 毫秒。
• Go on provided.al2023 — 100–250 毫秒。
• Ruby 3.3 — 200–400 毫秒。
• .NET 8 — 400–800 毫秒（啟用 SnapStart 後 200–500 毫秒）。
• Java 21 — 500–1500 毫秒（啟用 SnapStart 後 150–400 毫秒）。

這些數字會因區域、套件大小和 init 程式碼而變動，但排序穩定，且與考試相關。

AWS Lambda SnapStart

AWS Lambda SnapStart 是近三年來最重要的 AWS Lambda 效能優化功能，DVA-C02 v2.1 明確強調。

AWS Lambda SnapStart 的運作原理

AWS Lambda SnapStart 在已發布版本的 INIT 階段完成之後，對整個執行環境進行快照——包括 Firecracker 記憶體、JVM heap、已載入的類別、已初始化的 SDK client。在後續的每次冷啟動中，AWS Lambda 從快照還原環境，而非重新執行 INIT。還原成本通常為 100–400 毫秒，而 JVM 冷啟動的原始成本是 1–6 秒。

支援的執行環境

截至 DVA-C02 v2.1 範圍：

• Java 11（Corretto）——最初推出的執行環境（2022 年 11 月）。
• Java 17 和 Java 21——隨 Corretto 託管執行環境推出後新增。
• Python 3.12+——SnapStart 於 2024 年底擴展至 Python。
• .NET 8——SnapStart 於 2024 年底擴展至 .NET。

AWS Lambda SnapStart 不支援 Node.js、Ruby、Go 或自訂執行環境——這些執行環境的冷啟動已夠快，工程投入不划算。

AWS Lambda SnapStart 計費模式

AWS Lambda SnapStart 在推出時免費；AWS 現在對每次還原收取每 GB-second 的還原費用，以及對快照收取每 GB-hour 的快取費用。對於流量忽高忽低的應用，仍比 Provisioned Concurrency 便宜，因為你只在冷呼叫實際還原快照時付費，而不是為閒置的預熱容量付費。

AWS Lambda SnapStart 還原鉤子與唯一性重新播種

SnapStart 最大的坑是快照中捕獲的狀態必須在每個沙箱中保持唯一：隨機數種子、UUID、已快取的 IAM 憑證、資料庫連線 ID、臨時連接埠。如果一千次冷啟動都從同一個快照還原，它們將全部繼承相同的 RNG 狀態，可能還有相同的過期憑證快取。

解決方法是使用 CRaCResource 鉤子（org.crac.Resource）：

public class ConnectionPool implements Resource {
  @Override public void beforeCheckpoint(Context<? extends Resource> ctx) {
    pool.closeAllConnections();
  }
  @Override public void afterRestore(Context<? extends Resource> ctx) {
    pool.reopenAllConnections();
    SecureRandom.reseed();
  }
}

在靜態 init 中註冊此資源；AWS Lambda SnapStart 會在 checkpoint/restore 前後呼叫鉤子。Python 和 .NET 透過各自的執行環境鉤子 API 提供等效的 beforeSnapshot / afterRestore callback。

AWS Lambda Provisioned Concurrency

AWS Lambda Provisioned Concurrency 是效能優化的暴力解法——付費讓 N 個沙箱保持完全預熱。

Provisioned Concurrency 的保障

當你在別名上設定 Provisioned Concurrency = 50 時：

• AWS Lambda 預先初始化 50 個執行環境——所有三個 INIT 子階段在流量到來之前就已完成。
• 前 50 個並行呼叫抵達時使用暖沙箱，沒有冷啟動（大多數執行環境的 p99 低於 50 毫秒）。
• 第 51 到帳號上限的呼叫退回隨需擴展，可能發生冷啟動。
• 你需要為預熱容量支付每 GB-second 費用，加上正常的呼叫費用。

Application Auto Scaling 整合

Provisioned Concurrency 本身是 AWS Application Auto Scaling 的可擴展目標，因此你可以：

• 排程在業務高峰時段前預熱（例如平日上午 9 點至下午 6 點）。
• 目標追蹤 ProvisionedConcurrencyUtilization，將使用率維持在 70% 左右。

結合 CloudWatch 警報，使 AWS Lambda Provisioned Concurrency 對可預測的流量高峰在經濟上合理——典型的「開盤時流量暴增 20 倍」模式。

Provisioned Concurrency vs SnapStart 決策

• SnapStart — 適合 Java、Python、.NET；還原成本低廉；適合無法預測的流量。
• Provisioned Concurrency — 適用於任何執行環境，包括 Node.js 和 Go；適合可預測的流量暴增，需要低於 50 毫秒的尾延遲。
• 可以組合使用：SnapStart 縮短 Provisioned Concurrency 預熱的沙箱達到就緒狀態的時間，讓預熱艦隊更快準備好。

AWS Lambda Reserved Concurrency 節流

AWS Lambda Reserved Concurrency 是 AWS Lambda 效能優化的節流旋鈕——重塑吞吐量並保護下游依賴。

Reserved Concurrency 的運作方式

當你在函式 F 上設定 Reserved Concurrency = 100 時：

• F 的並行從恰好 100 個的私有池中取用（保障下限）。
• F 不能超過 100 個並行執行——超過 100 的請求會被節流，同步呼叫回傳 HTTP 429，非同步呼叫進入重試佇列或 DLQ。
• 帳號其餘的池（預設帳號為 1,000 − 100 = 900）由該區域的其他所有函式共享。

為何 Reserved Concurrency 是效能槓桿而非只是限制

AWS Lambda Reserved Concurrency 是效能槓桿，因為現代應用通常有 Lambda 必須尊重的下游瓶頸：

• Amazon RDS 連線限制（Postgres 預設 max_connections = 100；1,000 個 Lambda 同時敲擊會耗盡連線）。
• 第三方 API 速率限制（Stripe、Twilio、SendGrid）。
• DynamoDB 已佈建吞吐量（舊型表格）。
• 老舊內部 SOAP 端點（執行緒池極小）。

將 Reserved Concurrency 設定在下游上限以下，讓 Lambda 成為行為良好的客戶端，防止級聯故障。這是針對整個系統的 AWS Lambda 效能優化，而非只針對函式本身。

Reserved Concurrency 設為零 = 緊急停止開關

特殊情況：Reserved Concurrency = 0 節流函式的每一次呼叫。這是安全的「緊急停止」模式——在不刪除函式的情況下暫停行為異常的非同步消費者，修復部署後再調高。

AWS Lambda 執行環境重用與連線池化

AWS Lambda 執行環境重用是最便宜的 AWS Lambda 效能優化技術——只需將程式碼寫在 handler 外面。

全域範圍模式

模組層級的程式碼（handler 外部）在每個執行環境的 INIT 期間執行一次，結果對暖呼叫已在記憶體中。標準優化模式：

// Node.js — 在 INIT 期間執行一次
const { DynamoDBClient } = require("@aws-sdk/client-dynamodb");
const ddb = new DynamoDBClient({});

// 每次呼叫執行
exports.handler = async (event) => {
  const result = await ddb.send(/* ... */);
  return result;
};

應全域初始化的項目：

• AWS SDK client — 它們池化 HTTPS keep-alive 連線（SDK v3 Node.js 預設啟用 keep-alive；v2 需要 NodeHttpHandler 搭配 keepAlive: true；Python boto3 透過底層 urllib3 池支援 Config(keep_alive=True)）。
• 資料庫連線池 — MySQL、Postgres、MongoDB、Redis client。
• 密鑰/設定 — 在 INIT 期間從 Secrets Manager 或 Parameter Store 取回一次（但請記得 SnapStart 的唯一性注意事項）。
• 大型靜態資料 — 從 S3 載入的參考資料、設定 JSON。
• ML 模型 — 在模組層級一次性載入至記憶體。

反模式——每次呼叫都重新連線

# 反模式：每次呼叫增加 20-50 毫秒
def lambda_handler(event, context):
    conn = psycopg2.connect(host=..., ...)
    # ...
    conn.close()

對比正確做法：

# 全域 init——每個沙箱執行一次
conn = psycopg2.connect(host=..., ..., keepalives=1)

def lambda_handler(event, context):
    with conn.cursor() as cur:
        # ...

僅憑這個重構，通常能將 p50 延遲降低 20–100 毫秒，並將 RDS 連線抖動減少 95% 以上。這是整個考試中投資報酬率最高的 AWS Lambda 效能優化技術。

Amazon RDS Proxy 作為連線池化層

當池化連線在高並行下仍然壓垮 RDS 時，Amazon RDS Proxy 位於 AWS Lambda 和 RDS 之間，在 RDS 端維護固定大小的連線池，並將數千個 Lambda 呼叫多工複用到其上。在 DVA-C02 上，「Lambda 耗盡 RDS 連線」→ RDS Proxy 是標準答案。

AWS Lambda VPC 設定與 Hyperplane ENI

VPC 中的 AWS Lambda 效能優化曾是本主題最棘手的問題；Hyperplane ENI 大致解決了它，但考試仍然測試其機制。

2019 年前的 VPC 冷啟動夢魘

2019 年 9 月之前，將 AWS Lambda 附加到 VPC 意味著每個沙箱在冷啟動時都會佈建一個專屬 ENI。ENI 的建立與附加為第一次呼叫增加了 10–20 秒，大規模時帳號 ENI 也會耗盡。這是 DVA-C02 期望你在題目提到「VPC 冷啟動」時能認出的歷史背景——這段歷史說明了為什麼 Hyperplane ENI 是答案。

Hyperplane ENI（現行架構）

現在 AWS Lambda 使用 Hyperplane——一個共享的 NAT/代理層，在函式設定時（而非每個沙箱）延遲佈建少量 ENI，並讓數千個並行沙箱共享它們。結果：

• 首次附加到新 VPC 設定時仍會建立 ENI；後續冷啟動重用它們。
• VPC 冷啟動開銷從 10 秒以上降至數十毫秒。
• ENI 數量與 VPC 子網路 × 安全群組組合成比，而非與並行數成比。
• 在同一帳號/區域中共享子網路與安全群組的函式，共享底層 Hyperplane ENI 池。

VPC + Lambda 對外網路

私有子網路中的 VPC 附加 AWS Lambda 函式，預設沒有通往網際網路的路由。對於 AWS 服務目標（S3、DynamoDB、Secrets Manager、KMS、STS、Lambda 本身、CloudWatch Logs），正確答案是 VPC Endpoint——S3/DynamoDB 使用 Gateway Endpoint，其他服務使用 Interface Endpoint。對於公用網際網路目標（Stripe、Twilio、Google API），你需要在公有子網路中設置 NAT Gateway。

AWS Lambda arm64 Graviton2——20% 費用效能提升

將 AWS Lambda 切換至 arm64 Graviton2 是效益最不對稱的 AWS Lambda 效能優化：一行設定變更換來最高 20% 的費用效能提升。

Graviton2 實際帶來什麼

AWS Lambda 支援兩種指令集架構：

• x86_64 — 預設的 Intel/AMD 架構。
• arm64 — AWS Graviton2 處理器。

在相同記憶體設定下，arm64 函式的每 GB-second 計費比 x86_64 低約 20%，而且由於 Graviton2 更寬的向量單元和更好的編譯程式碼記憶體頻寬，實際工作負載通常快 5–15%。淨效益是相容工作負載降低 20–34% 的成本。

執行環境相容性

• 完全支援 — Python、Node.js、Java、Ruby、.NET（6 / 8）、provided.al2023。
• Container image — 必須為 linux/arm64 建置（使用 docker buildx 多平台建置）。
• 原生二進位 — 如果你的 Lambda 包含已編譯的 C/C++/Rust/Go 二進位，必須提供 arm64 版本；x86_64 二進位不能執行。
• 第三方原生依賴 — NumPy、Pandas、Sharp、Prisma engines 等必須有 arm64 wheel/二進位。大多數主要函式庫現在都有。

何時不要切換

• 具有沒有 arm64 版本的舊原生依賴的遺留函式。
• 在 x86_64 上效能更好的工作負載（罕見——通常是舊的 Intel 特定 SIMD 程式碼路徑）。

在 DVA-C02 上，「無程式碼變更降低 Lambda 成本 20%」→ arm64 Graviton2 是標準答案。

AWS Lambda Layers——Layer 大小與 INIT 時間的取捨

Lambda Layers 是一個共享功能，但從 AWS Lambda 效能優化的角度來看，它們也是 INIT 時間的稅負。

Layers 如何影響冷啟動

每個 Layer 在沙箱佈建期間都會被下載、解壓縮並掛載至 /opt。每個 Layer 增加數毫秒的掛載時間，加上執行環境 import 期間載入的任何位元組。結果：

• 1 個大 Layer（你的整個共享工具函式庫）載入速度快於 5 個小 Layer，因為解壓縮開銷是主要成本。
• 從未被 import 的 Layer 內容在執行期仍然免費（但佔用儲存空間和部署時間）。
• 有 5 個 Layer、接近 250 MB 的函式，與 5 MB 的套件函式相比，可能增加 100–300 毫秒的冷啟動時間。

效能情境下的 Layers 最佳實踐

• 使用 Layers 共享跨函式的依賴（例如 20 個資料科學函式共用 NumPy）。
• 不要僅為了縮小 ZIP 而使用 Layers——透過 esbuild、webpack、Rollup 樹搖優化成單一 5 MB 檔案的打包工具，在延遲上勝過 Layers。
• 將始終一起部署的多個小自訂 Layer 合併成一個 Layer。
• 對於以 Layer 形式提供的 Lambda Extensions，記住 Extensions 在 INIT 和 INVOKE 期間執行——一個繁重的 Extension 會增加每次冷啟動的延遲。

計算 250 MB 組合限制

函式程式碼 + 所有附加 Layers + Extensions 解壓縮後不能超過 250 MB。接近上限會損害冷啟動；對大多數函式而言，保持總計低於 50 MB 是 AWS Lambda 效能優化的最佳點。

AWS Lambda Extensions 成本模型

Lambda Extensions 改變 AWS Lambda 效能優化的計算方式，因為它們計費計算資源並延伸 SHUTDOWN 時間窗口。

Extensions 如何計費

Lambda Extension 作為獨立程序（外部）或執行環境內部（內部）在同一執行環境中執行。結果：

• Extension 的 CPU 和記憶體使用量計入函式的 GB-seconds——AWS Lambda 無法區分「你的程式碼」和「你的 Extension」。
• 一個喋喋不休的可觀測性 Extension 可能為每次呼叫增加 5–20% 的開銷。
• Extensions 參與 INIT（最多 10 秒）、INVOKE（事件驅動）和 SHUTDOWN（最多 2 秒）。SHUTDOWN 預算讓 Extensions 在 handler 回傳後將遙測資料刷出至 Datadog / New Relic / Dynatrace。

Parameters and Secrets Lambda Extension

AWS Parameters and Secrets Lambda Extension 是一個官方 Extension，在程序內快取 Parameter Store 和 Secrets Manager 的值，從 localhost:2773 提供服務，首次取回後不再產生網路呼叫。AWS Lambda 效能優化中，取得密鑰的時間從約 80 毫秒（首次呼叫）降至 < 5 毫秒（快取），TTL 可自行控制。在 DVA-C02 上，「無程式碼變更跨呼叫快取密鑰」→ Parameters and Secrets Lambda Extension 是標準答案。

何時不應使用 Extension

• 每毫秒都很關鍵的延遲敏感函式。
• 已優化 SDK 程式碼的成本敏感函式。
• 全域範圍 SDK 取回加上程序內快取可達到相同效果的情況。

AWS Lambda Function URL vs API Gateway——延遲取捨

Function URL vs API Gateway 是 DVA-C02 的 AWS Lambda 效能優化題型，在延遲、功能和成本之間進行取捨。

Lambda Function URL 能給你什麼

Lambda Function URL 是直接綁定到特定函式與別名/版本的專屬 HTTPS 端點。設定：

• 僅 HTTPS，TLS 1.2+。
• 認證：NONE（公開）或 AWS_IAM。
• CORS 在函式上設定。
• 無映射範本、無授權方、無使用計劃、無 API 金鑰。

延遲開銷：Function URL 增加約 5–10 毫秒的 HTTP 到 Lambda 連接——是進入 AWS Lambda 的最低延遲同步入口。

API Gateway 能給你什麼

API Gateway REST/HTTP API 增加 20–50 毫秒（REST）或 10–20 毫秒（HTTP）的路由、認證、節流和轉換開銷，換取 Cognito 授權方、Lambda 授權方、使用計劃、API 金鑰、映射範本、WAF 整合、快取、帶 ACM 憑證的自訂網域和 OpenAPI 匯入。

為 AWS Lambda 效能優化做出選擇

• Function URL — 需要原始 HTTP 速度、IAM 足以滿足認證需求、不需要複雜轉換。常用於內部服務間呼叫或 Auth0/Clerk 驗證的 Webhook。
• API Gateway HTTP API — 最常見的平衡點：低於 20 毫秒的開銷，Cognito/JWT 認證，以及基於路由的 Lambda 整合。
• API Gateway REST API — 需要請求驗證、映射範本、使用計劃，或邊緣優化/私有端點時使用。

DVA-C02 經常問「從外部 HTTP 客戶端呼叫 Lambda 的最低延遲方式」，答案取決於認證需求：純內部 → Function URL；需要 Cognito/JWT → HTTP API；需要映射範本 → REST API。

AWS Lambda 並行配額與暴增限制

並行配額數學對大規模 AWS Lambda 效能優化至關重要。

帳號並行池

每個 AWS 帳號從區域軟性配額 1,000 個並行執行開始。這是一個跨該區域所有函式共享的單一池。你可以透過 AWS Service Quotas / AWS Support 申請提高——大型客戶擁有數千乃至數萬的限制很常見。

暴增並行（初始擴展速率）

當函式從零開始擴展時，AWS Lambda 允許立即暴增 500–3,000 個並行執行，依區域而異（美國/歐洲：3,000；部分其他區域：1,000 或 500）。初始暴增後，並行以每分鐘 +1,000 的速率增長，直到觸及帳號池或函式的 Reserved Concurrency 上限。

範例：函式閒置，流量突然在 us-east-1 暴增至每秒 5,000 個 1 秒呼叫。

• 第 0 秒 → 最多 3,000 個並行。
• 第 60 秒 → 最多 4,000 個並行。
• 第 120 秒 → 最多 5,000 個並行。
• 第 0–120 秒期間，超出上限的呼叫被節流（同步 HTTP 429，非同步 SQS 重試 / DLQ）。

暴增容量不足時的解法

解法，依成本排序：

1. SnapStart — 在暴增時間窗口內加速預熱。
2. Provisioned Concurrency — 預熱 N 個沙箱，使從零暴增變成從 N 暴增。
3. 對吵雜鄰居使用 Reserved Concurrency — 防止其他函式耗盡池資源。
4. 配額提升 — 如果帳號總需求確實超過 1,000，透過 AWS Support 申請。

AWS Lambda 酬載限制——同步 6 MB / 非同步 256 KB

酬載大小是隱藏的 AWS Lambda 效能優化槓桿：硬性限制迫使你為大型資料採用不同的整合模式。

硬性限制

• 同步呼叫 — 請求與回應各 6 MB。
• 非同步呼叫 — 每個事件 256 KB。
• 事件來源映射批次 — SQS 每批次 6 MB，串流在批次限制內記錄數量實際上無上限。

S3 繞道方案

當酬載超過這些限制時，慣用模式是以 Amazon S3 作為資料載體：

1. 呼叫者將大型物件上傳至 S3（直接 PUT 或預簽名 URL）。
2. 呼叫者以小型指標事件（bucket + key）呼叫 AWS Lambda。
3. Lambda 從 S3 下載物件、處理，並將結果寫回 S3。
4. Lambda 回傳小型回應（結果 key 或狀態）。

此模式支援 GB 級酬載，Lambda 端沒有大小限制，代價是每次呼叫多兩次 S3 往返。AWS Lambda 大型資料效能優化 = S3 指標模式。

Amazon EFS 繞道方案

對於跨呼叫共享狀態的工作負載——大型參考資料集、模型產物、建置快取——Amazon EFS 可以在本地路徑掛載到 Lambda 執行環境。檔案系統在函式的所有暖沙箱和函式版本間共享。EFS 增加首次存取延遲（個位數毫秒），但移除了 250 MB 解壓縮上限和每次呼叫的 S3 下載成本。

決策規則：

• 暫時性大型酬載 → S3 指標模式。
• 持久性大型參考資料跨呼叫共享 → 掛載 Amazon EFS。
• 每沙箱的大型暫存資料 → /tmp，最多 10 GB。

AWS X-Ray 主動追蹤開銷

AWS X-Ray 主動追蹤是預設的可觀測性工具，但從 AWS Lambda 效能優化角度來看，它並非免費。

開銷概況

啟用主動追蹤時：

• 每個取樣的呼叫透過 X-Ray SDK 寫入追蹤片段。
• 片段序列化和傳輸為每次呼叫增加 1–5 毫秒。
• 下游呼叫的子片段各增加 0.5–2 毫秒。
• 預設取樣規則約為每秒 1 個請求加上超出部分的 5%——因此大多數呼叫成本很低。
• 在高取樣率（例如 100%）下，成本可達執行時間的 5–10%。

效能最佳實踐

• 取樣規則 — 對穩定流量取樣 1–5%；僅在除錯時段才使用 100%。
• Annotation vs Metadata — Annotation 建立索引（可篩選，按維度計費）；偏好對無限制的 key-value 資料使用 Metadata。
• 子片段預算 — 避免包裝每個函式呼叫；專注於下游網路呼叫（DynamoDB、HTTP API）。

在 DVA-C02 上，「不失去關鍵追蹤的情況下降低 X-Ray 帳單」→ 調整取樣規則，而非停用追蹤。

高效封裝——打包、搖樹優化、壓縮

高效封裝是基本的 AWS Lambda 效能優化，在 DVA-C02 上以「降低冷啟動」的形式出現。

Node.js / TypeScript

使用 esbuild（SAM CLI 透過 esbuild BuildMethod 的預設工具）或 webpack 將原始碼與依賴打包成單一檔案，搖樹優化移除無用程式碼並壓縮。典型的 Node.js Lambda 從 50 MB（node_modules + 原始碼）縮小至 1–5 MB 打包後——冷啟動成比例縮短。

# AWS SAM — esbuild 建置
Metadata:
  BuildMethod: esbuild
  BuildProperties:
    Minify: true
    Target: es2022
    External:
      - "@aws-sdk/*"   # 使用 Lambda 內建的 SDK v3

外部化 @aws-sdk/*（由 Lambda Node.js 18+/20+ 執行環境提供）進一步縮小套件。

Python

使用 pip install --target ./package + zip -r 產生最小 ZIP。排除 *.pyc、__pycache__、測試、文件。對於大型 ML 依賴，考慮 container image 以避免 250 MB 限制。

Java

使用 jlink 產生只包含所需模組的自訂 JRE，或使用 GraalVM native-image（搭配 AWS Lambda Custom Runtime）編譯成原生二進位，冷啟動可達數十毫秒。AWS SAM 支援 Gradle -Pfunction.package.type=Zip -Pfunction.package.optimized=true 進行 Layer 優化。

.NET

使用 dotnet publish -c Release -r linux-arm64 --self-contained false 針對託管 .NET 8 執行環境；啟用修剪（PublishTrimmed=true）以移除未使用的組件。

Go / Rust

針對 provided.al2023 執行環境編譯靜態二進位——冷啟動已是 100–200 毫秒，因為除了二進位啟動之外沒有執行環境 init。

非同步呼叫——Destinations vs DLQ 重試控制

非同步呼叫的 AWS Lambda 效能優化關鍵在於重試語義和失敗路由。

重試模型

非同步 AWS Lambda：

• 預設重試 = 額外 2 次（可設定 0/1/2），帶指數退避。
• 預設最大事件年齡 = 6 小時（可設定 60 秒–6 小時）。
• 所有重試失敗後，事件進入 Destination（on-failure）或 DLQ。

Destinations（現代，推薦）

Lambda Destinations 讓你將成功和失敗結果路由到四個目標之一：

• Amazon SQS — 用於失敗檢查的耐久佇列。
• Amazon SNS — 扇出警報。
• Amazon EventBridge — 結構感知路由、跨帳號。
• 另一個 AWS Lambda 函式 — 串接到補償工作流程。

Destinations 攜帶豐富的上下文：原始呼叫酬載、回應或錯誤、重試次數和呼叫元資料。這大幅簡化了分散式故障排查。

DLQ（舊版，仍在考試範圍）

Lambda Dead-Letter Queue 早於 Destinations。DLQ 是在函式上設定的單一 SQS 佇列或 SNS 主題；在最終失敗時，AWS Lambda 只寫入原始事件（無錯誤上下文）。DLQ 仍出現在 DVA-C02 上，因為許多實際帳號仍在使用它們。

選擇

• 新工作 → Destinations（on-failure + on-success）。
• 維持舊版一致性 → DLQ。
• 最佳實踐 → 兩者可同時設定；Destinations 在元資料豐富度上獲勝。

事件來源映射效能調校

輪詢式來源（SQS、Kinesis、DynamoDB Streams、MSK）有其專屬的 AWS Lambda 效能優化槓桿。

SQS 效能槓桿

• BatchSize（標準佇列 1–10，高吞吐量搭配 BatchWindow 最多 10,000）——每次呼叫更多訊息 = 每則訊息的開銷更低。
• MaximumBatchingWindowInSeconds — 最多等待 N 秒以填滿批次，再觸發呼叫。
• ScalingConfig.MaximumConcurrency（2022 年後）——獨立於 Reserved Concurrency，限制 SQS 驅動的並行。
• ReportBatchItemFailures — 回報部分批次失敗，只讓毒丸訊息回到佇列。

Kinesis / DynamoDB Streams 效能槓桿

• BatchSize 最多 10,000。
• ParallelizationFactor 1–10 — 每個分片並行執行最多 10 個 Lambda（打破每記錄順序，保留每分片鍵順序）。
• MaximumRecordAgeInSeconds — 跳過超過閾值的舊記錄，避免永遠卡在毒丸批次上。
• BisectBatchOnFunctionError — 對半重試以隔離失敗記錄。
• On-failure destination — 將失敗批次元資料發送至 SQS/SNS 進行分類。

SQS vs Kinesis 的 AWS Lambda 效能優化選擇

• SQS — 無限吞吐量（按 API 呼叫計費），無順序保證（標準）或每 MessageGroup 順序（FIFO），無重播，簡單重試語義。
• Kinesis — 每分片有序，每分片 1 MB/s 入 / 2 MB/s 出（或每消費者 2 MB/s 的增強扇出），最多可重播 7 天（延伸保留 365 天），帶退避的批次處理。

DVA-C02 經常問「需要重播的高吞吐事件處理」→ Kinesis；「每訊息重試的簡單佇列」→ SQS。

DVA-C02 的 AWS Lambda 效能優化陷阱

了解陷阱的分數與了解功能一樣多。

陷阱一——Provisioned vs Reserved 名稱混淆

Reserved 聽起來像「預先保留容量」，但不會預先預熱沙箱——它只是從池中劃出一塊。Provisioned 才是預熱的那一個。每次看到這兩個詞時，都要慢慢重新讀一遍。

陷阱二——SnapStart 唯一性繼承

模組層級的 UUID.randomUUID() 在 SnapStart 快照中捕獲後，所有還原的沙箱都會產生相同的值。務必在 afterRestore 鉤子中重新播種唯一性。

陷阱三——VPC 冷啟動不再是罪魁禍首

Hyperplane ENI 之後，VPC 冷啟動開銷是數十毫秒，而非數秒。如果 2024 年的情境將 10 秒冷啟動歸咎於「VPC」，答案幾乎總是在其他地方（大型套件、繁重的 JVM init、缺少 SnapStart）。

陷阱四——全域 Init 與 Handler 內部

在 handler 內部寫 new DynamoDBClient() 每次呼叫都會執行；在 handler 外部則每個沙箱只執行一次。永遠將 SDK client、DB 連線池和密鑰取回器提升到全域範圍。

陷阱五——超量酬載透過 S3 繞道

當情境描述「處理 100 MB 檔案」時，Lambda 本身無法接收 100 MB——呼叫者必須上傳至 S3 並傳遞指標。「以 100 MB 酬載呼叫 Lambda」永遠是干擾選項。

陷阱六——Function URL vs API Gateway 延遲

Function URL 是到達 Lambda 的最快路徑（約 5–10 毫秒開銷），但缺少 Cognito 授權方、映射範本和使用計劃。如果情境提到這些功能中的任何一個，答案就是 API Gateway。

陷阱七——arm64 與原生二進位不相容

切換至 arm64 Graviton2 節省 20%，但會破壞任何純 x86_64 的原生二進位。在切換之前驗證依賴相容性。

陷阱八——Destinations 和 DLQ 與同步失敗無關

Destinations 和 DLQ 都不會在同步 AWS Lambda 失敗時觸發——僅在非同步失敗時觸發。「API Gateway → Lambda 失敗，為什麼 DLQ 是空的？」因為 DLQ 只接收非同步失敗。

AWS Lambda 效能優化決策矩陣

整合後的決策矩陣，將症狀對應到槓桿。

症狀：冷啟動高 p99 延遲

1. 縮小套件（打包工具、搖樹優化、arm64 原生）。
2. 將偶爾使用的 import 延遲載入到 handler 內部。
3. 啟用 SnapStart（Java 11/17/21、Python 3.12+、.NET 8+）。
4. 對可預測的流量暴增啟用 Provisioned Concurrency。

症狀：暖呼叫高 p50 延遲

1. 將 SDK client 和 DB 連線池提升至全域範圍。
2. 執行 AWS Lambda Power Tuning 提升記憶體（CPU 密集型）。
3. 使用 Parameters and Secrets Lambda Extension 快取密鑰。
4. 在 /tmp 或全域變數中快取參考資料。
5. 對 I/O 密集型模式，考慮使用 Step Functions Express 並行化，而非在單一 handler 內順序執行。

症狀：流量暴增時函式遭節流

1. 提升對暴增並行的認識——確認 500/1,000/3,000 的區域初始暴增限制。
2. 為前 N 個並行啟用 Provisioned Concurrency。
3. 申請帳號並行配額提升。
4. 對吵雜鄰居新增 Reserved Concurrency，以保護此函式。

症狀：Lambda 壓垮下游服務

1. 將 Reserved Concurrency 設為下游容量。
2. 對資料庫後端工作負載使用 RDS Proxy。
3. 將觸發器切換為 SQS，並調校 BatchSize + MaximumConcurrency 以平滑流量暴增。

症狀：帳單過高

1. 使用 cost 策略執行 AWS Lambda Power Tuning。
2. 切換至 arm64 Graviton2（每 GB-second 降低 20%）。
3. 檢查 handler 內部的靜默重複工作，是否能移至全域 init。
4. 稽核 Lambda Extensions——每個 Extension 都計入函式 GB-seconds。
5. 在生產環境降低 X-Ray 取樣率。

症狀：事件超過 6 MB

1. 切換至 S3 指標模式——上傳至 S3，以 bucket+key 呼叫 Lambda。
2. 對共享參考資料，掛載 Amazon EFS。
3. 對高吞吐事件扇出，保持事件小型並在 S3 中儲存酬載。

AWS Lambda 效能優化限制速查表

將以下 AWS Lambda 效能優化數字背得滾瓜爛熟：

• 記憶體 — 128 MB–10,240 MB；1,769 MB = 1 vCPU；10,240 MB ≈ 6 vCPU。
• 逾時 — 最長 900 秒（15 分鐘）；預設 3 秒。
• 暫時 /tmp — 預設 512 MB，最多 10,240 MB。
• 部署套件 — 50 MB 直接 ZIP，透過 S3 解壓縮後 250 MB，container image 10 GB。
• 酬載 — 同步 6 MB / 非同步 256 KB。
• Layers — 每函式 5 個，組合解壓縮後 250 MB。
• 環境變數 — 總計 4 KB。
• 帳號並行 — 預設 1,000（軟性），可提升。
• 暴增並行 — 依區域 500 / 1,000 / 3,000；之後每分鐘 +1,000。
• 非同步重試 — 0 / 1 / 2（預設 2 = 共 3 次嘗試）。
• 最大事件年齡 — 60 秒–6 小時（預設 6 小時）。
• SnapStart 還原延遲 — 通常 100–400 毫秒。
• Provisioned Concurrency 自動擴展 — 透過 Application Auto Scaling（排程或基於使用率的目標追蹤）。
• arm64 折扣 — 每 GB-second 比 x86_64 便宜約 20%。

FAQ——AWS Lambda 效能優化

Q1. DVA-C02 上最快降低 AWS Lambda 冷啟動延遲的方法是什麼？

最便宜、最快的冷啟動 AWS Lambda 效能優化是縮小部署套件——使用 esbuild 對 Node.js/TypeScript 進行打包和搖樹優化、修剪未使用的 Python 依賴，或為 Go/Rust 提供 arm64 原生二進位。2 MB 套件比 50 MB 原始 ZIP 冷啟動快 2–3 倍，且零成本。只有在縮小套件之後，才有必要啟用 AWS Lambda SnapStart（Java、Python 3.12+、.NET 8+）或 Provisioned Concurrency（任何執行環境）。這三個槓桿——縮小、快照、預熱——構成你按順序爬的冷啟動階梯。

Q2. 何時應該選擇 Provisioned Concurrency、SnapStart 還是 Reserved Concurrency？

Provisioned Concurrency 是暴力預熱槓桿——按每 GB-second 付費，讓 N 個沙箱完全初始化，使前 N 個並行呼叫不遭遇冷啟動。SnapStart 是對支援執行環境（Java/Python/.NET）的免費或便宜快照槓桿——在 100–400 毫秒內還原 INIT 後的快照，消除大部分冷啟動痛點，無需為閒置容量付費。Reserved Concurrency 是節流槓桿——它保障容量下限並限制函式的最大並行，同時保護函式（免於被吵雜鄰居耗盡）和下游服務（免於被壓垮）。AWS Lambda 效能優化通常結合三者：SnapStart 提速、Provisioned 應對可預測暴增、Reserved 保護 RDS 或第三方 API。

Q3. 如何找到 AWS Lambda 的最佳記憶體設定？

使用 AWS Lambda Power Tuning——一個開源的 Step Functions 狀態機，可從 AWS Serverless Application Repository 部署。傳入函式 ARN、具代表性的酬載和記憶體大小清單（例如 [128, 512, 1024, 1792, 3008, 5120, 10240]），加上策略（speed、cost 或 balanced）。狀態機在每個記憶體大小下呼叫函式 N 次，並回傳標示最佳點的視覺化結果。對於 CPU 密集型工作負載，最佳點通常高於直覺預期——1,792 MB 或 3,008 MB——因為 CPU 與記憶體線性對應（1,769 MB = 1 個完整 vCPU，10,240 MB ≈ 6 個 vCPU），較短的執行時間往往超過每毫秒成本的增加。

Q4. AWS Lambda SnapStart 是什麼？支援哪些執行環境？

AWS Lambda SnapStart 在已發布版本的 INIT 階段完成之後對執行環境進行快照並快取。後續冷啟動時，AWS Lambda 在約 100–400 毫秒內從快照還原，而非重新執行 INIT——這對 Java 而言是革命性的（冷啟動從 1–6 秒降至 200–400 毫秒）。截至 DVA-C02 v2.1 範圍，SnapStart 支援 Java 11、17、21、Python 3.12+ 和 .NET 8+。關鍵陷阱是唯一性重新播種：模組層級中每個沙箱必須唯一的狀態（RNG 種子、UUID、已快取憑證、DB 連線 ID）將被凍結到快照中，並被每次還原繼承。在 afterRestore callback 中透過 CRaCResource（Java）或 beforeSnapshot / afterRestore（Python、.NET）鉤子重新播種。

Q5. AWS Lambda 執行環境重用如何加速暖呼叫？

AWS Lambda 跨呼叫凍結並重用執行環境，因此你在模組層級（handler 外部）執行的任何程式碼，在 INIT 期間恰好執行一次，其結果對所有暖呼叫都保留在記憶體中。AWS Lambda 效能優化模式是將 AWS SDK client（持有 HTTPS keep-alive 連線池）、資料庫連線池、已快取密鑰和參考資料提升至模組層級；handler 然後重用它們。這個單一重構通常將 p50 延遲降低 20–100 毫秒，並將 RDS 連線抖動減少 95% 以上。反模式是在 handler 內部建立新的 client 或連線——這會在每次呼叫時強制執行 TLS 握手和連線開啟。

Q6. Hyperplane ENI 如何影響 AWS Lambda VPC 效能？

2019 年之前，將 AWS Lambda 附加到 VPC 會為每個沙箱建立專屬 ENI，為冷啟動增加 10 秒以上的時間，並在大規模時耗盡帳號 ENI 限制。AWS Lambda 現在使用 Hyperplane ENI——一個共享的 NAT/代理層，在函式設定時延遲佈建少量 ENI 池，並將數千個並行沙箱多工複用到其上。目前的 VPC 冷啟動開銷是數十毫秒，而非數秒。然而，私有子網路中的 VPC 附加 AWS Lambda 仍然沒有網際網路存取，需要 NAT Gateway（對公用 API）或 VPC Endpoint（對 AWS 服務——S3/DynamoDB 優先使用 Gateway Endpoint，Secrets Manager、KMS、STS 使用 Interface Endpoint）。在 DVA-C02 上，「VPC 中的 Lambda 呼叫外部 API 逾時」= 缺少 NAT 或缺少 Endpoint，而非冷啟動。

Q7. 何時應將 AWS Lambda 切換至 arm64 Graviton2？

只要依賴圖支援，就切換至 arm64 Graviton2——一次設定變更即可獲得每 GB-second 便宜約 20% 的計費，且實際工作負載通常快 5–15%。相容性要求：（1）執行環境必須支援 arm64（Python、Node.js、Java、Ruby、.NET 6/8、provided.al2023 都支援）；（2）container image 必須為 linux/arm64 建置；（3）捆綁的原生二進位（Go、Rust、C 擴展）必須為 arm64 編譯；（4）原生 Python/Node.js 依賴（NumPy、Pandas、Sharp、Prisma）必須有 arm64 wheel——大多數主要函式庫現在都有。在 DVA-C02 上，「無程式碼變更降低 Lambda 成本 20%」是標準的 arm64 Graviton2 情境。

Q8. 如何處理超過 6 MB 的 AWS Lambda 酬載？

AWS Lambda 硬性限制為同步 6 MB（請求和回應）和非同步每事件 256 KB。對於較大的資料，使用 Amazon S3 指標模式：呼叫者將大型物件上傳至 S3（直接 PUT 或預簽名 URL），然後以包含 {bucket, key} 的小型事件呼叫 AWS Lambda。Handler 從 S3 下載、處理，並將結果寫回 S3，只回傳狀態或結果 key。對於跨呼叫共享的持久性大型參考資料（ML 模型、查找表），在本地路徑掛載 Amazon EFS——EFS 在函式的所有暖沙箱間共享，並移除 250 MB 解壓縮套件上限。對每沙箱最多 10 GB 的暫存資料，使用 /tmp 暫時儲存。這三個繞道方案涵蓋 DVA-C02 上每一個「Lambda 無法處理大酬載」的情境。

Q9. Lambda Destinations 與非同步呼叫的 DLQ 有何差異？

Destinations 和 DLQ 都在所有重試耗盡後（預設 2 次重試，可設定 0–2）捕獲非同步 AWS Lambda 失敗。DLQ（舊版）是在函式上設定的單一 SQS 佇列或 SNS 主題，只接收原始事件——無錯誤上下文、無回應、無重試次數。Lambda Destinations（現代，推薦）讓你為成功和失敗設定跨四種服務類型（SQS、SNS、EventBridge、另一個 Lambda）的目標，並攜帶豐富上下文：原始事件、回應或錯誤、重試次數、呼叫元資料。Destinations 是 DVA-C02 對新非同步工作的推薦答案；DLQ 仍在範圍內，因為許多遺留系統仍在使用它。兩者都不會在同步呼叫失敗時觸發——同步失敗將錯誤回傳給呼叫者，呼叫者負責重試。

Q10. 哪個記憶體設定讓 AWS Lambda 獲得完整一個 vCPU？為何重要？

AWS Lambda 與記憶體線性分配 CPU。需要背記的錨點：1,769 MB = 1 個完整 vCPU，3,538 MB ≈ 2 個 vCPU，5,307 MB ≈ 3 個 vCPU，10,240 MB ≈ 6 個 vCPU。之所以重要，是因為大多數 CPU 密集型工作負載（圖片處理、PDF 渲染、加密、大型 JSON 解析、壓縮）在低於 1,769 MB 時效能顯著較差——512 MB 的函式通常比 1,792 MB 的函式慢 3 倍，而由於 AWS Lambda 按 GB-seconds 計費，高記憶體版本往往既更快又更便宜。因此，透過記憶體調校進行 AWS Lambda 效能優化，很少是「最小記憶體 = 最低成本」；執行 AWS Lambda Power Tuning，讓資料驅動選擇。

摘要——AWS Lambda 效能優化一覽

• AWS Lambda 效能優化是 DVA-C02 的 Task 4.3——四個維度（延遲、吞吐量、成本、可靠性）由針對三個生命週期階段（INIT、INVOKE、SHUTDOWN）的槓桿控制。
• 記憶體是首要旋鈕——128 MB–10,240 MB 線性對應到 CPU（1,769 MB = 1 vCPU，10,240 MB = 6 vCPU）；使用 AWS Lambda Power Tuning 找出實測最佳點。
• 冷啟動是執行環境啟動 + 套件載入 + 函式 init 的複合體；透過（1）縮小套件、（2）SnapStart（Java/Python/.NET）、（3）Provisioned Concurrency（任何執行環境）緩解。
• SnapStart 快照 INIT 後的狀態，在 100–400 毫秒內還原；務必在 afterRestore 鉤子中重新播種唯一性（RNG、UUID、DB 連線 ID）。
• Provisioned Concurrency 預熱 N 個沙箱，使最多 N 個並行零冷啟動；與 Application Auto Scaling 整合。
• Reserved Concurrency 是下限加上限——保護函式並限制下游影響。
• 執行環境重用 — 將 SDK client 和 DB 連線池提升至全域範圍，節省 20–100 毫秒 p50；使用 RDS Proxy 大規模池化資料庫連線。
• VPC 冷啟動在 Hyperplane ENI 之後是數十毫秒；使用 VPC Endpoint（AWS 服務）或 NAT Gateway（公用網際網路）進行輸出。
• arm64 Graviton2 一行設定變更換來約 20% 費用效能提升，前提是依賴相容。
• Lambda Layers 以可分享性換取 INIT 時間——對冷啟動而言，打包通常優於 Layers。
• Lambda Extensions 計入函式 GB-seconds；Parameters and Secrets Lambda Extension 是快取 Secrets Manager / Parameter Store 值的標準答案。
• Function URL 是進入 Lambda 的最低延遲 HTTPS 入口（約 5–10 毫秒開銷）；API Gateway 增加 20–50 毫秒，換取認證、節流和映射範本。
• 並行配額 — 預設 1,000，暴增 500/1,000/3,000，每分鐘 +1,000 擴展。
• 酬載限制 — 同步 6 MB / 非同步 256 KB；對較大資料使用 S3 指標模式或 Amazon EFS。
• 高效封裝（esbuild/webpack、修剪 Python、arm64 原生、GraalVM）是最便宜的冷啟動改善。
• Destinations 取代 DLQ 用於現代非同步失敗路由；兩者都只在非同步時觸發，同步永不觸發。
• 事件來源映射 — 調校 BatchSize、MaximumBatchingWindowInSeconds、ParallelizationFactor 和 ReportBatchItemFailures 以提升串流和佇列吞吐量。

掌握這些 AWS Lambda 效能優化槓桿，Task 4.3 將成為整個 DVA-C02 考試中準確率最高的章節——而這些技能也直接轉移到生產環境中運行 serverless 系統，這才是認證的真正意義所在。