AWS 應用程式設計和遷移策略 - AWS 方案指引
應用程式未來狀態重複性要求To-be 架構架構決策軟體生命週期環境標記遷移策略遷移模式和工具服務管理和操作切換考量風險、假設、問題和相依性預估執行成本

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

AWS 應用程式設計和遷移策略

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

我們也建議您 AWS 使用遷移策略鏡頭來接近 中應用程式的未來狀態。在此階段，請確定您定義應用程式 AWS 因此遷移而出現在 中的情況。產生的設計將作為遷移後進一步發展的基礎。

下列清單包含協助設計程序的資源：

  • AWS Architecture Center 結合了工具和指引，例如 AWS Well-Architected Framework。此外，它還提供可用於應用程式的參考架構。

  • Amazon Builders' Library 包含有關 Amazon 如何建置和操作軟體的數個資源。

  • AWS Solutions Library 提供雲端型解決方案的集合，由 審核數 AWS十種技術和業務問題。它包含大量的參考架構。

  • AWS 方案指引提供策略、指南和模式，協助設計程序和遷移最佳實務。

  • AWS Documentation 包含 AWS 服務的相關資訊，包括 使用者指南和 API 參考。

  • 入門資源中心提供數個實作教學課程和深入探討，以學習基礎知識，讓您可以開始建置 AWS。

根據您在雲端旅程中的位置， AWS 基礎可能已存在。這些 AWS 基礎包括下列項目：

  • AWS 區域 已識別。

  • 帳戶已建立或可隨需取得。

  • 已實作一般聯網。

  • 基礎 AWS 服務已部署在 帳戶內。

相反地，您可能在程序初期，而且尚未建立 AWS 基礎。缺乏已建立的基礎可能會限制應用程式設計的範圍，或需要進一步努力來定義它們。如果是這種情況，我們建議您在應用程式設計工作中平行定義和實作登陸區域的基礎設計。應用程式設計有助於識別需求，例如 AWS 帳戶 結構、聯網、虛擬私有雲端 (VPCs)、無類別網域間路由 (CIDR) 範圍、共用服務、安全性和雲端操作。

AWS Control Tower 提供最簡單的方法來設定和管理稱為登陸區域的安全多帳戶 AWS 環境。 會使用 AWS Control Tower 建立您的登陸區域 AWS Organizations，在數千位客戶遷移至雲端時，提供持續的帳戶管理和控管，以及實作 AWS 最佳實務型體驗。

應用程式未來狀態

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

請注意，指定應用程式的遷移策略可能不是唯一的。這是因為多個 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

修補和遠端存取

維護

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 Elastic Disaster Recovery

識別元件之後，請使用您偏好的工具在圖表中繪製它們。與主要應用程式利益相關者共用初始設計，包括應用程式擁有者、企業架構師，以及平台和遷移團隊。請考慮詢問下列問題：

  • 團隊是否通常同意設計？

  • 營運團隊可以提供支援嗎？

  • 設計可以進化嗎？

  • 還有其他選項嗎？

  • 設計是否符合架構標準和安全政策？

  • 是否有任何元件遺失 （例如，程式碼儲存庫、CI/CD 工具、VPC 端點）？

架構決策

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

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

軟體生命週期環境

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

標記

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

遷移策略

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

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

如需判斷 6 個 R 的詳細資訊，請參閱AWS Migration Hub 策略建議。

遷移模式和工具

透過應用程式和基礎設施元件的定義遷移策略，您現在可以探索特定的技術模式。例如，可透過遷移工具實作重新託管策略，例如 AWS Application Migration Service。如果您不需要複寫狀態或資料，您可以使用 Amazon Machine Image (AMI) 和應用程式部署管道重新部署應用程式，以達到相同的結果。

同樣地，若要重建或重構 （重新建構） 應用程式，您可以使用 AWS App2Container、 AWS Database Migration Service (AWS DMS)、 AWS Schema Conversion Tool(AWS SCT)、 等工具AWS DataSync。對於容器化，您可以使用 Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Kubernetes Service (Amazon EKS) 或 AWS Fargate。重新購買時，您可以使用特定產品或軟體即服務 (SaaS) 解決方案的 AMIAWS Marketplace。

評估可用於實現目標的不同模式和選項。考慮優缺點，以及遷移操作準備程度。若要協助您進行分析，請使用下列問題：

  • 遷移團隊可以支援這些模式嗎？

  • 成本和利益之間的平衡是什麼？

  • 此應用程式、服務或元件是否可以移至受管服務？

  • 實作此模式的工作為何？

  • 是否有任何法規或合規政策阻止使用特定模式？

  • 是否可以重複使用此模式？ 建議使用可重複使用模式。不過，有時候只會使用一次模式。考慮在單次使用模式的工作量與替代可重複使用模式之間取得平衡。

AWS 方案指引包含各種遷移模式和技術。

服務管理和操作

建立遷移到 的應用程式設計時 AWS，請考慮操作準備程度。與您的應用程式和基礎設施團隊評估整備要求時，請考慮下列問題：

  • 他們準備好操作嗎？

  • 事件回應程序是否已定義？

  • 什麼是預期的服務水準協議 (SLA)？

  • 是否需要職責分離？

  • 不同的團隊準備好協調支援動作嗎？

  • 誰負責什麼？

切換考量

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

風險、假設、問題和相依性

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

預估執行成本

若要估算目標 AWS 架構的成本，請使用 AWS 定價計算器。新增您設計定義的基礎設施元件，並取得預估的執行成本。考量應用程式元件所需的軟體授權，以及尚未包含在您將使用 AWS 之服務中的授權。