本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 使用 AWS Lambda 函數的最佳實務
以下是使用 AWS Lambda的推薦最佳實務：
**Topics**
+ [函數程式碼](#function-code)
+ [函數組態](#function-configuration)
+ [函數可擴展性](#function-scalability)
+ [指標與警示](#alarming-metrics)
+ [使用串流](#stream-events)
+ [安全最佳實務](#security-best-practices)
## 函數程式碼
**請利用執行環境重新使用來改看函式的效能。**在函式處理常式之外初始化 SDK 用戶端和資料庫連線，並在本機快取 `/tmp` 目錄中的靜態資產。由您函式的相同執行個體處理的後續叫用可以重複使用這些資源。這可藉由減少函數執行時間來節省成本。
若要避免叫用間洩漏潛在資料，請不要使用執行環境來儲存使用者資料、事件，或其他牽涉安全性的資訊。如果您的函式依賴無法存放在處理常式內記憶體中的可變狀態，請考慮為每個使用者建立個別函式或個別函式版本。
**使用 Keep-Alive 指令維持持續連線的狀態。**Lambda 會隨著時間的推移清除閒置連線。叫用函數時嘗試重複使用閒置連線將導致連線錯誤。若要維護持續連線，請使用與執行階段相關聯的 keep-alive (保持啟用) 指令。如需範例，請參閱[在 Node.js 中重複使用 Keep-Alive 的連線](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/node-reusing-connections.html)。
**使用[環境變數](configuration-envvars.md)將操作參數傳遞給您的函數。**例如，如果您正在寫入到 Amazon S3 儲存貯體，而非對您正在寫入的儲存貯體名稱進行硬式編碼，請將儲存貯體名稱設定為環境變數。
**避免在 Lambda 函數中使用遞迴調用**，其中函數會調用自己或啟動可能再次調用函數的程序。這會導致意外的函式呼叫量與升高的成本。若您看到意外的調用數量，當更新程式碼時，請立刻將函數的預留並行設為 `0`，以調節對函數的所有調用。
**請勿在您的 Lambda 函數程式碼中使用未記錄的非公有 API**。對於 AWS Lambda 受管執行期，Lambda 會定期將安全性和功能更新套用至 Lambda 的內部 APIs。這些內部 API 更新可能是向後不相容的，這會導致意外結果，例如若您的函數依賴於這些非公有 API，則叫用失敗。請參閱 [API 參考](https://docs.aws.amazon.com/lambda/latest/api/welcome.html)查看公開可用 API 的清單。
**撰寫等冪程式碼。**為函數撰寫等冪程式碼可確保採用相同方式來處理重複事件。程式碼應正確驗證事件並正常處理重複的事件。如需詳細資訊，請參閱 [How do I make my Lambda function idempotent?](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-function-idempotent/) (如何讓 Lambda 函數等冪？)。
**注意**
您可以使用 Powertools for AWS Lambda 讓函數成為等冪。如需詳細資訊，請參閱：
[Python – 冪等性公用程式](https://docs.aws.amazon.com/powertools/python/latest/utilities/idempotency/)
[TypeScript – 冪等性公用程式](https://docs.aws.amazon.com/powertools/typescript/latest/features/idempotency/)
[Java – 冪等性公用程式](https://docs.aws.amazon.com/powertools/java/latest/utilities/idempotency/)
[.NET – 冪等性公用程式](https://docs.aws.amazon.com/powertools/dotnet/utilities/idempotency/)
如需語言特定的程式碼最佳實務，請參閱下列章節：
+ [Node.js Lambda 函數的程式碼最佳實務](nodejs-handler.md#nodejs-best-practices)
+ [TypeScript Lambda 函式的程式碼最佳實務](typescript-handler.md#typescript-best-practices)
+ [Python Lambda 函數的程式碼最佳實務](python-handler.md#python-handler-best-practices)
+ [Ruby Lambda 函數的程式碼最佳實務](ruby-handler.md#ruby-best-practices)
+ [Java Lambda 函數的程式碼最佳實務](java-handler.md#java-best-practices)
+ [Go Lambda 函數的程式碼最佳實務](golang-handler.md#go-best-practices)
+ [C\$1 Lambda 函數的程式碼最佳實務](csharp-handler.md#csharp-best-practices)
+ [Rust Lambda 函數的程式碼最佳實務](rust-handler.md#rust-best-practices)
## 函數組態
**啟動您的 Lambda 函式的效能測試**是確保您挑選最佳記憶體大小組態非常重要的一環。任何記憶體大小的增加能觸發相同的增加可用於函數的 CPU。函數的記憶體用量取決於每個呼叫，且可以在 [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatchLogs.html) 中檢視。每一次呼叫會產生 `REPORT:` 項目，如下所示：
```
REPORT RequestId: 3604209a-e9a3-11e6-939a-754dd98c7be3 Duration: 12.34 ms Billed Duration: 100 ms Memory Size: 128 MB Max Memory Used: 18 MB
```
藉由分析 `Max Memory Used:` 欄位，您可以判斷您的函式是否需要更多記憶體，或是否過度佈建函式記憶體大小。
**若要為您的函數尋找正確的記憶體組態**，我們建議您使用開放原始碼 AWS Lambda Power Tuning 專案。如需詳細資訊，請參閱 GitHub 上的 [AWS Lambda 電源調校](https://github.com/alexcasalboni/aws-lambda-power-tuning)。
若要最佳化函數效能，我們也建議部署可充分利用進階向量延伸 2 (AVX2) 的程式庫。這可讓您處理繁重的工作負載，包括機器學習推論、媒體處理、高效能運算 (HPC)、科學模擬和財務建模。如需詳細資訊，請參閱[使用 AVX2 建立更快的 AWS Lambda 函數](https://aws.amazon.com/blogs/compute/creating-faster-aws-lambda-functions-with-avx2/)。
**對您的 Lambda 函數進行負載測試**以判斷最佳的逾時值。分析您的函式執行多久時間是很重要的，如此您更能判斷任何相依服務的問題，這可能會增加超出預期的函式並行。當您的 Lambda 函數對可能無法處理 Lambda 擴展的資源發出網路呼叫時，這尤其重要。如需有關應用程式負載測試的詳細資訊，請參閱 [AWS上的分散式負載測試](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/)。
**設定 IAM 政策時，使用最嚴苛的許可。**了解您的 Lambda 函數需要的資源與操作，並限制這些許可的執行角色。如需詳細資訊，請參閱[在 中管理許可 AWS Lambda](lambda-permissions.md)。
**熟悉 [Lambda 配額Lambda 配額](gettingstarted-limits.md)。**承載大小、檔案描述項與 /tmp 空間，是在判斷執行時間資源限制時經常忽略的。
**刪除您不再使用的 Lambda 函數。**透過上述方法，未使用的函式不會對您的部署套件大小限制做不必要的計算。
**如果您使用 Amazon Simple Queue Service** 作為事件來源，請確保函數的預期叫用時間值不會超過佇列上的[可見性逾時](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html)值。這同時適用於 [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html) 和 [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)。
+ 在 **CreateFunction** 的情況下， AWS Lambda 會失敗函數建立程序。
+ 如果是 **UpdateFunctionConfiguration**，則可能會導致重複呼叫函數。
## 函數可擴展性
**熟悉您的上游和下游輸送量限制。**雖然 Lambda 函數可隨負載進行無縫擴展，但上游和下游相依性可能不具有相同的輸送量能力。如果需要限制函數可擴展的高度，則可以在函數中[設定預留並行](configuration-concurrency.md)。
**在節流容限中建置。**如果同步函數因為流量超過 Lambda 的擴展速率而遇到限流，則可以使用下列策略來改善限流容錯：
+ **使用[逾時、重試和退避 (具有抖動)](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)**。實作這些策略可順利完成重試的調用，並有助於確保 Lambda 可以在幾秒鐘內向上擴展，以最大程度減少最終使用者限流。
+ **使用[佈建並行](provisioned-concurrency.md)**。佈建並行是 Lambda 分配給函數的預先初始化執行環境的數目。Lambda 會在可用時使用佈建並行來處理傳入請求。如有需要，Lambda 也可以擴展函數，使其超過佈建並行設定。設定佈建並行會對 AWS 您的帳戶產生額外費用。
## 指標與警示
**使用 [將 CloudWatch 指標與 Lambda 搭配使用](monitoring-metrics.md) 與 [CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)**，而非建立或更新 Lambda 函數程式碼內的指標。這是追蹤 Lambda 函數運作狀態的更有效率方式，可讓您盡快在開發階段找出問題。例如，您可以根據預期的 Lambda 函數叫用持續時間來設定警示，以解決任何由函數程式碼導致的瓶頸或延遲。
**使用內嵌指標格式 (EMF) 以非同步方式發出自訂指標。**使用 EMF 透過函式的日誌發出指標，而不是向 CloudWatch 發出同步 API 呼叫。此方法可以減少延遲並改善效能。Powertools for AWS Lambda 中的 Metrics 公用程式會自動處理 EMF 格式。如需詳細資訊，請參閱 Powertools for AWS Lambda 文件中的 [Python](https://docs.aws.amazon.com/powertools/python/latest/core/metrics/)、[TypeScript](https://docs.aws.amazon.com/powertools/typescript/latest/features/metrics/)、[Java](https://docs.aws.amazon.com/powertools/java/latest/core/metrics/) 或 [.NET](https://docs.aws.amazon.com/powertools/dotnet/core/metrics/) Metrics 公用程式。如需使用 EMF 產生指標格式日誌的資訊，請參閱 Amazon CloudWatch User Guide 中的 [Publishing logs with the embedded metric format](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Generation.html)。
**使用結構化 JSON 記錄以提高可觀測性。**結構化記錄可讓您更輕鬆地搜尋、篩選和分析函式的日誌。請考慮使用 Powertools for 的 Logger 公用程式 AWS Lambda ，在 JSON 中自動格式化日誌。如需詳細資訊，請參閱 Powertools for AWS Lambda 文件中的 [Python](https://docs.aws.amazon.com/powertools/python/latest/core/logger/)、[TypeScript](https://docs.aws.amazon.com/powertools/typescript/latest/features/logger/)、[Java](https://docs.aws.amazon.com/powertools/java/latest/core/logging/) 或 [.NET](https://docs.aws.amazon.com/powertools/dotnet/core/logging/) Logger 公用程式。
**利用您的記錄程式庫與 [AWS Lambda 指標與維度](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/lam-metricscollected.html)**，找出應用程式錯誤 (例如，ERR、ERROR、WARNING 等等)。
**使用 [AWS 成本異常偵測](https://docs.aws.amazon.com/cost-management/latest/userguide/manage-ad.html)**來偵測帳戶中的異常活動。成本異常偵測會使用機器學習來持續監控您的成本和使用量，同時盡可能減少誤報警示。成本異常偵測使用來自 的資料 AWS Cost Explorer，最多可延遲 24 小時。因此，使用後最多可能需要 24 小時才能偵測到異常。若要開始使用成本異常偵測，您必須先使用[註冊 Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-enable.html)。然後，[存取成本異常偵測](https://docs.aws.amazon.com/cost-management/latest/userguide/settingup-ad.html#access-ad)。
## 使用串流
**使用不同的批次與記錄大小測試**讓每個事件來源的輪詢頻率調整為函式可以多快完成作業。[CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) 批次大小參數控制每次呼叫時能傳送至您函數的記錄上限。更大的批次大小通常會更有效吸收更大集合的記錄的呼叫成本，增加您的傳輸量。
Lambda 預設會在記錄可用時立即叫用函數。如果 Lambda 從事件來源中讀取的批次只有一筆記錄，Lambda 只會傳送一筆記錄至函數。為避免調用具有少量記錄的函數，您可設定*批次間隔*，請求事件來源緩衝記錄最長達五分鐘。調用函數之前，Lambda 會繼續從事件來源中讀取記錄，直到收集到完整批次、批次間隔到期或者批次達到 6 MB 的承載限制。如需詳細資訊，請參閱[批次處理行為](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching)。
**警告**
Lambda 事件來源映射至少會處理每個事件一次，而且可能會重複處理記錄。為避免與重複事件相關的潛在問題，強烈建議您讓函數程式碼具有等冪性。若要進一步了解，請參閱 AWS 知識中心中的[如何使 Lambda 函數具有等冪性](https://repost.aws/knowledge-center/lambda-function-idempotent)。
**啟用部分批次回應以進行串流處理。**處理來自 Kinesis 或 DynamoDB Streams 等串流的記錄批次時，請啟用部分批次回應，以允許 Lambda 僅重試失敗的記錄，而不是重試整個批次。這樣可以提高處理效率並減少不必要的重新處理。您可以選擇使用 Powertools for 的 Batch 公用程式 AWS Lambda 來簡化批次處理模式。
**注意**
您可以使用適用於 的 Powertools AWS Lambda 進行批次處理。如需詳細資訊，請參閱：
[Python – 批次處理](https://docs.aws.amazon.com/powertools/python/latest/utilities/batch/)
[TypeScript – 批次處理](https://docs.aws.amazon.com/powertools/typescript/latest/features/batch/)
[Java – 批次處理](https://docs.aws.amazon.com/powertools/java/latest/utilities/batch/)
[.NET – 批次處理](https://docs.aws.amazon.com/powertools/dotnet/utilities/batch-processing/)
**新增碎片以增加 Kinesis 串流處理輸送量。**Kinesis 串流由一個或多個碎片組成。Lambda 可從 Kinesis 讀取資料的速率會隨著碎片數量而線性擴展。增加碎片的數量會直接增加最大並行 Lambda 函數叫用的數量，還會增加 Kinesis 串流處理輸送量。如需碎片與函數調用之間的關係詳細資訊，請參閱 [輪詢和批次處理串流](with-kinesis.md#kinesis-polling-and-batching)。如果您正在增加 Kinesis 串流中碎片的數量，請確保為您的資料挑選良好的分割區索引鍵 (請參閱[分割區索引鍵](https://docs.aws.amazon.com/streams/latest/dev/key-concepts.html#partition-key))，如此一來，相關的記錄會位於相同的碎片上，您的資料也會獲得妥善的分配。
在 IteratorAge 上**使用 [Amazon CloudWatch](https://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html)**，判斷是否正在處理您的 Kinesis 串流。例如，將 CloudWatch 警示的最大設定設為 30000 (30 秒)。
## 安全最佳實務
**使用 監控 的使用情況， AWS Lambda 因為它與安全最佳實務相關 AWS Security Hub CSPM。**Security Hub CSPM 使用安全控制來評估資源組態和安全標準，以協助您符合各種合規架構。如需使用 Security Hub CSPM 評估 Lambda 資源的詳細資訊，請參閱 AWS Security Hub CSPM 《 使用者指南》中的[AWS Lambda 控制項](https://docs.aws.amazon.com/securityhub/latest/userguide/lambda-controls.html)。
**使用 Amazon GuardDuty Lambda Protection 監控 Lambda 網路活動日誌。**GuardDuty Lambda 保護可協助您在 中叫用 Lambda 函數時識別潛在的安全威脅 AWS 帳戶。例如，如果其中一個函數查詢與加密貨幣相關活動相關聯的 IP 位址。GuardDuty 會監控調用 Lambda 函數時產生的網路活動日誌。若要進一步了解，請參閱《*Amazon GuardDuty 使用者指南*》中的 [Lambda Protection](https://docs.aws.amazon.com/guardduty/latest/ug/lambda-protection.html)。