使用 AWS MGN 规划和执行大规模迁移 - 波次设计与切换自动化
通过波次设计规划数百台规模的服务器迁移，介绍切换自动化脚本和迁移后的优化方法。
波次设计的思路
大规模迁移不是一次性迁移所有服务器，而是分为波次 (迁移批次) 分阶段执行。波次设计基于应用的依赖关系。Web 服务器、应用服务器、数据库服务器紧密耦合的应用包含在同一波次中同时切换。第一波次由低风险应用 (开发环境、内部工具) 组成，验证和改善迁移流程。后续波次迁移生产应用，最终波次迁移最关键的系统。使用 Migration Hub 的应用分组功能按应用单位打包服务器并分配到波次，防止依赖关系遗漏。每波次 10-25 台服务器为宜，便于管理和同时切换时的故障处理。
切换自动化
MGN 的启动后操作 (Post-launch actions) 是在切换后的 EC2 实例上自动执行脚本的功能。与 Systems Manager Run Command 集成，可自动化 DNS 记录更新、监控代理安装、应用配置变更和健康检查执行。通过应用模板标准化迁移目标的 EC2 设置 (实例类型、子网、安全组、IAM 角色、标签)，确保同一角色的服务器获得一致配置。测试启动和切换使用相同模板，消除测试环境与生产环境之间的配置差异。启动后操作的执行顺序通过优先级控制，可实现如先更新 DNS 再安装监控代理等依赖感知的排序。预先创建 Systems Manager 文档 (SSM Document) 可使复杂脚本幂等执行。
迁移后的优化
迁移后初期以与本地相同规格的 EC2 实例运行，确认稳定性。积累 2-4 周运行数据后，根据 AWS Compute Optimizer 的建议调整实例类型。本地环境中许多服务器以富余规格运行，通过调整可期望 30-50% 的成本削减。Graviton (Arm 架构) 实例可在保持同等性能的同时降低约 40% 的成本。迁移后优化不是一次性工作，需建立定期审查 Compute Optimizer 建议并持续优化成本的流程。Savings Plans 或预留实例应在迁移完成后的稳定期应用，避免在迁移进行中做出长期承诺。
MGN 的费用
MGN 本身免费使用。成本由复制用 EC2 实例 (自动创建轻量的 t3.small)、EBS 卷 (复制数据存储)、测试实例和切换实例的 EC2 费用构成。复制期间持续产生成本，因此缩短迁移周期是成本优化的关键。测试实例验证完成后应及时终止，切换后停止源服务器的复制。数据传输费用方面，从源服务器到 AWS 的复制通信 (入站) 免费，但源服务器在本地时需注意互联网线路或 Direct Connect 的带宽成本。
迁移前评估与工具选择
大规模迁移前，使用 Migration Hub Discovery 工具或 Application Discovery Service 自动收集本地环境的服务器配置、依赖关系和使用率。将收集的数据输入 Migration Hub Strategy Recommendations，判定每台服务器的迁移策略 (Rehost / Replatform / Refactor)。MGN 针对直接迁移 (Rehost) 优化，在不修改 OS 或应用的情况下以块级别复制磁盘。数据库迁移配合使用 DMS (Database Migration Service)，应用服务器用 MGN、数据库用 DMS 是常见的分工模式。VMware 环境较多时，MGN 的无代理复制 (vCenter 连接器) 也是选择之一，省去在每台服务器上安装代理的工作。
切换时的风险缓解
为最小化切换停机时间，MGN 的持续复制执行块级差异同步，最终同步仅传输变更的块。实际每台服务器的切换时间为数分钟到十几分钟，取决于差异数据量而非磁盘大小。回滚计划方面，不关闭源服务器而保持待机状态，事前将 DNS TTL 缩短至 5 分钟以下，问题发生时可立即恢复到原服务器。推荐两阶段流程：先执行测试启动验证所有波次的动作，确认测试结果后再进行切换。迁移到多个区域时，设计波次配置顺序以确保区域间延迟不影响应用间通信。
总结
大规模迁移的成功关键在于通过波次设计分阶段执行、通过启动后操作自动化切换、以及迁移后通过 Compute Optimizer 进行优化。结合 MGN 和 Migration Hub 统一管理数百台规模的迁移，在最小化风险的同时高效完成迁移。将迁移前的 Discovery 评估与切换时的回滚计划相结合，控制整个迁移项目的风险。