選擇無 AWS 伺服器服務

Step Functions 支援以一種狀態指派資料並將其用於後續狀態的變數，以及用於進階資料處理的 JSONata 轉換，包括日期格式和數學操作。這些功能可簡化跨狀態的資料共用，並減少中繼處理步驟的需求。對於大規模批次處理，分散式映射會平行執行來自 Amazon S3、Athena 或 JSON 資料集數百萬個項目的相同程序，而無需佈建運算基礎設施。

了解應用程式的操作模式是選取無伺服器服務時最重要的因素。不同的工作負載模式需要不同的服務組合。無伺服器資料處理大部分落在下列模式內：

每個模式使用不同的無伺服器服務組合。如需每個模式的詳細範例和建議的服務組合，請參閱選擇一節。

無伺服器運算服務在允許單一執行執行的時間以及處理並行的方式方面有很大的差異。與傳統伺服器不同，Lambda 事件函數不會持續執行。當某個事件觸發某個函數時，這稱為調用。Lambda 事件函數的持續時間限制為 15 分鐘，但平均而言，在所有 AWS 客戶之間，大多數調用會持續不到一秒。

Lambda 最好提供短期、事件驅動的調用，其支援長達 15 分鐘的執行持續時間，並且每次請求自動擴展到數千個並行調用。Lambda 服務只會在需要時執行函數的執行個體，並自動從每天零個請求擴展到每秒數千個請求。您只需支付實際使用的運算時間，因此程式碼未執行時無需付費。Lambda 的每毫秒計費可以降低短期工作負載的成本。

有許多類型的叫用事件可以觸發短期函數。一些範例包括來自 API Gateway 的 HTTP 請求、由 EventBridge 規則管理的排程、來自 IoT 裝置的訊息，或檔案已上傳至 Amazon S3 儲存貯體的通知。

具狀態的互動式工作階段，例如 AI 編碼沙盒、互動式筆記本和多租戶 CI 環境，需要跨使用者互動保留狀態的隔離環境。Lambda MicroVMs是與 Event Functions 不同的運算形式：它們使用以 Dockerfile 為基礎的程式設計模型、為每個工作階段配置一個環境 （不是每個請求），並根據基準加上爆量模型而不是每毫秒計費。MicroVMs 提供具有完整作業系統功能的 VM 層級隔離、快照型快速啟動、長達 8 小時的生命週期，以及暫停/繼續以降低閒置成本。

長時間執行或穩定狀態的程序，例如批次工作、持久性 WebSocket 連線，或需要超過 15 分鐘持續處理的 服務，Fargate 會更好地提供服務，而這些程序可以無限期地執行。如需 Fargate 和 Lambda 如何以不同方式擴展的詳細資訊，請參閱擴展模型和延遲索引標籤。Fargate 為超過 Lambda 逾時或運算限制的工作負載提供一致的資源配置。此外，Lambda 耐用函數可啟用多步驟、長時間執行的執行，這些執行會在多個調用中持續存在狀態。每個個別調用仍然遵守 15 分鐘的限制。耐用函數會自動檢查點進度，並在停止的地方繼續，因此工作流程總持續時間可以遠超過 15 分鐘，而不需要 Fargate 或外部協同運作。

同時考慮工作負載的平均和最長執行時間。偶爾超過 15 分鐘的 Lambda 函數無法預測地失敗，且需要架構重新設計。您的應用程式架構和 需要決定如何叫用 函數。例如，批次處理模式的需求與隨需資料處理不同。Fargate 適合主要處理批次資料處理的微服務。Lambda 更容易部署和維護以進行隨需處理。

無伺服器開發的其中一個主要優點是您只需為使用的資源付費。無伺服器技術是pay-as-you-go，這表示您可以隨著應用程式需求變更而擴展和縮減，而無需支付閒置容量。不過，不同的無 AWS 伺服器服務使用不同的定價模式，偏好不同的使用模式。

Pay-per-use(Lambda、Step Functions Express、EventBridge) 根據實際調用和持續時間收費，閒置時無需付費。對於 Lambda，會根據函數的請求數量以及程式碼執行所需的持續時間向您收費。程式碼未執行時無須付費。此模型適用於無法預測或尖峰的工作負載，其中流量可能降至零，以及適用於需求不確定的早期應用程式。

以容量為基礎的定價 (Fargate、Amazon Aurora Serverless、DynamoDB 佈建模式） 會收取預留運算或輸送量容量的費用。雖然這可能會在低流量期間產生成本，但它在持續、可預測的規模下更具成本效益，其中每個請求定價會超過同等預留容量。例如，DynamoDB 佈建模式可讓您視需要調整資料表的輸送量容量，這對於流量模式一致的工作負載來說更經濟。

混合定價 (DynamoDB 隨需 API Gateway) 提供每個請求定價，可線性擴展，無需預先承諾。這可提供成本可預測性，而無需預測容量，但與佈建的替代方案相比，輸送量可能會非常高。

在 MicroVMs 執行時，已設定基準資源的基準加爆量定價 (Lambda MicroVM) 費用，可在尖峰活動期間爆量至 4 倍基準。暫停MicroVMs 可降低成本，同時保留狀態。此模型適用於具有可變活動和閒置期間的互動式工作負載。

建立每日、每週和季節性週期的預期流量模式模型。具有高peak-to-average比率的工作負載有利於每次使用定價。穩定狀態工作負載可能受益於以容量為基礎的定價。您也可以使用組合：例如，搭配 DynamoDB 佈建模式的pay-per-use Lambda，以取得可預測的資料存取模式。

傳統 Web 應用程式架構會將路由、資料存取、連線集區和整合綁定到您部署和維護為單一單位的單一程式碼庫中。設定、設定和維護架構、執行時間環境和基礎設施會拖慢您交付功能和錯誤修正的速度。隨著應用程式成長和依賴更多外部系統，這種複雜性會增加新開發人員的漸進測試時間，使追蹤錯誤來源更具挑戰性，並延遲新功能的交付。

無伺服器服務存在於各種營運責任上，可降低或消除此額外負荷。您不會在一個套件中管理所有項目，而是編寫鬆散連線的服務，其中每個服務都以盡可能少的相依性執行一個動作。

最低管理：Lambda、API Gateway、DynamoDB、Amazon SQS、Amazon SNS、EventBridge 和 Step Functions 不需要伺服器佈建、修補或容量規劃。您不需要設定連線集區、設定執行時間環境或管理擴展基礎設施。您可以完全專注於撰寫或產生程式碼，以解決業務問題。

容器管理：Fargate 需要建置和維護容器映像、設定任務定義和管理部署管道。您不會管理基礎基礎設施，但擁有容器生命週期。此模型適合需要自訂執行時間的團隊，或擁有想要執行的現有容器化工作負載，而無需管理叢集的團隊。

基礎設施即程式碼複雜性： AWS Serverless Application Model 使用速記語法和本機測試將僅限伺服器的架構的 IaC 複雜性降至最低。 AWS Cloud Development Kit (AWS CDK) 以更陡峭的學習曲線和要維護的程式碼為複雜應用程式Terraform提供更多功能。

請考慮您團隊的現有技能、要管理的服務數量，以及您組織的營運標準。如果您的團隊花費更多時間維護基礎設施，而不是建置功能，則朝向頻譜的最小管理端移動可以釋放資源以進行更高價值的工作。

服務如何在負載下直接影響應用程式的回應能力。在無伺服器架構中，擴展會自動發生，但不同的服務使用影響延遲和輸送量的不同機制。

每個請求擴展 (Lambda) 會為每個並行請求建立新的執行環境。Lambda 會在執行環境中叫用您的函數，提供安全且隔離的執行期環境，以管理執行函數所需的程序和資源。這可提供近乎即時的流量尖峰回應，在幾秒鐘內從零擴展到數千個並行執行。

不過，每個請求擴展會引入冷啟動，這是在 Lambda 建立新的執行環境時發生的初始化延遲。冷啟動時間的最大貢獻是 Lambda 初始化函數所花費的時間，其中包括載入函數的程式碼、啟動執行時間，以及初始化函數程式碼。對於 Java、Python 和 .NET 工作負載，Lambda SnapStart 可以透過擷取初始化執行環境的快照並將其快取為低延遲存取，將啟動效能提升高達 10 倍，無需額外費用。對於其他執行時間，您可以支付額外費用來緩解佈建並行的冷啟動。

任務層級擴展 （遠） 根據 CPU 使用率、記憶體用量或請求計數等指標新增或移除容器執行個體。擴展會在幾秒鐘到幾分鐘內新增任務，並避免對現有任務處理的請求冷啟動。一旦任務執行，它會在整個生命週期內保持暖機，為處理的所有請求提供一致的延遲。

輸送量型擴展 (DynamoDB、Kinesis) 會根據需求調整讀取/寫入容量或碎片計數。DynamoDB 隨需模式會立即擴展，以適應工作負載的流量模式。佈建模式需要自動調整規模組態，但每個請求的成本較低，可提供可預測的輸送量。使用無伺服器架構和 DynamoDB，不需要連線集區即可快速連接和擴展資料庫。反之，您可以視需要調整資料表的輸送量容量。

對於嚴格的延遲要求 (P99 低於 100 毫秒），請仔細評估冷啟動行為。Lambda 搭配佈建並行或 SnapStart，或 Fargate 搭配預暖任務，可為 API 工作負載提供可預測的延遲。對於延遲較不重要的資料處理工作負載，標準 Lambda 擴展通常就足夠了。

無伺服器架構是由透過 事件通訊的多項服務組成。事件代表狀態變更或更新。例如，放置在購物車中的項目、上傳至儲存系統的檔案，或訂單已準備好運送。服務之間的原生整合深度會影響您建置的速度，以及您需要撰寫多少自訂程式碼。

深度原生整合：Lambda 將超過 200 種 AWS 服務整合為事件來源。有些服務可以直接觸發 Lambda 函數。例如，將映像新增至 Amazon S3 儲存貯體時，可觸發 Lambda 來調整其大小。有些服務無法直接叫用 Lambda，但您可以使用事件來源映射，這是從事件來源讀取並叫用 Lambda 函數的輪詢機制。您可以使用事件來源映射來處理串流或佇列中的項目：DynamoDB Streams、Amazon Kinesis、Amazon MQ、Amazon MSK、自我管理 Apache Kafka和 Amazon SQS。

事件路由彈性：EventBridge 提供具有篩選規則的內容型路由，允許單一事件匯流排根據事件內容將事件路由到不同的目標。Amazon SNS 提供以主題為基礎的廣發功能，可同時將訊息傳遞給多個訂閱者。Amazon SQS 提供point-to-point緩衝，讓消費者主動從佇列輪詢訊息。常見的組合包括將 EventBridge 或 Amazon SNS 事件路由到 Amazon SQS 佇列，做為下游消費者的緩衝區、使用 EventBridge 管道從串流或佇列提取事件，以及將事件路由到 Kinesis 進行分析。

API 整合模式：API Gateway 提供兩種整合方法。Proxy 整合會將所有請求資訊直接傳遞至 Lambda 函數進行處理，這更容易設定。非代理 （自訂） 整合可以在資料到達您的函數之前轉換資料，並在輸出傳回用戶端之前轉換資料，這對於舊版程式碼遷移或將函數程式碼專注於商業邏輯非常有用。REST API 提供最廣泛的功能集，包括快取、請求驗證和 WAF。HTTP API 提供最低的延遲和成本。 AWS AppSync 提供即時訂閱和 GraphQL。Lambda URLs 提供最簡單的單一函數 HTTPS 端點，而不需要 API Gateway。對於伺服器需要將資料推送至用戶端的雙向通訊，API Gateway WebSocket APIs提供適用於聊天、即時儀表板和多玩家遊戲的持久性連線。

由於事件驅動系統元件之間的鬆散耦合，您的運算函數不知道架構中的其他活動。您可以獨立擴展元件，一個服務可能會失敗，而不會影響其他服務，並且事件可以靈活路由、緩衝並提供日誌以供稽核。

您選擇的無伺服器服務會影響您的架構跨環境的可攜式程度。無伺服器應用程式通常包含數個 AWS 服務，與 Lambda 函數中執行的自訂程式碼整合。雖然 Lambda 可以與大多數 AWS 服務整合，但您應該考慮深度平台整合與在其他環境中執行工作負載的能力之間的權衡。

AWS 原生服務 (Lambda、Step Functions、EventBridge、DynamoDB) 提供最深入的整合和最低的操作開銷。您可以透過 AWS SDK 使用任何這些服務，而不需要安裝應用程式或設定伺服器。熟悉透過 Lambda 函數中的程式碼使用這些服務，是生產設計良好的無伺服器應用程式的重要步驟。不過，這些服務會建立與 AWS特定 APIs和事件格式的耦合，這表示遷移到另一個雲端需要大量的重構。

標準型服務 （以Docker容器為目標、使用 Amazon MQAMQP、使用 Amazon MSKApache Kafka) 在開放式通訊協定或開放原始碼技術上執行。如果您需要 未提供的自訂執行期 AWS，您可以在 Fargate 上建立和部署自訂容器映像。Amazon MSK 為具有現有 Kafka 專業知識的團隊提供Apache Kafka相容性。這些選項讓工作負載可攜性更可行，而成本較高，營運複雜性高，且與其他 AWS 服務的整合較不緊密。

部署架構： AWS Serverless Application Model 和 AWS Cloud Development Kit (AWS CDK) 會產生 CloudFormation 範本和 be AWS-only. AWS Serverless Application Model extends CloudFormation ，其速記語法著重於加速無伺服器開發、提供 API Gateway、Lambda 和 Step Functions 資源的最佳化定義，以及透過 SAM CLI 進行本機 Lambda 測試。 使用跨提供者的單一工作流程，但具有較少的無伺服器特定工具，以及有限的本機 Lambda 測試功能，Terraform來提供多雲端基礎設施定義。

容器和標準型傳訊可以改善多雲端需求的可攜性。原生無伺服器服務提供與其他 AWS 服務的緊密整合，可在工作負載主要執行時簡化開發 AWS。

您需要處理來自 Web 或行動用戶端的 HTTP 請求、處理它們，以及以低延遲傳回回應。

對於 Web APIs和行動後端，API Gateway 會將 HTTP 請求路由到 Lambda 函數。DynamoDB 會處理低延遲的資料存取。HTTP API 以較低的成本提供簡單的路由，而 REST API 新增快取、請求驗證和 WAF 整合。您可以使用 Amazon Cognito 處理身分驗證，也可以使用速記語法 AWS Serverless Application Model 定義這些資源。

若要實作同步處理，請使用 AWS Lambda 進行運算，並使用 Amazon API Gateway 進行路由請求。使用 AWS Step Functions 來協調微服務工作流程。使用 DynamoDB 和 Amazon S3 存放資料和檔案，並使用 Amazon Cognito 驗證使用者。

例如，假設您想要建置微服務應用程式，依郵遞區號查詢天氣資料。用戶端會透過 Amazon Route 53 解析主機名稱。HTTP GET 請求會路由至 API Gateway，透過 Amazon Cognito 驗證存取字符，然後將請求傳送至 Lambda 函數。函數會查詢 DynamoDB、自訂資料、將事件傳送至 Amazon SQS 進行分析，以及將事件傳送至 Amazon SNS 以取得提醒。流量變慢後，Lambda 會縮減執行環境。您只需支付實際函數用量的費用。

您需要處理不需要立即回應的事件，具有可靠的交付和吸收流量尖峰的能力。

對於在沒有立即回應的情況下處理事件的工作負載，Amazon SQS 會處理緩衝和負載平衡。Amazon SNS 可以平行向多個訂閱者分發單一事件。EventBridge 會依內容篩選事件，並與 SaaS 應用程式整合。Step Functions 會與 DynamoDB 或 Amazon S3 協調多步驟處理，以儲存結果。

若要實作非同步處理，請使用 AWS Lambda 進行運算，並使用 AWS Step Functions 進行協同運作。使用適用於廣發功能的 Amazon Simple Notification Service 和用於耐用佇列的 Amazon Simple Queue Service 路由訊息。將結果儲存在 DynamoDB 和 Amazon S3 中。

例如，當使用者上傳相片到 Amazon S3 時，Amazon S3 會發佈事件，呼叫 Lambda 函數來產生縮圖。如果您還需要分類映像並通知使用者，請使用 Amazon SNS 將單一上傳事件發散到多個平行處理的 Lambda 函數。

您需要使用分支邏輯、錯誤處理、重試和人工核准步驟來協調一系列任務。

標準工作流程會處理執行時間長達 1 年的程序，且執行時間與完整稽核歷史記錄完全相同。對於大量、短期處理 （最多 5 分鐘），快速工作流程會在每次執行時以較低的成本運作。

當您的工作流程具有多個狀態、需要分支或平行執行任務時，Step Functions 非常有用。Step Functions 服務可做為您應用程式的狀態模型。標準工作流程提供一次恰好完整的可稽核執行歷史記錄，使其非常適合訂單處理、人工核准工作流程和 ETL 管道。Express Workflows at-least-once以較高數量和較低成本執行，使其非常適合 IoT 資料擷取、串流轉換和高速率事件處理。

您需要近乎即時地擷取、處理和分析高速連續資料。Lambda 和 Amazon Kinesis 可以處理即時串流資料。使用案例包括活動追蹤、點選串流分析、日誌篩選、IoT 遙測和計量。

對於原生 AWS 整合，Kinesis Data Streams 會處理串流擷取。Amazon MSK 可以擷取具有Apache Kafka相容性的串流。Lambda 或 Fargate 會使用 DynamoDB 或 Amazon S3 處理串流資料，以儲存結果。

若要實作無伺服器串流，請使用 AWS Lambda 進行運算，並使用 Amazon Kinesis 收集和分析即時資料。使用 DynamoDB 和 Amazon S3 儲存結果。

例如，當項目寫入 DynamoDB 資料表時，DynamoDB Streams 會發佈叫用 Lambda 函數以產生即時分析的事件。對於數百萬台裝置的 IoT 遙測等較高容量擷取，請使用 Kinesis Data Streams 在處理之前收集和緩衝資料。

您需要的處理時間超過 Lambda 的 15 分鐘限制、需要持續連線，或是自訂容器執行時間的好處。

對於超過 15 分鐘但包含離散步驟的工作流程，Lambda 耐久函數檢查點進度和跨調用恢復。Step Functions 分散式映射可以平行處理來自 Amazon S3、Athena 或 JSON 的數百萬個項目，而無需佈建運算。Fargate 支援持續處理、持久性連線和精細 CPU/記憶體控制。

例如，處理 1，000 萬個 Amazon S3 物件的夜間資料管道會使用 Step Functions Distributed Map 來平行處理工作。處理檔案超過 30 分鐘的影片轉碼服務會使用 Fargate。跨天數的多步驟貸款核准工作流程使用 Lambda 耐久函數在人工審核步驟之間持續存在狀態。

您需要在具有強大租用戶分離和狀態保留的隔離環境中執行使用者提供或 AI 產生的程式碼。

Lambda MicroVMs提供由 Firecracker 提供支援的 VM 層級隔離，具有完整的作業系統功能、以快照為基礎的快速啟動，以及長達 8 小時的生命週期。每個 MicroVM 都會取得支援 HTTP/2、gRPC 和 WebSocket 通訊協定的專用 HTTPS URL。閒置時可暫停 MicroVMs以降低成本，同時保留記憶體和磁碟狀態。與 Event Functions 不同，MicroVMs使用以 Dockerfile 為基礎的程式設計模型，每個工作階段配置一個環境，並根據基準加上爆量模型計費 （尖峰活動期間高達 4 倍基準）。每個 MicroVM 都支援可設定的輸出聯網，用於 VPC 存取和公有網際網路連線，而不需要負載平衡器或輸入基礎設施。

例如，AI 編碼助理會為每個使用者工作階段提供自己的 MicroVM，以安全地執行產生的程式碼。互動式筆記本平台會在互動之間持續存在狀態的隔離 MicroVM 中，執行每個學生的程式碼。

AWS Lambda

AWS Fargate

Lambda MicroVMs

Amazon API Gateway REST API

Amazon API Gateway HTTP API

AWS AppSync

Lambda 函數 URL

Amazon Simple Queue Service

Amazon Simple Notification Service

Amazon EventBridge

AWS Step Functions

Amazon DynamoDB

Amazon Simple Storage Service

Amazon Aurora Serverless

AWS Serverless Application Model

AWS Cloud Development Kit (AWS CDK)

Terraform

Amazon CloudWatch

AWS X-Ray