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

考慮無伺服器 。NET

概觀

無伺服器運算已成為建置和部署應用程式的熱門方法。這主要是因為無伺服器方法在建置現代架構時提供的可擴展性和靈活性。不過，在某些情況下，考慮無伺服器運算的成本影響非常重要。

Lambda 是一種無伺服器運算平台，可讓開發人員執行程式碼，而不需要專用伺服器。Lambda 對於 來說是特別有吸引力的選項。NET 開發人員希望降低基礎設施成本。使用 Lambda，。NET 開發人員可以開發和部署高度可擴展且具有潛在成本效益的應用程式。透過使用無伺服器方法，開發人員不再佈建伺服器來處理應用程式請求。反之，開發人員可以建立隨需執行的函數。這使得無伺服器方法比執行、管理和擴展虛擬機器更具可擴展性、可管理性，而且可能更具成本效益。因此，您只需支付應用程式使用的資源，而不必擔心資源未充分利用或伺服器維護成本。

開發人員可以使用現代跨平台 。NET 版本來建置快速、高效且符合成本效益的無伺服器應用程式。。NET 核心和較新版本是免費且開放原始碼的架構，較先前 更適合在無伺服器平台上執行。NET 架構版本。這可讓開發人員縮短開發時間並提高應用程式效能。現代 。NET 也支援各種程式設計語言，包括 C# 和 F#。因此，對於希望在雲端中建置現代架構的開發人員來說，這是一個吸引人的選項。

本節說明如何使用 Lambda 作為無伺服器選項來節省成本。您可以透過微調 Lambda 函數的執行設定檔、正確調整 Lambda 函數的記憶體配置大小、使用原生 AOT以及移至 Graviton 型函數，進一步最佳化成本。

成本影響

您可以降低成本的程度取決於幾個因素，包括無伺服器函數執行的次數，以及每個函數配置的記憶體量和持續時間。 AWS Lambda 提供免費層級，其中包括每月一百萬次免費請求和每月 400，000 GB 的運算時間。您可以大幅降低在這些免費層限制內或附近工作負載的每月成本。

使用負載平衡器搭配 Lambda 函數作為目標時，可能也會產生額外費用。這計算方式為負載平衡器為 Lambda 目標 處理的資料量。

成本最佳化建議

正確調整 Lambda 函數的大小

在以 . NET為基礎的 Lambda 函數中，正確調整大小是成本最佳化的必要做法。此程序涉及識別在效能與成本效益之間取得平衡的最佳記憶體組態，而不需要變更程式碼。

透過設定 Lambda 函數的記憶體，範圍從 128 MB 到 10，240 MB，您也可以調整調用期間可用的 vCPU 量。這可讓記憶體或CPU繫結應用程式在執行期間存取其他資源，進而減少調用期間和整體成本。

不過，識別 NET. 型 Lambda 函數的最佳組態可以是手動且耗時的程序，特別是在經常變更的情況下。AWS Lambda Power Tuning 工具可協助您透過分析一組記憶體組態與範例承載來識別適當的組態。

例如，增加以 NET. 為基礎的 Lambda 函數的記憶體可以改善總叫用時間並降低成本，而不會影響效能。函數的最佳記憶體組態可能會有所不同。 AWS Lambda Power Tuning 工具可協助識別每個函數最具成本效益的組態。

在下列範例圖表中，總叫用時間會隨著此 Lambda 函數的記憶體增加而改善。這會導致總執行成本降低，而不會影響函數的原始效能。對於此函數，函數的最佳記憶體組態為 512 MB，因為這是資源使用率對於每次調用的總成本最有效率的地方。這因函數而異，在 Lambda 函數上使用 工具可以識別它們是否受益於正確的大小。

我們建議您定期完成此練習，作為發行新更新時任何整合測試的一部分。如果不常更新，請定期執行此練習，以確保函數已調整且大小正確。識別 Lambda 函數的適當記憶體設定後，您可以將正確的大小調整新增至程序。 AWS Lambda Power Tuning 工具會產生程式設計輸出，可供 CI/CD 工作流程在新程式碼發行期間使用。這可讓您自動化記憶體組態。

您可以免費下載 AWS Lambda Power Tuning 工具。如需如何使用工具的指示，請參閱如何在 中執行狀態機器 GitHub。

Lambda 也支援原生 AOT，這可讓 .NET 應用程式預先編譯。這可以透過減少 .NET 函數的執行時間來協助降低成本。如需建立原生AOT函數的詳細資訊，請參閱 Lambda 文件中的具有原生AOT編譯的 。NET 函數。

避免閒置等待時間

Lambda 函數持續時間是用來計算帳單的一個維度。當函數程式碼發出封鎖呼叫時，您需支付等待接收回應的計費時間。當 Lambda 函數鏈結在一起，或函數擔任其他函數的協調器時，此等待時間可能會增加。如果您有批次操作或訂單交付系統等工作流程，這會增加管理開銷。此外，可能無法在最長 15 分鐘的 Lambda 逾時內完成所有工作流程邏輯和錯誤處理。

建議您重新架構解決方案以AWS Step Functions用作工作流程的協調器，而不是在函數程式碼中處理此邏輯。使用標準工作流程時，系統會針對工作流程中的每個狀態轉換向您收費，而不是工作流程的總持續時間。此外，您可以將重試、等待條件、錯誤工作流程和回呼的支援移至 狀態條件，以允許 Lambda 函數專注於業務邏輯。如需詳細資訊，請參閱 AWS 運算部落格中的最佳化 AWS Lambda 成本 – 第 2 部分。

移至 Graviton 型函數

採用新一代 Graviton2 處理器的 Lambda 函數現已正式推出。Graviton2 函數使用 ARM型處理器架構，旨在以 20% 的成本為各種無伺服器工作負載提供高達 19% 的更佳效能。Graviton2 處理器支援的函數具有更低的延遲和更好的效能，非常適合為任務關鍵型無伺服器應用程式提供動力。

遷移至以 Graviton 為基礎的 Lambda 函數對於 來說是符合成本效益的選項。NET希望最佳化其 Lambda 成本的開發人員。Graviton 型函數使用 ARM型處理器，而非傳統 x86 處理器。這可以大幅節省成本，而不會犧牲效能。

雖然移至 Graviton 型函數有幾個優點，但也有一些挑戰和考量事項建議您考慮。例如，基於 Graviton 的函數需要使用 Amazon Linux 2，這可能無法與所有 .NET 應用程式相容。此外，第三方程式庫或相依性可能有與 ARM型處理器不相容的相容性問題。

如果您正在執行 。NET 架構應用程式，並想要利用 Lambda 的無伺服器功能，您可以考慮使用適用於 NET的 Porting Assistant 將應用程式移植到現代 。NET這可協助您加速將舊版 .NET 應用程式遷移至現代 .NET，讓應用程式能夠在 Linux 上執行。

下列圖表比較 x86 和 ARM/Graviton2 架構結果，用於運算質數的函數。

函數正在使用單一執行緒。當記憶體設定為 1.8 GB 時，會報告這兩個架構的最短持續時間。除此之外，Lambda 函數可以存取超過 1 v 的 CPU，但在這種情況下，函數無法使用額外的電源。基於相同原因，記憶體高達 1.8 GB 的成本穩定。隨著記憶體增加，成本會增加，因為此工作負載沒有額外的效能優勢。Graviton2 處理器明確為這個運算密集的函數提供更好的效能並降低成本。

若要將函數設定為搭配 Graviton 使用 和 ARM型處理器，請執行下列動作：

其他資源