AWS之迁移与传输服务
目录
一、迁移管理与规划类
二、应用程序迁移类
1. MGN的迁移范围（能替代的场景）
✅ 自动包含以下数据：
🔹 适用场景举例：
2. 仍需DMS或DataSync的场景（不可替代）
❌ DMS仍必要的情况：
❌ DataSync仍必要的情况：
3. 技术原理对比
MGN的数据迁移机制：
DMS/DataSync的迁移机制：
4. 决策流程图
5. 典型案例
案例1：仅用MGN
案例2：MGN+DMS
案例3：MGN+DataSync
总结
三、数据库迁移类
四、在线数据传输类
Datasync和Transfer Family区别
1. 协议与访问方式
2. 使用场景
3. 数据处理与元数据
4. 集成与架构
总结：如何选择？
五、离线数据传输类
关键区别总结
典型场景匹配
以下是AWS各迁移与传输服务的区别总结，从功能、适用场景、迁移对象等维度分类对比：
一、迁移管理与规划类
| 服务名称 | 功能特点 | 适用场景 |
| AWS Migration Hub | 集中跟踪迁移活动，统一管理多任务进度，提供迁移状态可视化。 | 企业级多项目迁移管理，需监控跨服务迁移进度（如同时迁移应用和数据库）。 |
| AWS Application Discovery Service | 自动发现本地应用及其依赖关系、资源配置，生成迁移清单。 | 迁移前的应用调研，梳理本地资产（如服务器、应用、网络拓扑），为迁移规划提供数据。 |
| Migration Evaluator（原TSO Logic） | 分析迁移的业务价值（成本节省、性能提升等），创建迁移业务案例。 | 决策阶段，评估“是否迁移”及“迁移ROI”，为管理层提供数据支持。 |
二、应用程序迁移类
| 服务名称 | 功能特点 | 适用场景 |
| AWS Application Migration Service (MGN) | 迁移物理/虚拟/云环境的应用到AWS，自动转换基础设施（如将VM转换为EC2实例），支持应用现代化（如优化架构）。 | 通用应用迁移（如企业ERP、Web应用），需跨基础设施迁移并改进应用性能。 |
| AWS Mainframe Modernization | 专门针对大型机（Mainframe）工作负载，迁移到AWS并现代化（如转换为云原生架构），支持大型机应用的迁移、操作和运行。 | 遗留大型机系统迁移（如银行核心系统、政府 legacy 系统），需处理大型机特定的兼容性和性能需求。 |
AWS Application Migration Service (MGN) 确实可以迁移服务器上的所有数据（包括自建数据库和挂载存储），但是否完全替代DMS或DataSync取决于具体场景。以下是关键分析：
1. MGN的迁移范围（能替代的场景）
✅ 自动包含以下数据：
-
自建数据库数据
-
如服务器内运行的MySQL/MongoDB/PostgreSQL实例的数据文件（
/var/lib/mysql等目录） -
效果：迁移后数据与原服务器完全一致，但数据库引擎和架构无变化
-
-
挂载存储数据
-
包括本地磁盘（如
/data）、网络挂载的NFS/SMB共享卷 -
效果：块级复制保留所有文件属性和权限
-
🔹 适用场景举例：
-
开发测试环境中的WordPress服务器（含MySQL）整体迁移
-
本地文件服务器（含NAS挂载）原样搬迁到EC2
2. 仍需DMS或DataSync的场景（不可替代）
❌ DMS仍必要的情况：
| 需求 | MGN局限性 | DMS解决方案 |
| 数据库引擎升级 | 只能原样迁移 | 支持Oracle→Aurora等转换 |
| 单机→高可用集群 | 迁移后仍是单点 | 可输出到RDS Multi-AZ部署 |
| 实时同步生产库 | 仅一次性迁移 | 支持持续CDC同步 |
❌ DataSync仍必要的情况：
| 需求 | MGN局限性 | DataSync解决方案 |
| 仅迁移部分目录 | 必须迁移整个服务器 | 可选择性同步/data/images等 |
| 源为独立存储设备 | 无法直接迁移SAN/NAS设备 | 支持NFS/SMB协议直连 |
| 跨云/混合云持续同步 | 仅支持AWS作为目标 | 支持双向同步 |