本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# Lambda Web Functions 的最佳實務
<a name="web-functions-best-practices"></a>

## 保護每個端點
<a name="web-functions-best-practices-security"></a>

每個端點都可以從網際網路存取，因此您驗證來電者、設定前門的方式，以及範圍許可會決定誰可以連接您的應用程式及其可存取的內容。使用下列實務：
+ 每個端點都可以從網際網路存取，無論其身分驗證類型為何。使用 `ApplicationManaged`時，Lambda 不會驗證請求，因此任何知道網域的用戶端都可以呼叫您的應用程式。在應用程式或前門中實作身分驗證、授權、輸入驗證、請求大小檢查和濫用保護。
+ 當發起人可以簽署請求，且 IAM 政策提供必要的授權模型`IamAuth`時，請使用 。將資源政策範圍限定在特定端點 ARNs 和主體。
+ 當您需要自訂網域、 AWS WAF 檢查、快取或集中式邊緣控制時，請將 Amazon CloudFront 或 Amazon API Gateway 放在端點前面。限制原始伺服器，讓用戶端無法繞過前門。使用 CloudFront 時，請使用`IamAuth`端點和原始存取控制 (OAC)，如中所述[CloudFront 整合](web-functions-endpoint-access-control.md#web-functions-endpoint-access-control-cloudfront)。若使用其他前門，端點仍可直接連線，因此請在應用程式中驗證共用秘密或權杖。
+ 使用具有最低權限許可的專用執行角色。分隔部署身分、程式碼上傳者、Lambda 服務主體、執行角色和端點發起人許可。
+ 請勿將秘密放在部署套件或日誌中。在執行時間從適當的秘密存放區載入秘密、僅視需要快取秘密，以及修改敏感的請求欄位。

## 保留不可變的部署成品
<a name="web-functions-best-practices-artifacts"></a>
+ 在程式碼儲存貯體上啟用版本控制，並記錄每個部署的物件版本 ID。
+ 請勿覆寫或刪除作用中或轉返修訂所使用的物件版本。只要修訂版參考物件，保留 Lambda 服務主體存取權。
+ 在可重複的管道中建置部署套件。從鎖定檔案安裝生產相依性、排除開發檔案，並在上傳之前測試確切的封存。
+ 建置 Arm64 的原生相依性。針對 x86\_64 建置的原生模組不會在 Web 函數執行環境中執行。
+ 當環境有不同的信任或保留要求時，請使用不同的儲存貯體、字首、角色或帳戶。

## 並行請求的設計
<a name="web-functions-best-practices-runtime"></a>
+ 將請求特定資料保留在請求範圍內。請勿在全域變數中存放登入資料、客戶資料、回應物件或可變的每次請求狀態。
+ 使用非同步 I/O。 同步 CPU 或檔案系統工作會封鎖Node.js事件迴圈，並延遲環境中的每個傳輸中請求。
+ `worker_threads` 用於應該使用多個 vCPUs或更低的 CPU 密集型工作`maxConcurrencyPerEnvironment`，以減少爭用。
+ 將Node.js堆積與環境記憶體分開計算。環境有 2 GB，而預設 V8 堆積為 1，024 MB。如果您在 `--max-old-space-size`中使用 提升堆積`NODE_OPTIONS`，請保留緩衝區、原生模組、執行時間和並行請求的記憶體。
+ 在請求之間重複使用初始化的用戶端和連線集區，但驗證過時的連線和繫結快取成長。在執行環境外持續必要狀態。
+ 讓傳出連線保持運作狀態，以便對資料庫和其他相依性的請求重複使用它們，而不是每次開啟新的連線。 會在其全域 HTTP 代理程式中預設Node.js啟用保持連線。如果您建立自己的代理程式或設定 SDK 用戶端，請保持啟用狀態。同時處理遠端在閒置時關閉的連線。
+ 使用臨時檔案的唯一名稱，並在不再需要它們時將其移除。多個請求共用環境的 512 MB `/tmp` 檔案系統，而且檔案可以在請求之間保留，直到環境移除為止。

## 保持可預測的啟動
<a name="web-functions-best-practices-startup"></a>
+ 立即啟動 HTTP 伺服器，並接聽 的確切值`AWS_LAMBDA_HTTP_ENDPOINT`。
+ 保持套件小型，並移除未使用的生產相依性。
+ 僅初始化伺服器可接受流量之前所需的資源。延遲執行選用工作，但防止並行請求重複昂貴的初始化。
+ `SIGTERM` 處理在 1 秒內完成的清除，但不依賴關機回呼來保留所需的資料。

## 設定測量行為的限制
<a name="web-functions-best-practices-scaling"></a>
+ 使用與生產中使用的相同應用程式相依性和下游服務進行負載測試。增加並行，直到延遲、CPU 耗用量、記憶體或下游容量成為繫結限制條件為止。
+ 使用 `maxConcurrencyPerEnvironment`來繫結每個程序爭用、`maxEnvironments`繫結水平擴展，以及`rateLimit`保護下游相依性免於請求爆量。
+ 在效能測試和啟動之前，檢查套用的帳戶和區域限制。端點組態無法建立超過帳戶限制的容量。
+ 重試沒有`lambda-web-error-type`標頭的 HTTP 429 回應和 HTTP 503 回應。使用退避和抖動，並只在操作為等冪時重試。使用等冪索引鍵或應用程式層級重複資料刪除進行寫入。

## 使用明確驗證和復原進行部署
<a name="web-functions-best-practices-deployment"></a>
+ 針對生產端點使用手動修訂權重。為可接受立即推展的開發環境保留自動最新修訂部署。
+ 等到新修訂完成`Active`，且端點更新完成，再進行評估。對於 `MultiRegion`和 `PerRegion`端點，驗證每個區域中的更新狀態。
+ 在 Canary 部署期間，使用包含修訂識別符的應用程式日誌或自訂指標。服務提供的指標不包含修訂維度。
+ 在轉移流量之前，請定義新修訂必須符合的指標，以及您觀察它們的時間長度 （喚醒條件），以及觸發轉返的閾值。保留先前修訂版的程式碼物件版本、金鑰存取和組態，直到復原視窗結束為止。當 Web 函數超過其修訂限制時，Lambda 會自動刪除沒有端點路由到的最舊修訂，因此請將復原修訂保留在端點 （例如測試端點） 上，或從相同的物件版本重新建立它。如需詳細資訊，請參閱[修訂限制和自動清除](web-functions-revisions.md#web-functions-revisions-limits)。

## 建置操作基準
<a name="web-functions-best-practices-observability"></a>
+ 發出具有請求 ID、修訂 ID、路由、狀態碼、持續時間和診斷下游故障所需識別符的結構化應用程式日誌。請勿記錄登入資料、字符或敏感請求內文。
+ 對 5xx 回應和調節發出警示，並監控已執行的請求、作用中的環境和帳戶容量。設定稀疏錯誤指標，以適當地處理遺失的資料。
+ 使用回應請求 ID 和日誌串流標頭，將用戶端失敗與日誌建立關聯。只有在您需要其他事件時，才啟用 DEBUG 系統日誌。
+ 當您的稽核需求需要時，在 中 AWS CloudTrail 記錄管理操作和端點叫用資料事件。

## 將 MultiRegion 和 PerRegion 端點操作為分散式系統
<a name="web-functions-best-practices-multi-region"></a>
+ 讓每個可接收流量的區域都能使用應用程式資料、秘密、金鑰和下游相依性。
+ 測試部分部署失敗和區域相依性失敗。在所有區域更新報告成功之前，請勿假設所有區域都執行相同的修訂。
+ 每次端點更新後，請檢查 中的`updateStatus`每個項目`regionalEndpoints`。複寫在某些區域中可能會在其他區域中成功時失敗。因此，可以部分套用更新。請先重試或轉返，再將部署視為完成。
+ 對於`PerRegion`端點，請獨立於 Web 函數部署測試外部 DNS 或前門容錯移轉。
+ 集中主區域中的操作檢視，但保留遙測延遲或中斷的復原路徑。