Google Cloud 提供工具、產品、指南和專業服務，協助您將無伺服器工作負載從 Amazon Web Services (AWS) Lambda 遷移至 Google Cloud。雖然 Google Cloud 提供多項服務，可用於開發及部署無伺服器應用程式，但本文著重於遷移至Cloud Run，這是一種無伺服器執行階段環境。AWS Lambda 和 Cloud Run 有許多相似之處，例如自動佈建資源、由雲端服務供應商調整資源配置，以及按用量計費模式。
本文可協助您設計、實作及驗證計畫，將無伺服器工作負載從 AWS Lambda 遷移至 Cloud Run。此外，本指南也提供指引，協助評估這類遷移作業的潛在效益和程序。
本文件是從 AWS 遷移至Google Cloud 系列文章的一部分，該系列包含下列文件：
- 開始使用
- 從 Amazon EC2 遷移至 Compute Engine
- 從 Amazon S3 遷移至 Cloud Storage
- 從 Amazon EKS 遷移至 Google Kubernetes Engine
- 從 Amazon RDS 和 Amazon Aurora for MySQL 遷移至 MySQL 適用的 Cloud SQL
- 從 Amazon RDS 和 Amazon Aurora for PostgreSQL 遷移至 PostgreSQL 適用的 Cloud SQL 和 AlloyDB for PostgreSQL
- 從 Amazon RDS for SQL Server 遷移至 SQL Server 適用的 Cloud SQL
- 從 AWS Lambda 遷移至 Cloud Run (本文件)
如要進一步瞭解如何為商業邏輯選擇合適的無伺服器執行階段環境，請參閱「選取代管容器執行階段環境」。如要查看 AWS 和 Google Cloud 服務之間的完整對應關係，請參閱「比較 AWS 和 Azure 服務與 Google Cloud 服務」。
如要遷移至 Google Cloud，建議您按照「遷移至 Google Cloud：開始使用」一文所述的遷移架構操作。
以下是遷移流程圖。
您可能會分批從來源環境遷移至 Google Cloud ，例如先遷移部分工作負載，再遷移其他工作負載。針對每個獨立的遷移疊代，您必須遵循一般遷移架構的階段：
- 評估並探索工作負載和資料。
- 在 Google Cloud上規劃及建構基礎。
- 將工作負載和資料遷移至 Google Cloud。
- 將 Google Cloud 環境調整至最佳狀態。
如要進一步瞭解這個架構的各個階段，請參閱「遷移至 Google Cloud：開始使用」。
為設計有效的遷移計畫，建議您驗證計畫的每個步驟，並確保有復原策略。如要驗證遷移計畫，請參閱「遷移至 Google Cloud：驗證遷移計畫的最佳做法」。
遷移無伺服器工作負載時，通常不只是將函式從某個雲端服務供應商移至另一個，雲端式應用程式仰賴相互連結的服務網路，因此從 AWS 遷移至 Google Cloud 時，可能需要將依附的 AWS 服務替換為 Google Cloud 服務。舉例來說，假設 Lambda 函式與 Amazon SQS 和 Amazon SNS 互動。如要遷移這項函式，您可能需要採用 Pub/Sub 和 Cloud Tasks，才能達到類似功能。
遷移作業也是您全面審查無伺服器應用程式架構和設計決策的絕佳機會。透過這項審查，您可能會發現有機會執行下列操作：
- 運用 Google Cloud 內建功能進行最佳化：瞭解Google Cloud 服務是否提供獨特優勢，或更符合應用程式需求。
- 簡化架構：評估是否能透過整合功能或以不同方式使用Google Cloud服務，簡化架構。
- 提高成本效益：評估在 Google Cloud提供的基礎架構上，執行重構應用程式的潛在成本差異。
- 提升程式碼效率：在遷移過程中重構程式碼。
策略性規劃遷移作業。請勿將遷移作業視為重新託管 (lift-and-shift) 練習。您可以趁著遷移作業，提升無伺服器應用程式的整體設計和程式碼品質。
評估來源環境
在評估階段，您需要判斷將來源環境遷移至 Google Cloud的需求和依附元件。
評估階段是您能否成功遷移的關鍵。您必須深入瞭解要遷移的工作負載、其需求、依附元件，以及目前的環境。您必須瞭解起點，才能成功規劃及執行 Google Cloud遷移作業。
評估階段包含下列工作：
- 建立工作負載的完整清單。
- 根據工作負載的屬性和依附元件，將工作負載分類。
- 訓練及教育團隊 Google Cloud。
- 在 Google Cloud上建構實驗和概念驗證。
- 計算目標環境的總持有成本 (TCO)。
- 選擇工作負載的遷移策略。
- 選擇遷移工具。
- 定義遷移計畫和時程。
- 驗證遷移計畫。
如要進一步瞭解評估階段和這些工作，請參閱「遷移至 Google Cloud：評估及探索工作負載」。以下各節內容是根據該文件中的資訊撰寫而成。
建立 AWS Lambda 工作負載清單
如要定義遷移範圍，請建立清單並收集 AWS Lambda 工作負載的相關資訊。
如要建立 AWS Lambda 工作負載的清單，建議您採取下列做法：
- 如要探索 AWS Lambda 資產，請使用 Migration Center。Migration Center 是Google Cloud的整合式平台，可協助您加快從目前環境遷移至 Google Cloud的端對端雲端旅程。
如要精確列出 AWS Lambda 工作負載，請使用 AWS 命令列介面 (CLI)。例如，您可以使用 AWS CLI 取得 AWS Lambda 函式清單。接著，針對每個函式，取得其設定詳細資料和觸發條件。
如要查看最近的 AWS Lambda 叫用記錄和時間長度、並行執行和錯誤，請使用 CloudWatch。CloudWatch 提供多種 AWS Lambda 指標。如要進一步瞭解如何查看 AWS Lambda 指標，請參閱「查看 AWS Lambda 函式的指標」。
如要評估 AWS Lambda 工作負載清單，請使用 Gemini CLI。舉例來說，您可以將列出 AWS Lambda 工作負載的清查檔案新增至 Gemini CLI 內容，然後提示 Gemini 協助評估這些物件。詳情請參閱「運用 Gemini 遷移至 Google Cloud」。
建立清單後，建議您收集清單中各項 AWS Lambda 工作負載的資訊。針對每項工作負載，請著重於有助於預測潛在阻礙的層面。此外，請分析該工作負載，瞭解在遷移至 Cloud Run 之前，可能需要如何修改工作負載及其依附元件。建議您先收集各項 AWS Lambda 工作負載下列方面的資料：
- 應用實例和設計
- 原始碼存放區
- 部署構件
- 叫用、觸發條件和輸出內容
- 執行階段和執行環境
- 工作負載設定
- 存取控管與權限
- 法規遵循與監管要求
- 部署和作業程序
用途和設計
收集工作負載的用途和設計相關資訊，有助於找出合適的遷移策略。這項資訊也有助於您瞭解是否需要在遷移前修改工作負載及其依附元件。建議您為每項工作負載執行下列操作：
- 深入瞭解工作負載服務的特定用途，並找出與其他系統、資源或程序的任何依附關係。
- 分析工作負載的設計和架構。
- 評估工作負載的延遲時間需求。
原始碼存放區
如果需要重構 AWS Lambda 工作負載，確保與 Cloud Run 相容，則可盤點 AWS Lambda 函式的原始碼。建立這份清單時，必須追蹤程式碼集，這類程式碼集通常儲存在 Git 等版本管控系統，或 GitHub 或 GitLab 等開發平台。原始碼清單對 DevOps 程序 (例如持續整合和持續開發 (CI/CD) 管道) 至關重要，因為遷移至 Cloud Run 時，也需要更新這些程序。
部署構件
瞭解工作負載需要哪些部署構件，也有助於判斷是否需要重構 AWS Lambda 工作負載。如要找出工作負載所需的部署構件，請收集下列資訊：
- 用於部署工作負載的部署套件類型。
- 任何包含額外程式碼 (例如程式庫和其他依附元件) 的 AWS Lambda 層。
- 工作負載依賴的任何 AWS Lambda 擴充功能。
- 您設定用來指定版本和別名的限定詞。
- 已部署的工作負載版本。
叫用、觸發條件和輸出
AWS Lambda 支援多種叫用機制 (例如觸發條件) 和叫用模型 (例如同步叫用和非同步叫用)。針對每個 AWS Lambda 工作負載，建議您收集下列與觸發條件和叫用相關的資訊：
- 叫用工作負載的觸發條件和事件來源對應。
- 工作負載是否支援同步和非同步叫用。
- 工作負載網址和 HTTP(S) 端點。
AWS Lambda 工作負載可與其他資源和系統互動。您需要瞭解哪些資源會耗用 AWS Lambda 工作負載的輸出內容，以及這些資源如何耗用這些輸出內容。這項資訊有助於判斷是否需要修改可能依賴這些輸出的任何項目，例如其他系統或工作負載。針對每個 AWS Lambda 工作負載，建議您收集下列其他資源和系統的相關資訊：
- 工作負載可能傳送事件的目的地資源。
- 接收非同步叫用資訊記錄的目的地。
- 工作負載處理的事件格式。
- AWS Lambda 工作負載及其擴充功能與 AWS Lambda API 或其他 AWS API 互動的方式。
為確保正常運作，AWS Lambda 工作負載可能會儲存永久資料，並與其他 AWS 服務互動。針對每個 AWS Lambda 工作負載，建議您收集下列資料和其他服務的相關資訊：
- 工作負載是否存取虛擬私有雲 (VPC) 或其他私人網路。
- 工作負載如何儲存永久資料，例如使用臨時資料儲存空間和 Amazon Elastic File System (EFS)。
執行階段和執行環境
AWS Lambda 支援多種工作負載執行環境。如要將 AWS Lambda 執行環境正確對應至 Cloud Run 執行環境，建議您針對每個 AWS Lambda 工作負載評估下列項目：
- 工作負載的執行環境。
- 執行工作負載的電腦處理器指令集架構。
如果 AWS Lambda 工作負載是在特定語言的執行階段環境中執行，請針對每個 AWS Lambda 工作負載考量下列事項：
- 特定語言執行階段環境的類型、版本和專屬 ID。
- 您對執行階段環境所做的任何修改。
工作負載設定
如要設定從 AWS Lambda 遷移至 Cloud Run 的工作負載，建議您評估各個 AWS Lambda 工作負載的設定方式。
針對每個 AWS Lambda 工作負載，收集下列並行和擴充性設定的相關資訊：
- 並行控制項。
- 擴充性設定。
- 工作負載執行個體的設定，包括可用記憶體量和允許的執行時間上限。
- 工作負載是否使用 AWS Lambda SnapStart、預留並行或佈建並行來縮短延遲時間。
- 您設定的環境變數，以及 AWS Lambda 設定和工作負載依賴的環境變數。
- 標記和屬性式存取控管。
- 用於處理例外狀況的狀態機器。
- 使用容器映像檔的部署套件基本映像檔和設定檔 (例如 Dockerfile)。
存取控管與權限
建議您在評估過程中，評估 AWS Lambda 工作負載的安全需求，以及存取控管和管理方面的設定。如果您需要在 Google Cloud 環境中實作類似的控制項，這項資訊就非常重要。針對每個工作負載，請考量下列事項：
- 執行角色和權限。
- 工作負載及其層級用於存取其他資源的身分與存取權管理設定。
- 其他帳戶和服務用來存取工作負載的身分與存取權管理設定。
- 管理控制項。
法規遵循與監管要求
請務必瞭解每個 AWS Lambda 工作負載的法規遵循和監管要求，方法如下：
- 評估工作負載必須符合的法規遵循和監管要求。
- 判斷工作負載是否符合這些要求。
- 判斷日後是否需要滿足任何需求。
法規遵循和監管要求可能與您使用的雲端服務供應商無關，而且這些要求也可能對遷移作業造成影響。舉例來說，您可能需要確保資料和網路流量不超出特定地理區域 (例如歐盟) 的範圍。
評估部署和作業流程
請務必清楚瞭解部署和作業流程的運作方式。這些程序是準備及維護正式環境和其中執行的工作負載時，不可或缺的基本做法。
部署和作業程序可能會建構工作負載運作所需的構件。因此，您應該收集每種構件類型的資訊。例如，構件可以是作業系統套件、應用程式部署套件、作業系統映像檔、容器映像檔或其他項目。
除了構件類型外，請思考如何完成下列工作：
- 開發工作負載。評估開發團隊建構工作負載的流程。例如，開發團隊如何設計、編寫及測試工作負載？
- 產生要在來源環境中部署的構件。如要在來源環境中部署工作負載，您可能會產生可部署的構件 (例如容器映像檔或作業系統映像檔)，也可能會自訂現有構件 (例如透過安裝及設定軟體來自訂第三方作業系統映像檔)。收集這些構件的生成方式資訊，有助於確保生成的構件適合部署在Google Cloud中。
儲存構件。如果您在來源環境中產生並儲存構件，則必須在 Google Cloud 環境中提供這些構件。您可以採用下列策略：
- 在環境之間建立通訊管道：讓目標Google Cloud 環境可以存取來源環境中的構件。
- 重構構件建構程序：對來源環境進行小幅重構，以便在來源環境和目標環境中儲存構件。這種做法可讓您在目標 Google Cloud環境中實作構件建構程序之前，先建構構件存放區等基礎架構，進而支援遷移作業。您可以直接採用這種方法，也可以先建立通訊管道，再採用這種方法。
在來源和目標環境中提供構件，可讓您專注於遷移作業，而不必在目標 Google Cloud 環境中實作構件建構程序，做為遷移作業的一部分。
掃描及簽署程式碼。在建構構件的過程中，您可能會使用程式碼掃描功能，防範常見的安全漏洞和意外的網路暴露，並使用程式碼簽署功能，確保只有受信任的程式碼會在環境中執行。
在來源環境中部署構件。生成可部署的構件後，您可能會在來源環境中部署這些構件。建議您評估各項部署程序。這項評估有助於確保部署程序與 Google Cloud相容。此外，您也能瞭解最終重構程序所需的工作。舉例來說，如果部署程序僅適用於來源環境，您可能需要重構這些程序，以指定 Google Cloud 環境。
插入執行階段設定。您可能正在為特定叢集、執行階段環境或工作負載部署作業，插入執行階段設定。設定可能會初始化環境變數和其他設定值，例如 Secret、憑證和金鑰。為確保執行階段設定插入程序能在 Google Cloud上運作，建議您評估來源環境中執行的工作負載設定方式。
記錄、監控和剖析。評估現有的記錄、監控和分析程序，監控來源環境的健康狀態、相關指標，以及如何使用這些程序提供的資料。
驗證。評估您對來源環境的驗證方式。
佈建及設定資源。為了準備來源環境，您可能已設計並實作佈建及設定資源的程序。舉例來說，您可能會使用 Terraform 搭配設定管理工具，在來源環境中佈建及設定資源。如果您使用 Terraform，可以根據偏好的起點，使用下列工具在 Google Cloud 上建構基礎和登陸區：
- Google Cloud Terraform Provider 中的資源：使用基本建構模塊從頭開始。
- Google Cloud的 Terraform 藍圖和模組： 從基準 Terraform 模組開始。這種方法是以 Google Cloud Terraform 供應商中的資源為基礎。
- 企業基礎藍圖：從預先設定的基礎和登陸區開始。這個方法是以 Google Cloud的 Terraform 藍圖和模組為基礎。
- Cloud Foundation Fabric：從預先設定的基礎和登陸區開始。Cloud Foundation Fabric 是獨立實作項目，使用自己的 Terraform 模組。這個方法是以 Google Cloud Terraform 供應商中的資源為基礎。
完成評估
從 AWS Lambda 環境建立清查項目後，請按照「遷移至 Google Cloud：評估及探索工作負載」一文所述，完成評估階段的其他活動。
規劃及奠定基礎
在規劃和建構階段，您需要佈建及設定基礎架構，以執行下列操作：
- 支援 Google Cloud 環境中的工作負載。
- 連結來源環境和 Google Cloud 環境，完成遷移作業。
規劃和建構階段包含下列工作：
- 建立資源階層。
- 設定 Google Cloud的身分與存取權管理 (IAM)。
- 設定帳單資訊。
- 設定網路連線。
- 強化安全性。
- 設定記錄、監控和警告功能。
如要進一步瞭解各項工作，請參閱「遷移至 Google Cloud：規劃及建構基礎」。
遷移 AWS Lambda 工作負載
如要將工作負載從 AWS Lambda 遷移至 Cloud Run，請按照下列步驟操作：
- 設計、佈建及設定 Cloud Run 環境。
- 如有需要，請重構 AWS Lambda 工作負載，使其與 Cloud Run 相容。
- 重構部署和作業程序，以便在 Cloud Run 部署及觀測工作負載。
- 遷移 AWS Lambda 工作負載所需的資料。
- 驗證遷移結果的功能、效能和成本。
為避免在遷移期間發生問題，並預估遷移所需的工作量，建議您評估 AWS Lambda 功能與類似 Cloud Run 功能的差異。AWS Lambda 和 Cloud Run 的功能可能看起來很相似。不過，這兩家雲端服務供應商在功能設計和實作方面的差異，可能會對從 AWS Lambda 遷移至 Cloud Run 的作業產生重大影響。這些差異可能會影響您的設計和重構決策，詳情請參閱以下各節。
設計、佈建及設定 Cloud Run 環境
遷移階段的第一步是設計 Cloud Run 環境，以便支援從 AWS Lambda 遷移的工作負載。
為了正確設計 Cloud Run 環境，請使用您在評估階段收集的各項 AWS Lambda 工作負載資料。這些資料有助於：
- 選擇合適的 Cloud Run 資源來部署工作負載。
- 設計 Cloud Run 資源設定。
- 佈建及設定 Cloud Run 資源。
選擇合適的 Cloud Run 資源
針對要遷移的每個 AWS Lambda 工作負載，選擇合適的 Cloud Run 資源來部署工作負載。Cloud Run 支援下列主要資源：
- Cloud Run 服務：託管容器化執行階段環境、公開不重複端點，並根據需求自動調度基礎架構資源的資源。
- Cloud Run 工作：執行一或多個容器直到完成的資源。
下表摘要說明 AWS Lambda 資源如何對應至這些主要 Cloud Run 資源：
| AWS Lambda 資源 | Cloud Run 資源 |
|---|---|
| 由事件觸發的 AWS Lambda 函式，例如用於網站和網頁應用程式、API 和微服務、串流資料處理和事件導向架構的函式。 | 可透過觸發條件叫用的 Cloud Run 服務。 |
| 排定執行的 AWS Lambda 函式，例如背景工作和批次工作。 | 執行至完成的 Cloud Run 工作。 |
除了服務和工作，Cloud Run 還提供其他資源，可擴充這些主要資源。如要進一步瞭解所有可用的 Cloud Run 資源，請參閱「Cloud Run 資源模型」。
設計 Cloud Run 資源設定
在佈建及設定 Cloud Run 資源之前，請先設計其設定。某些 AWS Lambda 設定選項 (例如資源限制和要求逾時) 與類似的 Cloud Run 設定選項相當。以下各節說明 Cloud Run 提供的設定選項，包括服務觸發條件和工作執行、資源設定，以及安全性。這些章節也會重點介紹與 Cloud Run 類似的 AWS Lambda 設定選項。
Cloud Run 服務觸發條件和工作執行
遷移 AWS Lambda 工作負載時，您需要考量的主要設計決策是服務觸發條件和工作執行。Cloud Run 提供多種選項，可觸發及執行 AWS Lambda 中使用的事件導向工作負載。此外，Cloud Run 也提供多種選項，可用於串流工作負載和排定的工作。
遷移工作負載時，建議先瞭解 Cloud Run 提供哪些觸發條件和機制。這項資訊有助於您瞭解 Cloud Run 的運作方式。接著，您可以使用這項知識，判斷哪些 Cloud Run 功能與 AWS Lambda 功能相當，以及在重構這些工作負載時，可以使用哪些 Cloud Run 功能。
如要進一步瞭解 Cloud Run 提供的服務觸發條件，請參考下列資源：
- HTTPS 叫用：傳送 HTTPS 要求，觸發 Cloud Run 服務。
- HTTP/2 叫用：傳送 HTTP/2 要求來觸發 Cloud Run 服務。
- WebSockets：將用戶端連線至在 Cloud Run 上執行的 WebSockets 伺服器。
- gRPC 連線：使用 gRPC 連線至 Cloud Run 服務。
- 非同步叫用：使用 Cloud Tasks 將工作排入佇列，由 Cloud Run 服務非同步處理。
- 排定叫用：使用 Cloud Scheduler 依排程叫用 Cloud Run 服務。
- 事件型叫用：建立 Eventarc 觸發條件，以 CloudEvents 格式叫用特定事件的 Cloud Run 服務。
- 與 Pub/Sub 整合：透過 Pub/Sub 推送訂閱項目叫用 Cloud Run 服務。
- 與 Workflows 整合：從工作流程叫用 Cloud Run 服務。
如要進一步瞭解 Cloud Run 提供的任務執行機制，請參考下列資源：
- 隨選執行：建立工作執行作業，直到完成。
- 排定的執行作業：依排程執行 Cloud Run 工作。
- 與 Workflows 整合：從工作流程執行 Cloud Run 工作。
請參閱下表，瞭解哪些 Cloud Run 叫用或執行機制與 AWS Lambda 叫用機制相當。針對需要佈建的每項 Cloud Run 資源，請務必選擇合適的叫用或執行機制。
| AWS Lambda 功能 | Cloud Run 功能 |
|---|---|
| HTTPS 觸發條件 (函式網址) | HTTPS 叫用 |
| HTTP/2 觸發條件 (部分支援，需使用外部 API 閘道) | HTTP/2 叫用 (原生支援) |
| WebSockets (透過外部 API Gateway 支援) | WebSockets (原生支援) |
| 不適用 (不支援 gRPC 連線) | gRPC 連線 |
| 非同步叫用 | Cloud Tasks 整合 |
| 排定叫用 | Cloud Scheduler 整合 |
| 專屬事件格式的事件型觸發條件 | 以 CloudEvents 格式叫用事件 |
| Amazon SQS 和 Amazon SNS 整合 | Pub/Sub 整合 |
| AWS Lambda Step Functions | Workflows 整合 |
Cloud Run 資源設定
為補充您在觸發及執行遷移工作負載時所做的設計決策，Cloud Run 支援多種設定選項，可讓您微調執行階段環境的多個方面。這些設定選項包含資源服務和工作。
如前所述，您可以先瞭解 Cloud Run 提供的所有設定選項，進一步瞭解 Cloud Run 的運作方式。接著，您就能比較 AWS Lambda 和 Cloud Run 的類似功能，並決定如何重構工作負載。
如要進一步瞭解 Cloud Run 服務提供的設定，請參考下列資源：
- 容量：記憶體限制、CPU 限制、CPU 分配、要求逾時、每個執行個體的並行要求數量上限、執行個體數量下限、執行個體數量上限和 GPU 設定
- 環境： 容器通訊埠和進入點、 環境變數、 Cloud Storage 磁碟區掛接、 記憶體內磁碟區掛接、 執行環境、 容器健康狀態檢查、 密鑰和 服務帳戶
- 自動調度資源
- 處理例外狀況：Pub/Sub 失敗處理和 Eventarc 失敗處理
- 中繼資料： 說明、標籤和標記
- 流量提供：自訂網域對應、自動指派的網址、Cloud CDN 整合和工作階段相依性
如要進一步瞭解 Cloud Run 提供的任務，請參考下列資源：
- 容量：記憶體限制、CPU 限制、平行處理和工作逾時
- 環境： 容器進入點、 環境變數、 Cloud Storage 磁碟區掛接、 記憶體內磁碟區掛接、 Secret 和 服務帳戶
- 處理例外狀況：重試次數上限
- 中繼資料：標籤和標記
請參閱下表，瞭解哪些 Cloud Run 設定選項與 AWS Lambda 設定選項相當。針對需要佈建的各項 Cloud Run 資源，請務必選擇正確的設定選項。
| AWS Lambda 功能 | Cloud Run 功能 |
|---|---|
| 佈建並行 | 執行個體數量下限 |
| 每個執行個體的預留並行數 (並行集區由 AWS 帳戶中的 AWS Lambda 函式共用。) |
每項服務的執行個體數量上限 |
| 不適用 (不支援，一項要求對應一個執行個體) | 每個執行個體的並行要求數 |
| 不適用 (視記憶體配置而定) | CPU 分配方式 |
| 擴充性設定 | 服務的執行個體自動調度資源 工作的平行處理 |
| 執行個體設定 (CPU、記憶體) | CPU 和記憶體限制 |
| 執行時間上限 | 服務要求逾時 工作任務逾時 |
| AWS Lambda SnapStart | 啟動時增加 CPU |
| 環境變數 | 環境變數 |
| 暫時資料儲存空間 | 記憶體內磁碟區掛接 |
| Amazon Elastic File System 連線 | NFS 磁碟區掛接 |
| 不支援 S3 磁碟區掛接 | Cloud Storage 磁碟區掛接 |
| AWS Lambda 工作負載中的 AWS Secrets Manager | 密鑰 |
| 工作負載網址和 HTTP(S) 端點 | 自動指派的網址 Cloud Run 與 Google Cloud 產品整合 |
| 黏性工作階段 (使用外部負載平衡器) | 工作階段相依性 |
| 限定詞 | 修訂版本 |
除了上表列出的功能外，您也應考量 AWS Lambda 和 Cloud Run 佈建執行環境執行個體的方式差異。AWS Lambda 會為每個並行要求佈建單一執行個體。不過，Cloud Run 可讓您設定執行個體可處理的並行要求數量。也就是說，AWS Lambda 的佈建行為相當於在 Cloud Run 中，將每個執行個體的並行要求數量上限設為 1。將並行要求數量上限設為大於 1，可大幅節省費用，因為執行個體的 CPU 和記憶體會由並行要求共用，但只會計費一次。大多數 HTTP 架構都能平行處理要求。
Cloud Run 安全性和存取控管
設計 Cloud Run 資源時，您也需要決定遷移工作負載所需的安全性與存取控管機制。Cloud Run 支援多種設定選項，可協助您保護環境，並為 Cloud Run 工作負載設定角色和權限。
本節重點介紹 Cloud Run 提供的安全性和存取控管機制。這項資訊有助於您瞭解遷移的工作負載在 Cloud Run 中的運作方式，並找出重構這些工作負載時可能需要的 Cloud Run 選項。
如要進一步瞭解 Cloud Run 提供的驗證機制，請參閱下列資源：
如要進一步瞭解 Cloud Run 提供的安全防護功能，請參閱下列資源：
- 採用 Identity and Access Management (IAM) 控管存取權
- 個別服務身分
- Google Cloud Armor 整合
- 二進位授權
- 客戶自行管理的加密金鑰
- 軟體供應鏈安全性
- 輸入限制設定
- VPC Service Controls
請參閱下表，瞭解哪些 Cloud Run 安全性和存取控管機制與 AWS Lambda 提供的機制相當。針對需要佈建的每項 Cloud Run 資源，請務必選擇合適的存取控管機制和安全防護功能。
| AWS Lambda 功能 | Cloud Run 功能 |
|---|---|
| 使用 AWS Identity and Access Management 控管存取權 | 使用 Google Cloud的 IAM 存取控管 |
| 執行角色 | Google Cloud的 IAM 角色 |
| 權限邊界 | Google Cloud的 IAM 權限和自訂目標對象 |
| 管理控制項 | 組織政策服務 |
| 程式碼簽署 | 二進位授權 |
| 完整虛擬私有雲存取權 | 精細的虛擬私有雲輸出流量存取控管 |
佈建及設定 Cloud Run 資源
選擇要部署工作負載的 Cloud Run 資源後，您需要佈建及設定這些資源。如要進一步瞭解如何佈建 Cloud Run 資源，請參閱下列資源：
重構 AWS Lambda 工作負載
如要將 AWS Lambda 工作負載遷移至 Cloud Run，您可能需要重構這些工作負載。舉例來說，如果事件型工作負載接受包含 Amazon CloudWatch 事件的觸發條件，您可能需要重構該工作負載，使其接受 CloudEvents 格式的事件。
建議您使用 Gemini Code Assist 和 Gemini CLI，重構 AWS Lambda 工作負載。詳情請參閱「運用 Gemini 遷移至 Google Cloud」。
有幾項因素可能會影響每個 AWS Lambda 工作負載所需的重構量，例如：
- 架構。請考量工作負載的架構設計。舉例來說，如果 AWS Lambda 工作負載已將商業邏輯與存取 AWS 專屬 API 的邏輯明確區隔，則與混合這兩種邏輯的工作負載相比，可能需要較少的重構作業。
- 冪等性。請考量工作負載是否與輸入內容等冪。與需要維護已處理輸入內容狀態的工作負載相比，對輸入內容具有冪等性的工作負載可能需要較少的重構。
- State (狀態)。請考量工作負載是否為無狀態。與維護狀態的工作負載相比，無狀態工作負載可能需要較少的重構。如要進一步瞭解 Cloud Run 支援哪些資料儲存服務，請參閱「Cloud Run 儲存空間選項」。
- 執行階段環境。請考量工作負載是否對執行階段環境有任何假設。對於這類工作負載，您可能需要在 Cloud Run 執行階段環境中滿足相同的假設，或者如果無法對 Cloud Run 執行階段環境做出相同的假設，則需要重構工作負載。舉例來說，如果工作負載需要特定套件或程式庫，您必須在要託管該工作負載的 Cloud Run 執行階段環境中安裝這些套件或程式庫。
- 設定插入。請考量工作負載是否支援使用環境變數和密鑰來插入 (設定) 設定。與支援其他設定注入機制的工作負載相比，支援這類注入的工作負載可能需要較少的重構。
- API。考量工作負載是否會與 AWS Lambda API 互動。與這些 API 互動的工作負載可能需要重構，才能使用 Cloud API 和 Cloud Run API。
- Error Reporting。請考量工作負載是否使用標準輸出內容和錯誤串流回報錯誤。與使用其他機制回報錯誤的工作負載相比，執行這類 Error Reporting 的工作負載可能需要較少的重構。
如要進一步瞭解如何開發及最佳化 Cloud Run 工作負載，請參閱下列資源：
- 一般開發提示
- 針對 Cloud Run 最佳化 Java 應用程式
- 針對 Cloud Run 最佳化 Python 應用程式
- 負載測試最佳做法
- 工作重試和檢查點最佳做法
- 使用 Nginx 進行前端 Proxy 處理
- 使用 Cloud CDN 和 Cloud Run 提供靜態資產
- 瞭解 Cloud Run 可用區備援
重構部署和作業程序
重構工作負載後，您需要重構部署和作業程序，以便執行下列操作：
- 在 Google Cloud 環境中佈建及設定資源，而非在來源環境中佈建資源。
- 建構及設定工作負載，並部署至 Google Cloud，而非來源環境。
您在評估階段已收集這些程序的相關資訊。
您需要考慮對這些程序進行的重構類型，取決於您設計和實作這些程序的方式。重構也取決於您希望每個程序的最終狀態為何。例如，請考慮以下幾點：
- 您可能已在來源環境中實作這些程序，並打算在 Google Cloud中設計及實作類似的程序。舉例來說，您可以重構這些程序，改用 Cloud Build、Cloud Deploy 和 Infrastructure Manager。
- 您可能已在來源環境以外的其他第三方環境中實作這些程序。在這種情況下，您需要重構這些程序，改為指定 Google Cloud 環境，而非來源環境。
- 結合上述方法。
重構部署和作業程序可能相當複雜，需要投入大量心力。如果您嘗試在工作負載遷移期間執行這些工作，工作負載遷移作業可能會變得更複雜，並可能帶來風險。評估部署和作業程序後，您應該已瞭解其設計和複雜度。如果您預估需要投入大量心力重構部署和作業程序，建議您考慮將這些程序重構為獨立的專屬專案。
如要進一步瞭解如何在 Google Cloud上設計及實作部署程序，請參閱：
本文件著重於產生要部署的構件，並將其部署至目標執行階段環境的部署程序。重構策略高度取決於這些程序的複雜程度。以下清單概述可能的一般重構策略：
- 在 Google Cloud佈建構件存放區。例如，您可以使用 Artifact Registry 儲存構件及建構依附元件。
- 重構建構程序，將構件同時儲存在來源環境和 Artifact Registry。
- 重構部署程序，將工作負載部署至目標Google Cloud 環境。舉例來說，您可以先使用 Artifact Registry 中儲存的構件，在 Google Cloud中部署一小部分工作負載。接著，您會逐步增加部署在 Google Cloud中的工作負載 數量，直到所有要遷移的工作負載都在 Google Cloud上執行。
- 重構建構程序，只將構件儲存在 Artifact Registry。
- 如有必要，請將要部署的早期版本構件，從來源環境中的存放區遷移至 Artifact Registry。舉例來說，如要將容器映像檔遷移至 Artifact Registry，可以使用 gcrane 或 Rackware SWIFT 等工具。
- 不再需要來源環境中的存放區時，請將其停用。
為了在遷移期間因未預期的問題而最終復原，您可以在遷移至 Google Cloud 時，將容器映像檔儲存在 Google Cloud 目前的構件存放區中。最後，在停用來源環境時，您可以重構容器映像檔建構程序，只將構件儲存在Google Cloud 中。
雖然這可能不是遷移成功的關鍵，但您可能需要將舊版構件從來源環境遷移至 Google Cloud上的構件存放區。舉例來說，如要支援將工作負載復原至任意時間點，您可能需要將舊版構件遷移至 Artifact Registry。詳情請參閱「從第三方註冊資料庫遷移映像檔」。
如果您使用 Artifact Registry 儲存構件，建議您設定控管機制，協助保護構件存放區，例如存取控管、資料竊取防護、安全漏洞掃描和二進位授權。詳情請參閱「控管存取權及保護構件」。
重構作業程序
在遷移至 Cloud Run 的過程中，建議您重構作業流程，持續有效地監控 Cloud Run 環境。
Cloud Run 與下列作業服務整合：
- Google Cloud Observability：為工作負載提供記錄、監控和警告功能。如有需要，您也可以為 Cloud Run 工作負載取得 Prometheus 式監控或 OpenTelemetry 指標。
- Cloud 稽核記錄：提供稽核記錄。
- Cloud Trace：提供分散式效能追蹤功能。
遷移資料
在程序前期的評估階段，您應該已判斷要遷移的 AWS Lambda 工作負載是否依賴或產生 AWS 環境中的資料。舉例來說，您可能已決定要將資料從 AWS S3 遷移至 Cloud Storage，或從 Amazon RDS 和 Aurora 遷移至 Cloud SQL 和 AlloyDB for PostgreSQL。如要進一步瞭解如何將資料從 AWS 遷移至Google Cloud，請參閱「從 AWS 遷移至 Google Cloud：開始使用」。
與重構部署和作業程序一樣，將資料從 AWS 遷移至 Google Cloud 可能相當複雜，且需要投入大量心力。如果您嘗試在遷移 AWS Lambda 工作負載時執行這些資料遷移工作，遷移作業可能會變得複雜，並可能帶來風險。分析要遷移的資料後，您應該會瞭解資料的大小和複雜度。如果您預估需要投入大量心力才能遷移這項資料，建議您考慮將資料遷移作業視為獨立的專屬專案。
驗證遷移結果
驗證工作負載遷移作業並非一次性事件，而是持續進行的程序。從 AWS Lambda 遷移至 Cloud Run 之前、期間和之後，您都必須持續測試及驗證。
為確保遷移作業順利完成、效能最佳，並盡可能減少中斷情形，建議您按照下列程序，驗證從 AWS Lambda 遷移至 Cloud Run 的工作負載：
- 開始遷移階段前，請先重構現有的測試案例，將目標 Google Cloud 環境納入考量。
- 在遷移期間，請在每個遷移里程碑驗證測試結果，並進行徹底的整合測試。
- 遷移後，請執行下列測試：
- 基準測試：在 AWS Lambda 上建立原始工作負載的效能基準，例如執行時間、資源用量和不同負載下的錯誤率。在 Cloud Run 複製這些測試，找出可能代表遷移或設定問題的差異。
- 功能測試：建立並執行測試案例，涵蓋兩個環境中的各種輸入和預期輸出情境，確保工作負載的核心邏輯保持一致。
- 負載測試：逐步增加流量，評估 Cloud Run 在實際條件下的效能和擴充性。為確保遷移作業順利進行，請解決錯誤和資源限制等不一致問題。
最佳化 Google Cloud 環境
最佳化是遷移作業的最後階段。在這個階段，您會反覆執行最佳化工作，直到目標環境符合最佳化需求。每次疊代的步驟如下：
- 評估目前的環境、團隊和最佳化循環。
- 確立最佳化需求和目標。
- 最佳化環境和團隊。
- 調整最佳化循環。
重複這個流程，直到達成最佳化目標。
如要進一步瞭解如何最佳化 Google Cloud 環境，請參閱「遷移至 Google Cloud：最佳化環境」和「Google Cloud Well-Architected Framework：效能最佳化」。
後續步驟
- 瞭解其他從 AWS 遷移至 Google Cloud 的歷程。
- 瞭解如何比較 AWS 和 Azure 服務與 Google Cloud。
- 瞭解如何取得遷移作業相關協助。
- 參加 Google Skills 訓練課程，瞭解如何遷移至 Google Cloud。
- 如要查看更多參考架構、圖表和最佳做法，請瀏覽 Cloud Architecture Center。
貢獻者
作者：
- Marco Ferrari | 雲端解決方案架構師
- Xiang Shen | 解決方案架構師
其他貢獻者：
- Steren Giannini | 產品群經理
- James Ma | 產品經理
- Henry Bell | 雲端解決方案架構師
- Christoph Stanger | 策略雲端工程師
- CC Chen | 客戶解決方案架構師
- Wietse Venema | 開發人員關係工程師