如何将本地服务器迁移到 AWS（简单运行手册）

介绍

本地到AWS的迁移失败的原因更多是由于规划缺口，而不是计算能力：不明确的切换目标、被忽视的依赖关系和匆忙的测试。本指南使整个过程易于遵循，同时保持操作性。您将定义成功的标准，准备一个最小的着陆区，运行AWS MGN测试启动，自信地切换，然后在工作负载上线后进行优化。

在迁移任何内容之前，您应该决定什么？

哪个迁移策略适合此服务器（AWS的“7 Rs”）？

失去时间的最快方式就是迁移错误的东西。在安装任何代理之前，决定服务器应采用哪种迁移策略，以免提升和转移一些应该被淘汰或替换的东西。实际上，许多团队开始时为了速度选择重新托管，然后在工作负载在AWS中稳定后再进行优化。

然而，这仅在服务器是一个良好的“现状”候选者并且在切换后不会立即产生昂贵的技术债务时有效。实际决策捷径：

• 重新托管： 在时间紧迫时快速行动，尽量减少变动。
• 重新平台化： 保留应用程序，但进行小调整以适应AWS。
• 重构： 将精力集中在对业务至关重要的差异化因素上。
• 重新购买： 替换为 软件即服务 而不是迁移服务器。
• 退休/保留： 删除未使用的系统或将受限工作负载保留在本地。

一个有用的内部检查点是询问工作负载是否具有“云未来”。如果服务器将来会被分解为托管服务或容器化，请现在记录下来，并将重新托管视为一个临时步骤，而不是永久设计。

RTO/RPO、停机窗口和回滚触发器是什么？

成功的切换是可衡量的。定义可接受的停机时间和数据丢失容忍度，然后写下强制回滚的条件。这保持了迁移的目标，并防止团队在切换窗口期间即兴发挥。它还帮助业务利益相关者签字，因为他们可以清楚地看到接受的风险。

定义和记录：

• 恢复时间目标： 最大可接受停机时间。
• RPO： 最大可接受数据丢失。
• 停机窗口： 当您被允许切换生产流量时。
• 回滚触发器： 特定故障条件（身份验证中断、交易失败、数据不匹配）。
• 切换机制： DNS翻转，负载均衡器切换，路由/防火墙更改。

为了保持回滚计划的现实性，请指定在切换期间每个行动的负责人。例如，一个人负责DNS更改，一个人负责应用程序验证，还有一个人根据上述触发条件负责“回滚决策”。

在AWS和本地环境中，您需要准备什么？

复制的连接性和防火墙基础知识

仅当源环境能够持续访问AWS时，复制才有效。最常见的障碍是严格的出口控制、代理和干扰出站HTTPS流量的TLS检查。请尽早验证连接性，并在初始复制和测试启动期间保持网络路径稳定。在许多环境中，复制并不是完全“被阻止”的；相反，间歇性的丢包或数据包检查导致的不稳定行为在后期很难诊断。

常见连接模式：

• 公共互联网出口（在允许的情况下最简单）
• 站点到站点 VPN（常用于私有连接）
• 直接连接（对于较大环境更可预测）

预飞行检查：

• 出站HTTPS在源网络中可靠地工作
• 代理行为已被理解并在迁移流程中进行了测试
• 安全团队批准迁移窗口所需的出口。

如果您的环境高度锁定，请在您的波计划中添加一个简短的“网络验证”步骤：从一个试点服务器验证端点，然后将该确切的规则集复制到波的其余部分。

最小化 AWS 登陆区检查清单

您不需要一个完美的着陆区来开始，但您确实需要一个不会在波动中改变的一致目标。保持构建简约但有意，以便测试反映切换后的样子。许多迁移问题来自“临时”网络捷径，这些捷径变得永久，因为没有人有时间在发布后重建它们。

最低着陆区元素：

• A VPC 和 子网 实例将启动（通常是单独的测试与生产）
• 安全组 与实际应用流程对齐（避免“现在开放，稍后修复”）
• 身份和访问管理 准备进行迁移操作和第二天的访问与工具
• 基础 标记 因此，在切换后，所有权和成本跟踪将变得清晰。

它还帮助尽早决定管理员将如何访问实例（堡垒， 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 最成功的方式是遵循可重复的运行手册：选择正确的迁移策略，验证依赖关系，安全复制，进行现实测试，并在有明确回滚触发的情况下切换。一旦生产环境稳定，重点转向第二天的操作：安全加固、备份验证、监控和资源优化。这将“迁移”转变为一个可靠、可控成本的平台。