本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 優先應用程式評估
上一個階段的關鍵結果之一，[產品組合探索和初始規劃](portfolio-discovery-initial-planning.md)，是排定[應用程式子集的優先順序](prioritization-and-migration-strategy.md#prioritizing-applications)，以進行詳細評估。本節會探索應用程式的詳細評估。
儘早查看一些應用程式的詳細資訊將推動加速。評估和待定架構設計的程序會呈現潛在的封鎖程式，並釐清重要任務，這些任務會先行遷移到更大的範圍。這些任務包括收集建立 AWS 基礎的需求，例如 上的登陸區域 AWS，或擴展和驗證現有的登陸區域。此評估也是考慮步驟和遷移策略的時間。
此階段的主要結果如下：
+ 已驗證的優先順序應用程式清單
+ 記錄的目前狀態架構
+ 適用於遷移候選項目的記錄初始目標架構和遷移策略
+ 已識別的遷移模式和工具
+ 記錄的平台需求 （安全性、 AWS 基礎設施和操作）
+ 遷移規劃的記錄切換考量
+ 預估 AWS 執行速率
# 了解詳細的評估資料需求
下表說明取得遷移中應用程式的完整產品組合檢視及其相關聯基礎設施所需的資訊。
資料表使用以下縮寫：
+ R，針對必要
+ O，用於選用
+ N/A，適用於 不適用
**應用程式**
| **屬性名稱** | **描述** | **探索、設計和遷移策略** | **預估執行速率** | **建議的逼真度等級 （最低）** |
| --- |--- |--- |--- |--- |
| 唯一識別符 | 例如，應用程式 ID。通常適用於現有的 CMDBs或其他內部庫存和控制系統。每當組織中未定義 ID 時，請考慮建立唯一的 IDs。 | R | O | 高 |
| Application name (應用程式名稱) | 您的組織已知此應用程式的名稱。適用時包括商用off-the-shelf(COTS) 廠商和產品名稱。 | R | R | 高 |
| 是 COTS 嗎？ | 是或否。無論是商業應用程式還是內部開發 | R | R | 高 |
| COTS 產品和版本 | 商業軟體產品名稱和版本 | R | R | 高 |
| Description | 主要應用程式函數和內容 | R | O | 高 |
| 重要性 | 例如，策略或產生收入的應用程式，或支援關鍵 函數 | R | O | 高 |
| Type | 例如，資料庫、客戶關係管理 (CRM)、Web 應用程式、多媒體、IT 共用服務 | R | O | 高 |
| Environment | 例如，生產、生產前、開發、測試、沙盒 | R | R | 高 |
| 合規與法規 | 適用於工作負載的架構 （例如 HIPAA、SOX、PCI-DSS、ISO、SOC、FedRAMP) 和法規要求 | R | O | 高 |
| 相依性 | 對內部和外部應用程式或服務的上游和下游相依性 | R | N/A | 高 |
| 基礎設施映射 | 映射到組成應用程式的實體和/或虛擬資產 | R | R | 高 |
| 授權 | 商品軟體授權類型 （例如 Microsoft SQL Server Enterprise) | R | R | 高 |
| Cost | 軟體授權、軟體操作和維護的成本 | N/A | R | 中高 |
| 業務單位 | 例如，行銷、財務、銷售 | R | O | 高 |
| 擁有者詳細資訊 | 應用程式擁有者的聯絡資訊 | R | O | 高 |
| 架構類型 | 例如，Web 應用程式、2 層、3 層、微服務、服務導向架構 (SOA) | R | R | 高 |
| 復原點目標 (RPO)、復原時間目標 (RTO) 和 /服務層級協議 (SLA) | 目前的服務 - 管理屬性 | R | R | 高 |
| 產生營收的應用程式或商業策略應用程式？ | 是，如果應用程式直接或間接影響公司收入或業務視為策略。 | R | O | 中高 |
| 使用者數量 （並行） | 例如，內部或外部使用者，或內部和/或外部使用者/客戶 | R | R | 中高 |
| 使用者位置 | 使用者工作階段的來源 | R | R | 中高 |
| 風險與問題 | 已知風險和問題 | R | O | 中高 |
| 遷移考量事項 | 任何可能與遷移相關的其他資訊 | R | R | 中高 |
| 遷移策略 | 例如，用於遷移的 AWS 6 個 R 之一 | R | R | 中高 |
| 資料庫詳細資訊 | 例如，分割、加密、複寫、延伸、Secure Sockets Layer (SSL) 支援 | R | R | 高 |
| 支援團隊 | 例如，應用程式操作團隊名稱 | R | O | 中高 |
| 監控解決方案 | 用於監控此應用程式的產品 | R | O | 中高 |
| 備份需求 | 中的必要備份排程 AWS | R | R | 中高 |
| DR 資訊 | 例如，此應用程式的災難復原元件 | R | R | 中高 |
| 目標 AWS 需求 | 例如，元件、帳戶置放、聯網、安全 | R | R | 高 |
**基礎設施**
| | | | | |
| --- |--- |--- |--- |--- |
| **屬性名稱** | **描述** | **探索、設計和遷移策略** | **預估執行速率** | **建議的保真度等級 （最低）** |
| 唯一識別符 | 例如，伺服器 ID。通常適用於現有的 CMDBs或其他內部庫存和控制系統。每當組織中未定義 ID 時，請考慮建立唯一的 IDs。 | R | O | 高 |
| 網路名稱 | 網路中的資產名稱 （例如主機名稱） | R | O | 高 |
| DNS 名稱 （完整網域名稱，或 FQDN) | DNS 名稱 | O | O | 中高 |
| IP 地址和網路遮罩 | 內部和/或公有 IP 地址 | R | R | 高 |
| 資產類型設定 | 例如，實體或虛擬伺服器、Hypervisor、容器、裝置、資料庫執行個體 | R | R | 高 |
| 產品名稱 | 商業廠商和產品名稱 （例如 VMware ESXi、IBM Power Systems、Exadata) | R | R | 高 |
| 作業系統 | 例如，REHL 8、Windows Server 2019、AIX 6.1 | R | R | 高 |
| Configuration | 配置的 CPU、核心數量、每個核心的執行緒、總記憶體、儲存、網路卡 | R | R | 高 |
| 使用率 | CPU、記憶體和儲存峰值和平均值。資料庫執行個體輸送量。 | R | R | 高 |
| 授權 | 商品授權類型 （例如 RHEL Standard) | R | R | 高 |
| 是共用基礎設施嗎？ | 是或否表示提供共用服務的基礎設施服務，例如身分驗證提供者、監控系統、備份服務和類似服務 | R | O | 高 |
| 應用程式映射 | 在此基礎設施中執行的應用程式或應用程式元件 | R | O | 高 |
| 通訊資料 | 例如，在程序層級的伺服器對伺服器 | R | N/A | 中高 |
| 目標 AWS 需求 | 例如，執行個體類型、帳戶、子網路、安全群組、路由 | R | R | 高 |
| 遷移策略、模式和工具 | 例如，遷移的 6 個 R 之一、特定技術模式、遷移工具 | R | O | 高 |
| 風險與問題 | 已知風險和問題 | R | O | 中高 |
# 詳細的應用程式評估
詳細的應用程式評估目標是完全了解目標應用程式及其相關聯的基礎設施 （運算、儲存和網路）。為了避免陷阱，高保真度資料是必要的。例如，組織通常會假設他們完全了解應用程式。這是自然的，在許多情況下也是如此。不過，為了將業務風險降至最低，請務必盡可能取得程式設計資料來驗證機構知識和靜態文件。這將處理探索程序的繁重工作。您可以專注於來自替代來源的資料元素，例如業務特定資訊、策略藍圖等。
關鍵是避免遷移期間和之後的最後一分鐘變更。例如，遷移時，請務必避免根據無法識別的相依性進行變更，這些相依性可能需要將伺服器包含在持續的遷移波中。遷移後不久，請務必避免根據相關聯的平台需求進行變更，以允許流量或部署其他服務。這些類型的意外變更會增加安全和操作問題的風險。我們強烈建議在執行詳細的應用程式評估時，使用程式設計探索工具來驗證流量模式和相依性。
在評估開始時，您必須識別應用程式利益相關者。這些通常如下：
+ 業務單位主管
+ 應用程式擁有者
+ 架構師
+ 操作和支援
+ 雲端啟用團隊
+ 特定的平台團隊，例如運算、儲存和網路
有兩種方法可進行詳細探索。由上而下探索從應用程式開始，甚至從使用者開始，一路向下到基礎設施。這是明確識別應用程式時的建議方法。相反地，由下而上的探索從基礎設施開始，一路延伸到應用程式或服務及其使用者。當遷移計劃由基礎設施團隊驅動，以及application-to-infrastructure映射不清楚時，這種方法很有用。一般而言，您可能會使用兩者的組合。
若要深入探索應用程式，現有的架構圖是很好的開始。如果這些不可用，請根據目前的知識建立一個。請勿低估此任務的重要性，即使是簡單的重新託管或重新放置遷移策略也一樣。繪製架構圖可協助您識別在雲端中發生細微變更時可以快速解決的效率低下問題。
根據您是否執行由上而下或由下而上的方法，初始圖表將繪製應用程式元件和服務或基礎設施元件，例如伺服器和負載平衡器。識別主要元件和界面之後，請使用探索工具和應用程式效能監控工具中的程式設計資料進行驗證。這些工具必須支援相依性分析，並提供元件之間的通訊資訊。必須識別構成此應用程式的每個元件。接下來，記錄對其他應用程式和服務的相依性，包括內部和外部。
如果缺少驗證相依性和映射的工具，則需要手動方法。例如，您可以登入基礎設施元件並執行指令碼來收集通訊資訊，例如開放連接埠和已建立的連線。同樣地，您可以識別執行中的程序和已安裝的軟體。請勿低估手動探索所需的工作量。程式設計工具可以在幾天內擷取和報告大多數相依性，但間隔較大的相依性除外 （通常為小百分比）。手動探索可能需要數週的時間來收集和合併所有資料點，而且仍然容易發生錯誤和遺失資料。
繼續取得每個優先應用程式和映射基礎設施[的資料需求](understanding-detailed-assessment-data-requirements.md)區段中指定的資訊。接著，使用以下問卷引導您完成詳細的評估程序。與已識別的利益相關者會面，討論這些問題的答案。
## 一般
+ 此應用程式的關鍵程度為何？ 是否產生營收？ 這是商業策略還是支援業務應用程式？ 這是其他系統共用的核心基礎設施服務嗎？
+ 此應用程式是否有任何持續的轉換專案？
+ 這是面向內部或外部的應用程式？
## Architecture
+ 目前的架構類型是什麼 （例如 SOA、微服務、整體）？ 架構有多少層？ 是緊密耦合還是鬆耦合？
+ 什麼是元件 （例如，運算、資料庫、遠端儲存、負載平衡器、快取服務）？
+ 什麼是 APIs？ 描述這些項目，包括 API 名稱、操作、URLs、連接埠和通訊協定。
+ 元件之間以及此和其他應用程式或服務之間可容忍的最大延遲是多少？
## 作業
+ 此應用程式在哪些位置運作？
+ 誰負責操作應用程式和基礎設施？ 這些是由內部或 AWS 合作夥伴團隊操作？
+ 如果此應用程式故障，會發生什麼情況？ 誰會受到影響？ 有什麼影響？
+ 使用者或客戶位於何處？ 他們如何存取應用程式？ 並行使用者的數量是多少？
+ 上次技術重新整理是何時？ 未來是否排定重新整理？ 如果是，何時？
+ 此應用程式有哪些已知的風險和問題？ 中斷和中嚴重性和高嚴重性事件的歷史記錄為何？
+ 使用週期為何 （營業時間）？ 什麼是操作時區？
+ 什麼是變更凍結期間？
+ 使用什麼解決方案來監控此應用程式？
## 效能
+ 所收集的效能資訊顯示什麼？ 用量是尖峰還是恆定且可預測？ 可用效能資料的時間範圍、間隔和日期為何？
+ 是否有屬於此應用程式或與之互動的排程批次任務？
## 軟體生命週期
+ 目前的變更率是多少 （每週、每月、每季或每年）？
+ 什麼是開發生命週期 （例如，測試、開發、QA、UAT、生產前、生產）？
+ 應用程式和基礎設施的部署方法有哪些？
+ 什麼是部署工具？
+ 此應用程式或基礎設施是否使用持續整合 (CI)/持續交付 (CD)？ 什麼是自動化層級？ 什麼是手動任務？
+ 應用程式和基礎設施的授權要求是什麼？
+ 什麼是服務水準協議 (SLA)？
+ 目前的測試機制是什麼？ 什麼是測試階段？
## 移轉
+ 什麼是遷移考量？
此時，請注意遷移此應用程式時的任何考量。如需更完整且準確的評估，請從不同的利益相關者取得此問題的答案。然後，對照他們的知識和意見。
## 彈性
+ 什麼是目前的備份方法？ 哪些產品用於備份？ 什麼是備份排程？ 什麼是備份保留政策？
+ 目前的復原點目標 (RPO) 和復原時間目標 (RTO) 是什麼？
+ 此應用程式是否有災難復原 (DR) 計劃？ 若是如此，什麼是 DR 解決方案？
+ 上次 DR 測試是何時？
## 安全和合規
+ 適用於此應用程式的合規和法規架構有哪些？ 上次和下一個稽核日期為何？
+ 此應用程式是否託管敏感資料？ 什麼是資料分類？
+ 資料是傳輸中還是靜態，還是兩者同時加密？ 什麼是加密機制？
+ 此應用程式是否使用 SSL 憑證？ 什麼是發行授權機構？
+ 使用者、元件和其他應用程式和服務的身分驗證方法是什麼？
## 資料庫
+ 此應用程式使用哪些資料庫？
+ 與資料庫並行連線的典型數量是多少？ 連線數量下限和上限是多少？
+ 什麼是連線方法 （例如 JDBC、ODBC)？
+ 是否記錄連線字串？ 如果是，在哪裡？
+ 什麼是資料庫結構描述？
+ 資料庫是否使用自訂資料類型？
## 相依性
+ 元件之間的相依性為何？ 請注意，任何無法解析且需要將元件遷移到一起的相依性。
+ 元件是否跨位置分割？ 這些位置之間的連線為何 （例如 WAN、VPN)？
+ 此應用程式與其他應用程式或服務有何相依性？
+ 什麼是操作相依性？ 例如，維護和發行週期，例如修補時段。
# AWS 應用程式設計和遷移策略
設計和記錄應用程式的未來狀態是關鍵遷移成功因素。我們建議為任何類型的遷移策略建立設計，無論多簡單或多複雜。即使架構預期不會變更，建立設計也會呈現潛在的封鎖程式、相依性和最佳化應用程式的機會。
我們也建議使用 AWS 遷移策略鏡頭，在 中接近應用程式的未來狀態。在此階段，請確定您定義應用程式 AWS 會因為此遷移而出現在 中的情況。產生的設計將作為遷移後進一步發展的基礎。
下列清單包含協助設計程序的資源：
+ [AWS Architecture Center](https://aws.amazon.com/architecture/) 結合了工具和指引，例如 AWS Well-Architected Framework。此外，它還提供可用於應用程式的參考架構。
+ [Amazon Builders' Library ](https://aws.amazon.com/builders-library/)包含數個有關 Amazon 如何建置和操作軟體的資源。
+ [AWS Solutions Library](https://aws.amazon.com/solutions/) 為 AWS數十種技術和業務問題提供了一系列由 審核的雲端解決方案。它包含大量的參考架構。
+ [AWS 方案指引](https://aws.amazon.com/prescriptive-guidance/)提供策略、指南和模式，協助設計程序和遷移最佳實務。
+ [AWS Documentation](https://docs.aws.amazon.com/) 包含 AWS 服務的相關資訊，包括 使用者指南和 API 參考。
+ [入門資源中心](https://aws.amazon.com/getting-started/)提供數個實作教學課程和深入探討，以學習基礎知識，讓您可以開始建置 AWS。
視您在雲端旅程中的位置而定， AWS 基礎可能已存在。這些 AWS 基礎包括下列項目：
+ AWS 區域 已識別。
+ 帳戶已建立或可隨需取得。
+ 已實作一般聯網。
+ 基礎 AWS 服務已部署在帳戶中。
相反地，您可能在程序初期，而且尚未建立 AWS 基礎。缺乏已建立的基礎可能會限制應用程式設計的範圍，或需要進一步努力來定義它們。如果是這種情況，我們建議您與應用程式設計工作平行定義和實作登陸區域的基礎設計。應用程式設計有助於識別需求，例如 AWS 帳戶 結構、聯網、虛擬私有雲端 (VPCs)、無類別網域間路由 (CIDR) 範圍、共用服務、安全性和雲端操作。
[AWS Control Tower](https://aws.amazon.com/controltower/) 提供最簡單的方式來設定和管理安全、多帳戶 AWS 環境，稱為登陸區域。 會使用 AWS Control Tower 建立您的登陸區域 AWS Organizations，在數千位客戶遷移至雲端時，提供持續的帳戶管理和管控和實作 AWS 最佳實務體驗。
## 應用程式未來狀態
首先建立此應用程式的初始遷移策略。此時，策略會被視為初始策略，因為它可能會作為未來狀態設計的一部分而變更，從而發現潛在的限制。若要驗證初始假設，請參閱 [6 Rs 決策樹](prioritization-and-migration-strategy.md#migration-r-type)。此外，記錄潛在的遷移階段。例如，此應用程式是否會在單一事件中遷移 （所有元件都會同時遷移）？ 或者，這是分階段遷移 （某些元件稍後會遷移）？
請注意，特定應用程式的遷移策略可能不是唯一的。這是因為多個 R 類型可用於遷移應用程式元件。例如，初始方法可能是在沒有變更的情況下提升和轉移應用程式。不過，應用程式的元件可能位於不同的基礎設施資產中，可能需要不同的處理方式。例如，應用程式由三個元件組成，每個元件在不同的伺服器上執行，而其中一個伺服器執行雲端不支援的舊版作業系統。該元件需要一個轉換方法，而其他兩個在支援的伺服器版本中執行的元件可以重新託管。將遷移策略指派給要遷移的每個應用程式元件和相關聯的基礎設施至關重要。
接著，記錄內容和問題，並連結定義目前狀態的現有成品：
+ 為什麼要遷移此應用程式？
+ 提議的變更有哪些？
+ 有哪些好處？
+ 是否有任何主要風險或封鎖條件？
+ 目前的缺點是什麼？
+ 範圍內和範圍外是什麼？
## 重複性
在整個設計工作中，請考慮如何為此應用程式重複使用此解決方案和架構。這個解決方案可以廣義化嗎？
## 要求
記錄此應用程式的功能和非功能需求，包括安全性。這包括目前和未來的狀態需求，取決於所選的遷移策略。使用詳細應用程式評估期間收集的資訊來引導此程序。
## To-be 架構
描述此應用程式的未來架構。請考慮建立可重複使用的圖表範本，其中包含來源環境 （內部部署） 和目標 AWS 環境 （例如 AWS 區域目標、帳戶、VPCs和可用區域） 的建置區塊。
建立要遷移的元件和新元件的資料表。包含與此應用程式互動的其他應用程式和服務 （內部部署或雲端）。
下表列出範例元件。它不代表參考架構或經過審核的組態。
| **名稱** | **描述** | **詳細資訊** |
| --- |--- |--- |
| 應用程式 | 外部服務 （傳入連線） | 服務會使用公開 API 的資料。 |
| DNS | 名稱解析 （內部） | 部署為基準帳戶設定一部分的 Amazon Route 53 |
| Application Load Balancer | 在後端服務之間分配流量 | 取代內部部署負載平衡器。遷移集區 A。 |
| 應用程式安全 | DdoS 保護 | 使用 實作 AWS Shield |
| 安全群組 | 虛擬防火牆 | 限制對連接埠 443 （傳入） 上應用程式執行個體的存取。 |
| 伺服器 A | 前端 | 使用 Amazon Elastic Compute Cloud (Amazon EC2) 重新託管。 |
| 伺服器 B | 前端 | 使用 Amazon EC2 重新託管。 |
| 伺服器 C | 應用程式邏輯 | 使用 Amazon EC2 重新託管。 |
| 伺服器 D | 應用程式邏輯 | 使用 Amazon EC2 重新託管。 |
| Amazon Relational Database Service (Amazon RDS) – Amazon Aurora | 資料庫 | 取代伺服器 E 和 F |
| 監控和提醒 | 變更控制 | Amazon CloudWatch |
| 稽核記錄 | 變更控制 | AWS CloudTrail |
| 修補和遠端存取 | Maintenance (維護) | AWS Systems Manager |
| 資源存取 | 安全存取控制 | AWS Identity and Access Management (IAM) |
| 身分驗證 | 使用者存取 | Amazon Cognito |
| 憑證 | SSL/TLS | AWS Certificate Manager |
| API 1 | 外部 API | Amazon API Gateway |
| 物件儲存體 | 映像託管 | Amazon Simple Storage Service (Amazon S3) |
| 憑證 | 憑證的管理和託管 | AWS Secrets Manager |
| AWS Lambda 函數 | 擷取資料庫憑證和 API 金鑰 | AWS Lambda |
| 網際網路閘道 | 傳出網際網路存取 | VPC 的網際網路閘道 |
| 私有子網路 1 | 後端和資料庫 | 可用區域 1 – VPC 1 |
| 私有子網路 2 | 後端和資料庫 | 可用區域 2 – VPC 1 |
| 公有子網路 1 | 前端 | 可用區域 1 – VPC 1 |
| 公有子網路 2 | 前端 | 可用區域 2 – VPC 1 |
| 備份服務 | 資料庫和 EC2 執行個體備份 | AWS Backup |
| DR | Amazon EC2 彈性 | AWS 彈性災難復原 |
識別元件之後，請使用您偏好的工具將其繪製在圖表中。與主要應用程式利益相關者共用初始設計，包括應用程式擁有者、企業架構師，以及平台和遷移團隊。請考慮詢問下列問題：
+ 團隊是否通常同意設計？
+ 營運團隊可以支援嗎？
+ 設計可以進化嗎？
+ 還有其他選項嗎？
+ 設計是否符合架構標準和安全政策？
+ 是否有任何元件遺失 （例如，程式碼儲存庫、CI/CD 工具、VPC 端點）？
## 架構決策
在設計過程中，您可能會找到更多整體架構或其特定部分的選項。將這些選項與偏好或所選選項的原理一起記錄。這些決策可以記錄為架構決策。
確保列出和描述主要選項，並提供足夠的詳細資訊，讓新讀者了解決策背後的選項和原因，以使用一個選項而非另一個選項。
## 軟體生命週期環境
記錄目前環境的任何變更。例如，測試和開發環境將在 中重新建立 AWS ，而不會遷移。
## 標記
說明每個基礎設施元件的必要和建議標記，以及此設計的標記值。
## 遷移策略
就設計而言，應驗證有關遷移策略的初始假設。確認所選 R 策略有共識。記錄整體應用程式遷移策略和個別應用程式元件的策略。如前所述，不同的應用程式元件可能需要不同的 R 類型來進行遷移。
此外，將遷移策略與關鍵業務驅動因素和成果保持一致。此外，描述遷移的任何分階段方法，例如在不同遷移事件中元件的移動。
如需判斷 6 個 R 的詳細資訊，請參閱[AWS Migration Hub 策略建議](https://aws.amazon.com/blogs/aws/new-strategy-recommendations-service-helps-streamline-aws-cloud-migration-and-modernization/)。
## 遷移模式和工具
透過應用程式和基礎設施元件的定義遷移策略，您現在可以探索特定的技術模式。例如，重新託管策略可以透過遷移工具實作，例如 [AWS Application Migration Service](https://aws.amazon.com/application-migration-service/)。如果您不需要複寫狀態或資料，您可以使用 Amazon Machine Image (AMI) 和應用程式部署管道重新部署應用程式，以達到相同的結果。
同樣地，若要重建或重構 （重新建構） 應用程式，您可以使用 [AWS App2Container](https://aws.amazon.com/app2container/)、 [AWS Database Migration Service (AWS DMS)](https://aws.amazon.com/dms/)、 [AWS Schema Conversion Tool](https://aws.amazon.com/dms/schema-conversion-tool/)(AWS SCT)、 等工具[AWS DataSync](https://aws.amazon.com/datasync/)。對於容器化，您可以使用 [Amazon Elastic Container Service (Amazon ECS)](https://aws.amazon.com/ecs/)、[Amazon Elastic Kubernetes Service (Amazon EKS)](https://aws.amazon.com/eks/) 或 [AWS Fargate](https://aws.amazon.com/fargate/)。重新購買時，您可以將 AMI 用於 的特定產品或軟體即服務 (SaaS) 解決方案[AWS Marketplace](https://aws.amazon.com/marketplace/)。
評估可用於實現目標的不同模式和選項。考慮優缺點，以及遷移操作準備程度。為了協助您進行分析，請使用下列問題：
+ 遷移團隊可以支援這些模式嗎？
+ 成本和利益之間的平衡是什麼？
+ 此應用程式、服務或元件是否可以移至受管服務？
+ 實作此模式的工作為何？
+ 是否有任何法規或合規政策阻止使用特定模式？
+ 是否可以重複使用此模式？ 建議使用可重複使用的模式。不過，有時模式只會使用一次。考慮在單次使用模式的工作量與替代可重複使用模式之間取得平衡。
[AWS 方案指引](https://aws.amazon.com/prescriptive-guidance/)包含各種遷移模式和技術。
## 服務管理和操作
為遷移至 建立應用程式設計時 AWS，請考慮操作準備。使用應用程式和基礎設施團隊評估整備要求時，請考慮下列問題：
+ 他們準備好操作它了嗎？
+ 事件回應程序是否已定義？
+ 什麼是預期的服務水準協議 (SLA)？
+ 是否需要職責分離？
+ 不同的團隊是否已準備好協調支援動作？
+ 誰負責什麼？
## 切換考量
考量遷移策略和模式，遷移應用程式時需要了解哪些重要事項？ 切換規劃是設計後的活動。不過，針對可預期的活動和需求，記錄任何考量事項。例如，如果適用，請記錄執行概念驗證的要求，並概述測試、稽核或驗證要求。
## 風險、假設、問題和相依性
記錄任何尚未解決的開放風險、假設和潛在問題。為這些項目指派明確的擁有權，並追蹤進度，以便整體設計和策略可以核准實作。此外，請記錄實作此設計的金鑰相依性。
## 估算執行成本
若要預估目標 AWS 架構的成本，請使用 [AWS 定價計算器](https://calculator.aws/)。依您的設計新增基礎設施元件，並取得預估的執行成本。將應用程式元件所需的軟體授權，以及尚未包含在您將使用 AWS 之服務中的軟體授權納入考量。