本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 平台基礎
本節著重於評估現場部署基礎設施的準備程度、準備 AWS 登陸區域或檢閱現有的登陸區域設計，以及識別所需的遷移工具。您可以檢閱建置平台時應考慮的常見基礎設施、操作和安全問題。您可以將答案和決策記錄為遷移原則。因此，您擁有一個堅固的平台，以實現大型遷移所需的擴展和速度。
本節包含下列主題：
+ [大型遷移的登陸區域考量](landing-zone.md)
+ [大型遷移的內部部署考量事項](on-premises.md)
+ [記錄遷移原則](document.md)
# 大型遷移的登陸區域考量事項
*登陸區域*是架構良好的 AWS 環境，可擴展且安全。透過為登陸區域建立標準，例如定義帳戶數量和設計子網路和安全群組，您可以建立穩固的基礎。此基礎可讓您啟用、佈建和操作您的環境，以大規模實現業務敏捷性和治理，同時加速雲端採用之旅。如需有關登陸區域和建置它們之策略的詳細資訊，請參閱[設定安全且可擴展的多帳戶 AWS 環境](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/)。
除了登陸區域策略的標準業務、營運、安全和合規考量之外，您還必須考慮如何促進大型遷移。您必須設計登陸區域，以便在遷移期間和之後支援現有的現場部署工作負載，以防某些工作負載仍保留在現場部署中。本指南提供會影響遷移速度和整體遷移時間表的其他登陸區域考量。
一般而言，登陸區域的設計和部署是為了支援 中的新工作負載 AWS 雲端。這是因為組織在決定遷移大量現有應用程式 AWS 之前正在採用。這種方法的好處是在大型遷移 AWS 之前，組織在 中獲得寶貴的知識和技能，但也可能導致各種利益相關者之間的衝突。有些利益相關者可能想要在遷移期間現代化應用程式，因為他們想要利用雲端原生功能。不過，大型遷移的常見目標是達到最大遷移速度，並透過盡可能多的應用程式遷移來簡化轉換，而不需修改工作負載。然後，您可以在遷移完成後現代化這些應用程式。
可能會影響大型遷移計劃專案的登陸區域的一些關鍵因素包括：
+ 網路頻寬可用性和管理
+ 工作負載隔離和資源管理的帳戶策略
+ 遷移工作負載的安全和管理控制
本節會檢閱您在建置 AWS 登陸區域時應考慮的基礎設施、操作和安全問題。它還包含有關如何設計和部署登陸區域以支援大型遷移專案的建議。當您回答本節中的問題時，這些決策會成為遷移原則，而這些[原則是根據文件中所述的指示記錄，做為大型遷移原則](document.md)。
## 基礎架構考量因素
| 您考慮過嗎？ | 描述 | 動作 |
| --- | --- | --- |
| 您將每天和每週遷移多少資料？ | 所需的遷移速度決定了網路連線的類型和網路輸送量需求。這也可能會影響波規劃選擇條件。 | 完成產品組合評估後，請判斷雲端中所有遷移資源所需的總儲存量。使用此值計算使用目前網路頻寬遷移資料所需的時間量。您可能需要增加頻寬以符合遷移時間範圍，或者您可能需要使用替代方法，例如 AWS Snow Family 解決方案。在[基礎手冊範本](samples/foundation-playbook-templates.zip)中，您可以使用*資料複寫計算器 *(Microsoft Excel 格式） 來計算每個遷移波所需的頻寬。 |
| 每波來源伺服器的平均寫入速度是多少？ | 傳輸複寫資料所需的頻寬取決於參與來源伺服器的寫入速度。伺服器複寫所需的頻寬量是來源伺服器的平均寫入速度乘以最大波中的伺服器數量。 | 在產品組合評估期間，您需要判斷每個伺服器每個伺服器執行的平均資料寫入次數。在[基礎手冊範本](samples/foundation-playbook-templates.zip)中，您可以使用*資料複寫計算器 *(Microsoft Excel 格式） 來了解遷移流量所需的頻寬。遷移流量所需的頻寬是附加於正常商業活動所使用的頻寬。遷移完成後，您不再需要額外的頻寬來支援遷移活動。 |
| 其他網路活動或現有基礎設施是否可以限制或降低複寫速度？ | 如果網路頻寬也支援其他業務函數，這些活動可以減少遷移期間用於複寫伺服器的可用頻寬量。 | 在專案生命週期的早期， 會仔細評估和計算支援所有商業活動所需的網路頻寬。考慮正常商業活動、伺服器複寫和新的遷移相關活動所需的頻寬，例如將內部部署檔案共用與 上的資料同步 AWS。 供應商可能需要較長的前置時間來增加網路容量，而且您可能需要升級現有的內部部署基礎設施。考慮升級網路基礎設施是否需要任何額外的升級。在專案早期評估頻寬需求，可讓您有時間進行任何必要的變更。 |
| 您目前的 AWS 子網路策略是否符合遷移內部部署工作負載的 IP 定址要求？ | 伺服器和工作負載隔離要求的數量會決定登陸區域的子網路策略。 大型遷移可能需要比您預期更大的子網路。在大型遷移中，您會將工作負載分組在與內部部署基礎設施中設定類似的子網路中。為了簡化遷移，一開始會偏好更大、更平坦的子網路設計，然後在現代化期間視需要重新設計子網路。 | 當產品組合評估擁有有關基礎設施庫存的足夠資訊時，請評估內部部署網路結構，並儘早將其納入登陸區域設計中。 |
| 您打算平行複寫和遷移多少個伺服器？ | 最大遷移波的大小會影響子網路需求[AWS 和服務配額](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)。 | 檢閱高階遷移計劃，並使用它來設計子網路。例如，如果您計劃將 200 個伺服器遷移到一個子網路，則該子網路的無類別網域間路由 (CIDR) 範圍應有足夠的 IP 地址，以支援目標數量的伺服器。此外，視需要增加每個目標帳戶的 AWS 服務配額。 |
| 您是否已識別遷移資源的安全群組策略？ | 安全群組用於管理 AWS 資源的傳入和傳出流量。請務必儘早設計安全群組，以避免延遲遷移。 | 在應用程式的優先順序手冊中，檢閱遷移策略，然後根據遷移策略設計安全群組。例如，如果遷移策略是重新託管大部分工作負載，請考慮支援遷移切換的臨時通用安全群組，而不是重新建構網路並套用應用程式特定的安全群組。 |
| 是否有使用中的負載平衡器？ | 一般而言，在具有負載平衡器的環境中遷移伺服器時，您需要評估負載平衡器的組態，然後遷移負載平衡器。負載平衡器的遷移選項包括使用 Elastic Load Balancing (ELB) 或合作夥伴以設備為基礎的解決方案。 | 負載平衡器的評估需要在探索階段提早開始，以便考慮任何自訂組態。在大多數環境中，負載平衡器組態都是相當標準的，但有些可能具有複雜的邏輯，可決定您可以遷移至 ELB 還是以合作夥伴設備為基礎的解決方案。 |
| 是否有任何伺服器需要保留其來源 IP 地址？ | 將伺服器遷移至雲端最安全且最簡單的方法是將新的 IP 地址配置給遷移的執行個體。在某些情況下，您可能需要保留與來源伺服器相同的 IP 地址。例如，舊版應用程式可能有一個硬式編碼 IP 地址，沒有人知道如何變更。 | 保留來源 IP 地址會影響您在波動規劃時如何形成移動群組。最常見的方法是將整個子網路遷移至單一移動群組 AWS 中的 ，因為這會使路由和切換在網路層級變得直接。 以下是保留 IP 地址的關鍵動作： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-foundation-playbook/landing-zone.html) |
| 來源和 之間可接受多少延遲 AWS？ | 使用 VPN 連結啟動遷移很常見，因為可以快速設定，然後轉換到使用 建立的直接連線 AWS Direct Connect。VPN 連結通常具有更高和更多的可變延遲，這會影響資料輸送量，更重要的是，影響應用程式回應時間。 | 如果您使用的是高或可變延遲連線類型，請檢閱每個應用程式的需求，並相應地規劃遷移波。計劃在替代連線類型可用時，將需要低延遲連線的應用程式置於較晚的波段中。 |
## 操作考量
| 您考慮過嗎？ | 描述 | 動作 |
| --- | --- | --- |
| 您是否已為您的登陸區域識別 AWS 帳戶策略？ | AWS 架構良好的環境最佳實務建議您將資源和工作負載分隔成多個 AWS 帳戶。您可以將 AWS 帳戶視為隔離的資源容器：它們提供工作負載分類，並可減少發生災難時的影響範圍。 | 在應用程式的優先順序執行手冊中，檢閱您選擇的遷移策略，並使用它們來判斷您的帳戶策略。例如，如果您想要盡快遷移，且重新託管是最常見的遷移策略，則較少的帳戶更容易管理。不過，如果您的遷移策略需要現代化應用程式，而且您需要基於合規原因而分開業務單位，您應該在帳戶策略中包含每個業務單位的一或多個帳戶。 |
| 您需要在遷移期間切換監控工具嗎？ 如果是，這是遷移程序的一部分，還是發生在遷移之前或之後？ | 監控工具對於雲端操作至關重要。由於相容性或授權原因，您現有的工具可能無法在雲端運作。在設計過程中，您需要決定要用於 中工作負載的監控工具 AWS 雲端。 | 在開始遷移之前，請選取監控工具。確定遷移團隊包含在遷移模式中設定監控的指示。我們建議您建置自動化指令碼，以視需要取代或重複使用監控工具。 |
| 您是否已識別應用程式擁有者，且他們是否知道應用程式必須進行任何變更，才能在雲端中正常運作？ | 大型遷移是一種轉型，而不只是基礎設施專案。儘早包含應用程式擁有者以支援遷移。例如，應用程式擁有者會驗證波動計畫、建立測試計畫，以及參與切換。 | 與專案管理辦公室和 Cloud Enablement Engine 團隊合作，以與應用程式團隊領導者保持一致，並確保所有應用程式團隊之間的溝通都清晰。如需通訊和專案透明度的詳細資訊，請參閱適用於[AWS 大型遷移的專案管理手冊](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-governance-playbook/)。 |
| 您是否已選取備份和復原解決方案，且其是否適用於遷移的工作負載？ | 備份和復原工具對於雲端操作至關重要。由於相容性或授權原因，您現有的工具可能無法在雲端運作。在設計過程中，您需要決定要針對 中的工作負載使用哪些備份和復原工具 AWS 雲端。 | 在開始遷移之前，請選取備份和復原工具。確定遷移團隊包含在遷移模式中設定備份和復原的指示。我們建議您建置自動化指令碼，以視需要取代或重複使用備份和復原工具。 |
| 您是否已識別所有共用服務，並將其部署在登陸區域？ | *共用服務*是支援多個應用程式的服務，例如電子郵件、Active Directory 或共用資料庫環境。您通常需要在遷移之前在雲端部署共用服務，以便遷移的應用程式如預期般執行。 | 在完成登陸區域設計之前，與基礎設施團隊和應用程式團隊領導者安排深入探索。在開始遷移之前，檢閱並確認您必須在雲端部署的共用服務清單。最常見的共享服務是 Active Directory、網路裝置、網域名稱系統 (DNS) 和基礎設施軟體。 |
| 您是否已檢閱目標 AWS 區域和帳戶 AWS 的服務配額？ | 每個 AWS 服務都有服務配額。其中一些配額可以增加。在切換之前檢閱配額很重要。如果可用資源不足，切換可能會失敗。 | 檢閱遷移計畫。對於任何需要增加服務配額的目標帳戶，請求增加。如需詳細資訊和說明，請參閱[AWS 服務配額](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)。 |
| 您需要升級 AWS 支援計劃嗎？ | AWS 企業支援計劃提供全年無休的電話支援，而且回應時間比其他計劃更快。由於切換時段通常非常短，因此能夠存取經驗豐富的工程師以協助解決切換問題對於大型遷移的成功至關重要。 | 請聯絡您的 AWS 客戶團隊，討論不同的支援選項，並為您的大型遷移專案選擇適當的支援計畫。 |
| 您是否已通知 AWS 技術客戶經理 (TAM) 有關大型遷移計劃？ | Enterprise AWS On-Ramp 支援團隊會指派技術客戶經理 (TAMs) 的集區，協調主動計劃、預防性計劃和 AWS 主題專家的存取。您的 TAMs可以視需要排程支援資源的可用性。 | 將即將進行的大型遷移專案通知您的 AWS 技術客戶經理，並分享您的遷移計劃。您的 TAMs將確保在需要時提供 AWS 支援資源。例如，您的 TAMs可以在切換期間排程支援工程師，而且工程師可以協助緩解技術問題並簡化切換。 |
## 安全考量
| 您是否考慮過？ | 描述 | 動作 |
| --- | --- | --- |
| 您是否已識別存取管理的 AWS Identity and Access Management (IAM) 角色和政策？ | 管理大型遷移專案所有成員的身分和存取權。透過將 IAM 角色連接到遷移的資源並定義存取政策，您可以控制誰可以存取雲端中的遷移資源。 | 與遷移團隊合作以識別角色和責任。判斷哪些角色可以存取哪個 AWS 帳戶，並識別每個角色的存取層級。與安全團隊合作，驗證每個目標 AWS 資源的 IAM 角色是否正確。 |
| 工作負載是否有任何合規要求？ | 工作負載可能有不同的合規要求，例如健康保險流通與責任法案 (HIPAA) 或支付卡產業資料安全標準 (PCI DSS)。您必須在遷移之前識別這些要求，並規劃如何滿足這些要求。 | 與合規團隊和產品組合團隊合作，識別每個應用程式的合規要求，並相應地設計您的目標 AWS 帳戶。例如，您可能需要將一些工作負載遷移 AWS GovCloud (US) 到或 AWS 特定區域。我們建議您記錄每個應用程式的合規要求，以便稍後在應用程式的優先順序和波規劃程序中使用此資訊。 |
| 您的安全團隊是否需要檢閱和核准您在遷移期間計劃使用的任何工具或服務？ | 大型遷移專案到 AWS 雲端 會使用許多服務，例如 AWS Application Migration Service， AWS Database Migration Service (AWS DMS) AWS DataSync和產品組合探索工具 （例如 Flexera One)。有些組織要求所有新工具和服務在使用前都經過核准。 | 與遷移團隊合作，識別您希望在遷移中使用的所有工具、服務和應用程式。與安全團隊合作，在遷移開始之前檢閱公司政策並相應地核准這些工具。 |
# 大型遷移的內部部署考量事項
支援您業務操作的現場部署基礎設施也必須準備好進行大型遷移。透過準備目前的基礎設施，您可以協助降低大型遷移對業務營運和應用程式使用者的影響。
本節會檢閱您在準備大型遷移的現場部署基礎設施時應考慮的基礎設施、操作和安全問題。當您回答本節中的問題時，這些決策會成為*遷移原則*，而這些[原則是根據文件中所述的指示記錄，做為大型遷移原則](document.md)。
## 基礎架構考量因素
| 您是否考慮過？ | 描述 | 動作 |
| --- | --- | --- |
| 您是否設計了內部部署 DNS 和路由器，以支援往返目標 AWS 帳戶的流量？ | 由於有大量的伺服器和目標 AWS 帳戶，請務必確認不同的網路元件已正確設定，以支援遷移策略和擴展。 | 檢閱路由表的設計，並確保 AWS 帳戶和內部部署資料中心之間有正確的路由。此外，請確定 DNS 伺服器能夠支援來自內部部署伺服器和資源的 AWS DNS 查詢。 |
| 遷移團隊將如何存取內部部署和 AWS 環境？ | 遷移團隊需要存取來源和目標伺服器來執行遷移活動，例如在來源伺服器上安裝複寫代理程式，或在目標伺服器上解除安裝舊軟體。 | 檢閱現有的身分驗證和授權機制，並建置策略來授予存取權。您可以使用 Active Directory 群組、IAM 角色和安全聲明標記語言 2.0 (SAML 2.0) 聯合，以允許單一登入 AWS 帳戶。如果 Active Directory 有任何身分驗證問題，建議您建立本機管理員使用者。 |
| 目前網路組態中是否有任何已知的擁塞點會在遷移期間降低資料輸送量？ | 大型遷移需要大量頻寬，才能將資料從內部部署資料中心複寫到雲端。了解任何現有的擁塞點或限制，可協助您更妥善地規劃遷移。 | 與網路團隊一起檢閱網路組態，以進一步了解從來源機器到目標 AWS 帳戶的網路路徑。識別潛在的擁塞點，例如遷移和生產工作負載之間共用的連線。 |
## 操作考量
| 您是否考慮過？ | 描述 | 動作 |
| --- | --- | --- |
| 您是否有任何排程的封鎖日，也稱為*變更凍結*，而可能影響遷移？ | 遷移期間的變更凍結可能會讓關鍵資源和時間離開進行中的遷移專案。 | 與營運團隊一起檢閱變更管理程序，並在規劃切換時段時考慮封鎖天數。 |
| 您是否已為遷移預留變更日？ | 變更管理程序可能很複雜，有些組織僅允許在特定維護時段進行變更。 | 根據您的變更管理程序，排程至少會提前五波變更。這有助於防止延遲 |
| 遷移範圍內的所有伺服器最近是否都重新啟動？ | 系統變更或解除安裝的修補程式可能會在遷移期間造成問題，這需要長的切換時段或復原伺服器。最佳實務是在遷移之前，確認伺服器最近已在目標端重新啟動。 | 檢閱上次伺服器重新啟動的日期。如果伺服器在過去 90 天內尚未重新啟動，請在遷移伺服器之前排程重新啟動。 |
| 災難復原和業務連續性計劃目前如何運作，這是否已納入登陸區域設計？ | 災難復原和業務連續性計劃是滿足應用程式復原時間目標 (RTO) 和復原點目標 (RPO) 的關鍵元件。您需要確保這些計劃在轉換期間適用於您的內部部署和 AWS 工作負載。 | 檢閱現有的災難復原和業務連續性計劃，並確保這些計劃適用於您的目標 AWS 帳戶。如果沒有，請在將工作負載移至 之前設計新的計劃 AWS 雲端。 |
## 安全考量
| 您是否考慮過？ | 描述 | 動作 |
| --- | --- | --- |
| 您是否已建立防火牆規則以支援大型遷移？ | 根據您組織中的程序，完成防火牆組態的變更請求可能需要很長的時間。 | 與安全團隊一起檢閱現有的防火牆變更程序，並據此設計大型遷移防火牆變更的策略。您可能需要為大型遷移專案設計自訂程序，或者您可能需要在專案早期提交變更。建議您考慮使用 AWS 虛擬私有雲端 (VPC) 做為資料中心的延伸，並避免建置過於複雜的防火牆規則，這可能會大幅延遲大型遷移。 |
| 您是否已在 AWS 環境中設定 Active Directory？ | Active Directory 用於身分驗證和授權。您需要確保目標帳戶工作負載能夠連線至網域控制器以進行身分驗證和授權。您可以在目標 VPC 中新增網域控制站，也可以允許 AWS 工作負載連線到現場部署網域控制站。 | 與您的安全和基礎設施團隊一起檢閱 Active Directory 設計。確定目標 AWS 帳戶已連線至正確的網域控制站。請確定目標 AWS 子網路 CIDR 區塊位於正確的 Active Directory 網站中，讓 中的工作負載 AWS 能夠連線到最近的網域控制站。 |
| 您是否已識別第三方連線和應用程式相互依存性？ | 第三方連線和應用程式相互依存性需要您修改防火牆規則、網路存取控制清單和安全群組。 | 在與應用程式擁有者的深入探討工作階段期間，檢閱每個應用程式的外部相依性。提交請求以修改防火牆規則和網路存取控制清單，並根據第三方相依性需求相應地變更安全群組。 |
| 您的內部部署環境是否有任何額外的安全工具，可控制系統上執行的存取和程序，例如 CyberArk？ | 您可能需要評估和更新這些安全工具，以允許遷移工具在 AWS 登陸區域中運作。 | 檢閱來源環境中的存取政策。如果存取政策中使用安全工具，請確認 中的工具功能 AWS 雲端，然後確認遷移團隊可以同時存取來源和目標環境。如果需要進行任何變更，請將這些步驟新增至遷移執行手冊。 |
# 記錄遷移原則
檢閱登陸區域和內部部署考量後，您應該記錄您的答案和決策。這些都是引導其他專案的遷移原則。
請執行下列操作：
1. 在[基礎手冊範本](samples/foundation-playbook-templates.zip)中，開啟*遷移原則範本* (Microsoft Word 格式）。
1. 檢閱本指南中[大型遷移的登陸區域考量](landing-zone.md)事項和[大型遷移的現場部署考量](on-premises.md)事項中的基礎設施、操作和安全考量事項，並與建議團隊討論這些問題。
1. 在遷移原則文件中記錄基礎設施、操作和安全性決策。如需如何記錄這些決策的範例，請參閱下表。
1. 視需要為您的使用案例新增新的類別、項目和原則。例如，您可能想要記錄產品組合評估或專案管理決策的遷移原則。
以下是如何記錄決策到本指南中一些問題的範例。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-foundation-playbook/document.html)