如何將本地伺服器遷移到 AWS（簡單運行手冊）

介紹

本地遷移到 AWS 的失敗率較低，主要是因為計算資源不足，而不是因為計劃上的缺口：不明確的切換目標、被忽視的依賴關係和匆忙的測試。本指南使過程易於遵循，同時保持運營。您將定義成功的標準，準備一個最小的登陸區，運行 AWS MGN 測試啟動，自信地進行切換，然後在上線後優化工作負載。

在遷移任何東西之前，您應該決定什麼？

這個伺服器適合哪種遷移策略（AWS 的“7 Rs”）？

失去時間的最快方法就是遷移錯誤的東西。在安裝任何代理之前，決定伺服器應該採用哪種遷移策略，以免提升和轉移應該被淘汰或替換的東西。實際上，許多團隊為了速度而開始進行重新托管，然後在工作負載在AWS中穩定後再進行優化。

然而，這僅在伺服器是良好的“現狀”候選者並且在切換後不會立即產生昂貴的技術負債時有效。實際的決策捷徑：

• 重新托管： 在時間緊迫時迅速行動，變化最小。
• 重新平台： 保留應用程式，但對 AWS 進行小調整。
• 重構： 將精力保留給業務關鍵的差異化因素。
• 重新購買： 替換為 軟體即服務 而不是遷移伺服器。
• 退休/保留： 移除未使用的系統或將受限的工作負載保留在本地。

一個有用的內部檢查點是詢問工作負載是否有“雲端未來”。如果伺服器將來會被分解為管理服務或容器化，請現在記錄下來，並將重新托管視為臨時步驟，而不是永久設計。

RTO/RPO、停機窗口和回滾觸發器是什麼？

成功的切換需要可衡量的成功。定義可接受的停機時間和數據丟失容忍度，然後寫下迫使回滾的條件。這保持了遷移的目標，並防止團隊在切換窗口期間即興發揮。這也有助於業務利益相關者簽字，因為他們可以清楚地看到接受了什麼風險。

定義和記錄：

• RTO： 最大可接受的停機時間。
• RPO： 最大可接受數據損失。
• 停機窗口： 當您被允許切換生產流量時。
• 回滾觸發器： 特定失敗條件（身份驗證中斷、交易失敗、數據不匹配）。
• 切換機制： DNS 翻轉、負載平衡器切換、路由/防火牆變更。

為了保持回滾計劃的現實性，請指定在切換期間每個行動的擁有者。例如，一個人負責 DNS 變更，一個人負責應用程序驗證，還有一個人根據上述觸發條件負責“回滾決策”。

在 AWS 和本地環境中，您需要準備什麼？

複製的連接性和防火牆基本知識

複製僅在源環境能夠穩定地連接到 AWS 時才有效。最常見的阻礙因素是嚴格的出口控制、代理伺服器和干擾出站 HTTPS 流量的 TLS 檢查。請及早驗證連接性，並在初始複製和測試啟動期間保持網路路徑穩定。在許多環境中，複製並不是完全“被阻止”的；相反，間歇性的掉線或封包檢查會導致不穩定的行為，這在後期很難診斷。

常見的連接模式：

• 公共互聯網出口（在允許的情況下最簡單）
• 站對站 VPN（常用於私人連接）
• 直接連接（對於較大的環境更可預測）

預檢查：

• 出站 HTTPS 在源網絡中可靠運作
• 代理行為已被理解並在遷移流程中進行測試
• 安全團隊批准遷移窗口所需的出口。

如果您的環境高度鎖定，請在您的波段計劃中添加一個簡短的“網絡驗證”步驟：從一個試點伺服器驗證端點，然後將該精確的規則集複製到其餘的波段中。

最小 AWS 登陸區檢查清單

您不需要一個完美的登陸區域來開始，但您需要一個不會在波浪中變化的一致目標。保持建設簡約但有意圖，以便測試能反映出切換的樣子。許多遷移問題來自於“臨時”的網絡捷徑，這些捷徑因為沒有人有時間在啟動後重建而變得永久。

最低著陸區域元素：

• A 虛擬私人雲 和 子網 實例將啟動的地方（通常是測試與生產分開）
• 安全群組 對齊實際應用流程（避免“現在開放，稍後修復”）
• 身份管理 準備好進行遷移操作和第二天的訪問及工具
• 基本 標籤 因此，在切換後，所有權和成本追蹤將變得清晰。

它還有助於及早決定管理員將如何訪問實例（堡壘， VPN ，SSM）以及如何提供外部網際網路訪問（NAT 閘道、代理）。這些選擇會影響修補、監控代理和第一天的故障排除。

來源伺服器準備檢查清單

乾淨的遷移取決於乾淨的來源。確認工作負載與您選擇的方法相容，然後識別任何依賴於在 AWS 中將會改變的本地假設的內容。這也是您標記可能需要不同順序的“特殊案例”伺服器的地方。例如，具有大量寫入活動的檔案伺服器可能需要更緊湊的切換窗口和對開放檔案及共享的更嚴格驗證。

準備檢查以防止意外：

• 操作系統/工作負載與遷移方法的相容性
• 足夠的磁碟和穩定的 I/O 以應對複製開銷
• 依賴項映射： DNS , AD/LDAP 內部 PKI/證書 ，資料庫，共享
• 隱藏的脆弱性：硬編碼的IP、舊版TLS、不常見的排程任務
• 特殊情況提前標記：域控制器、集群、設備、加密狗授權

在離開此步驟之前，捕捉“必須保持不變”的項目，例如主機名稱、IP 地址要求或證書綁定，因為這些直接影響您的 AWS 啟動設置和切換順序。

如何使用 AWS MGN 將伺服器遷移到 AWS？

初始化MGN並設置複製默認值

在伺服器運行的區域初始化 AWS MGN，然後定義複製默認值，以保持波執行的一致性。穩定的模板減少每台伺服器的變異性，並使故障排除可重複。將此視為您在複製過程中的標準操作程序，類似於虛擬化環境中的金色映像。

設定複製預設值：

• 目標子網策略和網絡佈局
• 啟動實例的安全組基準
• 儲存行為（卷映射， 加密 期望
• 複製節流以保護生產流量

如果您已經知道生產環境將需要與測試環境不同的設置，請明確定義這些差異。這樣，測試啟動仍然具有代表性，而不會過早暴露生產網絡。

安裝代理並完成初始同步

在源伺服器上安裝複製代理並確認其成功註冊。初始同步是您成本最高的不穩定時期，因此請避免不必要的更改並密切監控複製健康狀況。這也是團隊受益於記錄“已知良好”安裝流程的地方，以便他們不會在每一波中排除相同的問題。

操作指導：

• 在初始複製期間保持伺服器穩定（如果可能，避免重啟）
• 監控複製狀態並立即處理錯誤
• 記錄安裝方法，以便未來的波次保持一致

在初始同步期間，不僅要監控遷移控制台，還要監控伺服器性能。複製開銷可能會揭示先前在本地環境中被掩蓋的存儲瓶頸或磁碟錯誤。

啟動測試實例並驗證

測試啟動將假設轉化為證據。啟動測試實例，然後驗證應用程序的整體健康狀況，而不僅僅是啟動成功。使用檢查清單，以便在伺服器和波次之間的測試可重複。如果最終用戶將通過 TSplus 遠端存取 包括在驗證中進行訪問路徑檢查。一致性很重要，因為它使您能夠比較工作負載之間的結果並發現模式，例如影響多個伺服器的DNS解析問題。

最低驗證檢查清單：

• 啟動完成，服務正常啟動
• 應用程序煙霧測試通過關鍵工作流程
• 身份驗證工作 (AD/LDAP/本地)
• 數據路徑工作（數據庫連接、文件共享、集成）
• 排程工作和背景服務按預期運行
• 日誌和 監控信號 出現於您的運營團隊預期的位置

增加一個團隊經常忽略的步驟：驗證用戶實際如何訪問應用程序，包括內部路由、防火牆規則和任何上游系統。一台伺服器可以是“健康的”，但在實際操作中卻無法訪問。

啟動切換並完成

切換是一個受控的轉換，而不是一次盲目的嘗試。盡可能凍結變更，使用計劃的機制執行流量移動，然後使用與測試相同的檢查清單進行驗證。保持回滾所有權明確，以便快速做出決策。將此視為可重複的操作手冊：你即使少即興發揮，風險就越低。

切換執行要素：

• 確認變更凍結和通信計劃
• 啟動切換實例並切換流量（DNS/LB/路由）
• 重新執行驗證檢查清單，特別關注數據完整性
• 如有需要，應用回滾觸發器並乾淨地恢復流量
• 完成切換並移除或終止測試資源

立即切換後，捕捉生產環境中發生的變更（新的 IP、新的路由、新的安全組規則）並進行記錄。這是運營團隊在幾週後出現問題時所需的信息。

通常會出現什麼問題，以及切換後您應該立即做什麼？

網絡出口、DNS/AD 依賴性，以及「提升和轉移尚未完成」

大多數故障都是依賴性故障。複製往往在出口和代理約束上中斷，而應用程序行為則往往在身份、名稱解析和證書上中斷。即使切換成功，重新托管也僅是第一個里程碑，而不是最終狀態。如果沒有第二階段，您通常會得到“雲端托管的舊系統”，這樣的系統成本更高且更難操作。

最常見的斷點：

• 出站 HTTPS 被代理阻擋或更改 TLS 檢查
• DNS 解析變更（分割視野問題，缺失的解析器規則）
• VPC 的 AD/LDAP 可達性差距
• 內部 PKI 鏈在新環境中缺失或不受信任
• 硬編碼的端點和對本地網絡路徑的舊有假設

一個簡單的緩解方法是在試點啟動時及早測試身份和DNS。如果這些基本要素有效，則其餘的應用程序驗證將變得更加可預測。

後切換穩定性：安全性、備份、監控、成本

切換後的前48小時應優先考慮穩定性和控制。確保工作負載是可觀察的、可恢復的，並且在您花時間進行更深入的優化之前得到安全管理。這也是您的遷移在長期內成功的地方，因為良好的第二天操作可以防止“我們移動了它，但沒有人想擁有它”的結果。

立即切換後的行動：

• 確認監控/警報已啟用並擁有
• 確保已啟用備份並完成還原驗證
• 加強安全群組並應用最小權限 身份管理
• 標準化修補方法和管理訪問（可審計路徑）
• 在收集到實際使用數據後開始進行權限調整
• 強制標記以防止“未知擁有者”成本漂移

一旦穩定性得到證明，為每個遷移的伺服器安排一次簡短的優化檢討。即使是對存儲類型、實例系列選擇和保留容量策略的輕微檢查，也能顯著降低成本。

將伺服器移至 AWS 後，TSplus 的位置在哪裡？

在 AWS 上運行 Windows 工作負載後，許多團隊仍然需要一種簡單的方法，將 Windows 應用程序和桌面發佈給用戶，而無需構建繁重的 VDI 堆棧。 TSplus 遠端存取 提供應用程式發佈和遠端桌面存取，適用於AWS、內部部署或混合環境中的Windows伺服器，具備簡單的管理和可預測的授權，適合中小企業和中型市場運營。

結論

將本地伺服器遷移到 AWS 最成功的方式是遵循可重複的運行手冊：選擇正確的遷移策略，驗證依賴關係，安全地複製，現實地測試，並在有明確回滾觸發的情況下切換。一旦生產環境穩定，將重點轉向第二天的操作：安全加固、備份驗證、監控和資源調整。這將“移動”轉變為一個可靠、成本可控的平台。