大型移轉的內部部署考量

支援企業營運的內部部署基礎結構也必須為大型移轉做好準備。藉由準備目前的基礎結構，您可以協助減少大量移轉至企業作業和應用程式使用者的影響。

本節檢閱準備內部部署基礎結構以進行大型移轉時，應考慮的基礎結構、作業和安全性問題。當您回答本節中的問題時，這些決定將成為遷移原則，您根據中的說明記錄將您的決策記錄為大型移轉原則。

基礎架構考

你有考慮過嗎	描述	動作
您是否設計了內部部署 DNS 和路由器來支援往返目標的流量AWS帳戶？	因為伺服器和目標數量眾多AWS帳戶時，請務必確認已正確設定不同的網路元件，以支援移轉策略和規模。	檢閱路由表的設計，並確定路由之間有正確的路由AWS帳戶和內部部署資料中心。此外，請確保 DNS 服務器能夠支持來自內部部署服務器和 DNS 查詢AWS資源。
遷移團隊將如何存取內部部署和AWS環境？	移轉小組需要存取來源和目標伺服器以執行移轉活動，例如在來源伺服器上安裝複製代理程式，或解除安裝目標伺服器上的舊軟體。	檢閱現有的驗證和授權機制，並建立授予存取權的策略。您可以使用作用中目錄群組、IAM 角色和安全宣告標記語言 2.0 (SAML 2.0) 聯盟來允許單一登入AWS帳戶。我們建議您建立本機系統管理員使用者，以防 Active Directory 發生任何驗證問題。
目前網路組態中是否有任何已知的擁塞點會降低移轉期間的資料輸送量？	大型移轉需要大量頻寬，才能將資料從內部部署資料中心複寫到雲端。瞭解任何現有的擁塞點或限制可協助您更有效地規劃移轉。	與網路群組一起檢閱網路組態，以更好地瞭解從來源機器到目標的網路路徑AWS帳戶。識別潛在的擁塞點，例如移轉與生產工作負載之間共用的連線。

作業考量

你有考慮過嗎	描述	動作
您是否有任何預定的阻止日期，也稱為更改凍結，這可能會影響遷移？	移轉期間的變更凍結可能會使重要資源和時間遠離進行中的移轉專案。	與作業團隊一起複查變更管理流\ 'b5\ '7b，並在計劃切換視窗時考慮封鎖的日子。
您是否已預留移轉的變更天數？	變更管理流程可能很複雜，有些組織只允許在某些維護時段中進行變更。	根據您的變更管理程序，至少要提前五個浪潮排定變更。這有助於防止延誤
移轉範圍內的所有伺服器是否最近都已重新啟動？	系統變更或解除安裝的修補程式可能會在移轉期間造成問題，因此需要較長的切換時間或復原伺服器。最佳做法是確認伺服器最近已在目標端重新啟動，然後再進行移轉。	檢閱上次重新啟動伺服器的日期。如果伺服器在過去 90 天內未重新啟動，請在移轉伺服器之前排程重新啟動。
災難恢復和業務連續性計劃如何運作，並且這是否被納入到著陸區設計中？	災難復原和業務連續性計畫是符合應用程式復原時間目標 (RTO) 和復原點目標 (RPO) 的關鍵元件。您需要確保這些計劃適用於您的內部部署和AWS轉換期間的工作負載。	檢閱現有的災難復原和業務連續性計劃，並確保計劃符合您的目標AWS帳戶。如果沒有，請先設計新計劃，然後再將工作負載移至AWS 雲端。

安全考量

你有考慮過嗎	描述	動作
您是否已建立防火牆規則來支援大型移轉？	視組織中的程序而定，可能需要很長時間才能完成防火牆組態的變更請求。	與安全團隊一起檢閱現有的防火牆變更程序，並相應地設計大型移轉防火牆變更的策略。您可能需要為大型移轉專案設計自訂程序，或者您可能需要在專案的早期提交變更。建議您考慮使用AWS虛擬私有雲（VPC）作為數據中心的擴展，避免構建太複雜的防火牆規則，這可能會顯著延遲大規模遷移。
你有沒有在中設置活動目錄AWS環境?	活動目錄用於身份驗證和授權。您需要確定目標帳戶工作負載能夠連線到網域控制站以進行驗證和授權。您可以在目標 VPC 中新增新的網域控制站，也可以允許AWS連線至內部部署網域控制站的工作負載。	與您的安全性和基礎結構團隊一起檢閱作用中目錄設計。確保目標AWS帳戶具有連接到正確的域控制器。確保目標AWS子網路 CIDR 區塊位於正確的作用中目錄站台中，以便中的工作負載AWS能夠連接到最近的域控制器。
您是否確定了第三方連接和應用程序的相互依賴	協力廠商連線和應用程式相互依存性需要您修改防火牆規則、網路存取控制清單和安全性群組。	在與應用程式擁有者進行深入研討會期間，檢閱每個應用程式的外部相依性。根據第三方相依性需求，提交要求以修改防火牆規則和網路存取控制清單，並相應地變更安全性群組。
您的內部部署環境是否有任何額外的安全性工具來控制系統上執行的存取和程序，例如CyberArk?	您可能需要評估和更新這些安全工具，以允許遷移工具在AWS著陸區。	檢閱來源環境中的存取原則。如果存取原則中正在使用安全性工具，請確認該工具在AWS 雲端，然後確定移轉小組同時具有來源和目標環境的存取權。如果需要進行任何變更，請將這些步驟新增至您的移轉手冊。