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

# AWS 應用程式設計和遷移策略
<a name="aws-application-design-and-migration-strategy"></a>

設計和記錄應用程式的未來狀態是關鍵遷移成功因素。我們建議為任何類型的遷移策略建立設計，無論多簡單或多複雜。即使架構預期不會變更，建立設計也會呈現潛在的封鎖程式、相依性和最佳化應用程式的機會。此外，產生的設計將作為遷移後進一步發展的基礎。 

除了設計程序的重要性之外，它也可以成為封鎖程式並影響遷移速度。這是因為現場部署系統所設想的舊式架構審查程序。我們建議您檢閱架構審核和核准程序，並專注於建立可預先核准的架構模式或類型。請勿低估檢閱數百或數千個應用程式架構的工作，並藉此機會將程序現代化。

下列清單包含協助設計程序的資源：
+ [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 最佳實務型體驗。

## 應用程式未來狀態
<a name="application-future-state"></a>

首先建立此應用程式的初始遷移策略。此時，策略會被視為初始策略，因為它可能會作為未來狀態設計的一部分而變更，從而發現潛在的限制。若要驗證初始假設，請參閱 [6 Rs 決策樹](prioritization-and-migration-strategy.md#migration-r-type)。此外，記錄潛在的遷移階段。例如，此應用程式是否會在單一事件中遷移 （所有元件都會同時遷移）？ 或者，這是分階段遷移 （某些元件稍後會遷移）？

請注意，指定應用程式的遷移策略可能不是唯一的。這是因為多個 R 類型可用於遷移應用程式元件。例如，初始方法可能是在沒有變更的情況下提升和轉移應用程式。不過，應用程式的元件可能位於不同的基礎設施資產中，可能需要不同的處理方式。例如，應用程式由三個元件組成，每個元件在不同的伺服器上執行，而其中一個伺服器執行雲端不支援的舊版作業系統。該元件需要一個轉換方法，而其他兩個在支援的伺服器版本中執行的元件可以重新託管。將遷移策略指派給要遷移的每個應用程式元件和相關聯的基礎設施至關重要。

接著，記錄內容和問題，並連結定義目前狀態的現有成品：
+ 為什麼要遷移此應用程式？ 
+ 提議的變更有哪些？ 
+ 有哪些好處？ 
+ 是否有任何主要風險或封鎖程式？ 
+ 目前的缺點是什麼？ 
+ 範圍內和範圍外是什麼？ 

## 重複性
<a name="repeatability"></a>

在整個設計工作中，請考慮如何為此應用程式重複使用此解決方案和架構。這個解決方案可以廣義化嗎？

## 要求
<a name="requirements"></a>

記錄此應用程式的功能和非功能需求，包括安全性。這包括目前和未來的狀態需求，取決於所選的遷移策略。使用詳細應用程式評估期間收集的資訊來引導此程序。

## To-be 架構
<a name="to-be-architecture"></a>

描述此應用程式的未來架構。請考慮建立可重複使用的圖表範本，其中包含來源環境 （內部部署） 和目標 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 端點）？

## 架構決策
<a name="architectural-decisions"></a>

在設計過程中，您可能會找到更多整體架構或其特定部分的選項。將這些選項與偏好或所選選項的原理一起記錄。這些決策可以記錄為架構決策。 

確保列出和描述主要選項，並提供足夠的詳細資訊，讓新讀者了解決策背後的選項和原因，以使用一個選項而非另一個選項。

## 軟體生命週期環境
<a name="software-lifecycle-environments"></a>

記錄目前環境的任何變更。例如，測試和開發環境將在 中重新建立 AWS ，而不會遷移。

## 標記
<a name="tagging"></a>

說明每個基礎設施元件的必要和建議標記，以及此設計的標記值。

## 遷移策略
<a name="migration-strategy"></a>

就設計而言，應驗證有關遷移策略的初始假設。確認所選 R 策略有共識。記錄整體應用程式遷移策略和個別應用程式元件的策略。如前所述，不同的應用程式元件可能需要不同的 R 類型來進行遷移。

此外，將遷移策略與關鍵業務驅動因素和成果保持一致。此外，描述遷移的任何分階段方法，例如在不同遷移事件中元件的移動。

如需判斷 6 個 R 的詳細資訊，請參閱[AWS Migration Hub 策略建議](https://aws.amazon.com/blogs/aws/new-strategy-recommendations-service-helps-streamline-aws-cloud-migration-and-modernization/)。

## 遷移模式和工具
<a name="migration-patterns-tools"></a>

透過應用程式和基礎設施元件的定義遷移策略，您現在可以探索特定的技術模式。例如，重新託管策略可以透過遷移工具實作，例如 [AWS Transform MGN](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(AWS SCT)](https://aws.amazon.com/dms/schema-conversion-tool/) 、 等工具[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/)包含各種遷移模式和技術。

## 服務管理和操作
<a name="service-management-and-operations"></a>

為遷移至 建立應用程式設計時 AWS，請考慮操作準備。使用應用程式和基礎設施團隊評估整備要求時，請考慮下列問題：
+ 他們準備好操作它了嗎？ 
+ 事件回應程序是否已定義？ 
+ 什麼是預期的服務水準協議 (SLA)？ 
+ 是否需要職責分離？ 
+ 不同的團隊是否已準備好協調支援動作？ 
+ 誰負責什麼？

## 切換考量
<a name="cutover-considerations"></a>

考量遷移策略和模式，遷移應用程式時需要了解哪些重要事項？ 切換規劃是設計後的活動。不過，針對可預期的活動和需求記錄任何考量。例如，如果適用，請記錄執行概念驗證的要求，並概述測試、稽核或驗證要求。

## 風險、假設、問題和相依性
<a name="risks-assumptions-issues-dependencies"></a>

記錄任何尚未解決的開放風險、假設和潛在問題。為這些項目指派明確的擁有權，並追蹤進度，以便整體設計和策略可以核准實作。此外，請記錄實作此設計的金鑰相依性。

## 估算執行成本
<a name="estimating-run-cost"></a>

若要預估目標 AWS 架構的成本，請使用 [AWS 定價計算工具](https://calculator.aws/)。依您的設計新增基礎設施元件，並取得預估的執行成本。將應用程式元件所需的軟體授權，以及尚未包含在 AWS 服務 您將使用的 中的軟體授權納入考量。