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作为目标	支持双向同步