使用 AWS Application Migration Service（MGN）进行直接迁移的实践
以实践的方式介绍从代理安装到切换的直接迁移步骤。同时解说设计上的注意事项和网络配置。
MGN 的机制与优势
AWS Application Migration Service（MGN）是用于将本地或其他云的服务器直接迁移到 AWS 的服务。自 2026 年 6 月 8 日起，该服务以 AWS Transform MGN 的名称提供。在源服务器上安装轻量的复制代理后，会以块级别将磁盘内容实时持续复制到 AWS。由于复制期间源服务器照常运行，迁移造成的停机时间仅限于切换时的几分钟。以往的 Server Migration Service（SMS）采用基于快照的定期同步，而 MGN 通过持续复制使 RPO 接近于零。
迁移步骤 - 从代理安装到切换
迁移分 4 个阶段进行。第 1 阶段是安装代理。在源服务器上安装 AWS Replication Agent 后，服务器会显示在 MGN 控制台中，并开始初始同步。第 2 阶段是配置启动设置。在启动模板中定义实例类型、VPC、子网、安全组和 IAM 角色。第 3 阶段是测试启动。启动用于测试的 EC2 实例，验证应用程序的运行、网络连接和性能。如果有问题，可以修改启动设置后重新测试。第 4 阶段是切换。执行最终的数据同步，并启动用于生产的 EC2 实例。通过切换 DNS 或更改负载均衡器的设置，将流量引向新环境。
设计上的注意事项
复制需要从源服务器到 AWS 的稳定网络连接。作为带宽的参考，要在 24 小时以内完成 100 GB 磁盘的初始同步，大约需要 10 Mbps。建议通过 Direct Connect 或 VPN 进行连接。用于复制的暂存区中会自动创建轻量的 EC2 实例（t3.small 左右）和 EBS 卷。这部分成本为每台源服务器每月几美元左右。在大规模迁移中，如果已经在使用 Migration Hub（自 2025 年 11 月 7 日起停止接受新客户），可以集中管理迁移进度。在这种情况下，还可以按应用程序对服务器分组，并同时切换存在依赖关系的服务器。
MGN 的费用
MGN 本身免费使用，安装复制代理和持续复制不会产生额外费用。成本是用于复制的暂存区（轻量的 EC2 实例和 EBS 卷）的费用。启动测试实例时会按目标规格产生 EC2 费用，因此测试完成后立即终止。切换后停止复制并删除暂存区的资源，以消除不必要的成本。
直接迁移这一策略
直接迁移是不对服务器进行大幅改造、几乎原样迁移到云端的迁移策略。由于不涉及应用程序的修改，能够控制迁移的风险和周期，成为最快到达云端的手段。在数据中心合同即将到期、希望先可靠地迁移到云端等情况下有效。向云原生的改造可以在迁移完成并稳定之后分阶段推进。不是从一开始就追求完美的优化，而是优先迁移、之后再改进，这种思路使现实的迁移成为可能。
通过测试启动进行验证
MGN 的一大优势是能够在切换生产环境之前，在迁移目标处验证运行情况。从复制的数据启动用于测试的实例，确认应用程序是否在 AWS 上正常运行。由于这项验证可以在不影响源服务器的情况下进行，因此可以在不中断业务的情况下反复测试。通过实际运行来确认网络连接、与依赖系统的集成、性能等。在生产切换之前充分反复测试，能够防止切换当天出现意外故障，并有信心地进行切换。
切换与回滚
向生产环境的切换（cutover）是迁移的关键时刻。由于 MGN 持续复制源数据，可以从同步到切换前一刻的状态进行迁移，并缩短停机时间。切换的时机选择对业务影响小的时间段。切换后，迅速确认应用程序是否正常运行。为防万一出现问题，重要的是准备好能够恢复到原环境的步骤。通过有计划的切换和做好回退的准备，能够安全地完成迁移。
迁移后的现代化
通过直接迁移完成迁移后，以此为立足点逐步发挥云的优势。首先，根据实际使用情况调整实例大小，降低成本。接着，按优先顺序分阶段推进现代化，例如将数据库迁移到托管服务、将处理替换为容器或无服务器等。不是一次性改造全部，而是从效果大的部分着手，可以在控制风险的同时持续减少运维负担和费用。重要的是将迁移定位为优化的起点，而不是终点。
总结
MGN 作为直接迁移的标准工具，通过基于代理的持续复制实现停机时间最短的迁移。仅在源服务器上安装代理就会开始块级复制，并通过启动测试实例执行迁移前的运行验证。切换时的停机时间通常为几分钟，也支持大规模的迁移项目。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。