1. 迁移与现代化改造总览

当企业决定把工作负载放到 AWS 上时，真正的挑战往往不是“能不能上云”，而是“以什么方式上云、上云之后变成什么样”。AWS 把这条路径拆成两个既独立又相互衔接的动作：迁移（Migration）解决“把现有系统搬到云上并保持可用”，现代化改造（Modernization）解决“搬上去之后如何用云的能力把它变得更好”。二者不是先后割裂的两件事，而是一条连续演进曲线上的不同区段。

迁移的核心目标是可运行、可回退、成本可控。它关注的是把服务器、数据库、存储、网络、身份与依赖关系完整地映射到 AWS 的对应服务上，并保证业务连续性。现代化改造的核心目标则是可弹性、可观测、可迭代、单位成本更优，它关注的是把单体拆成服务、把固定容量换成按需容量、把手工运维换成自动化流水线、把关系型强耦合换成更合适的托管数据服务。

业务驱动与技术维度

推动迁移与现代化的业务驱动通常有四类：数据中心租约到期或硬件生命周期结束带来的成本与合规压力；业务增长要求系统具备弹性与全球覆盖能力；产品迭代速度要求更短的发布周期；以及安全与韧性要求更细粒度的隔离和更快的恢复。这些驱动决定了迁移策略的选择——如果只是机房退租，Rehost（重新托管）可能就足够；如果要支撑快速增长的新业务，Refactor（重构）或 Replatform（平台重构）才更匹配。

从技术维度看，一次完整的迁移与现代化改造至少涉及六个层面：计算（EC2、容器、Lambda）、存储（S3、EBS、EFS）、数据库（RDS、Aurora、DynamoDB）、网络（VPC、子网、路由、安全组、负载均衡）、身份与安全（IAM、KMS、GuardDuty）、运维与交付（CloudWatch、CloudFormation、CodePipeline）。这六个层面在迁移阶段需要“对齐”，在现代化阶段需要“重构”。

整体方法论：从评估到持续优化

AWS 推荐的迁移方法论可以概括为四个阶段：评估（Assess）→ mobilize（动员）→ 迁移与现代化（Migrate & Modernize）→ 运营与优化（Operate & Optimize）。评估阶段要完成应用发现、依赖梳理、TCO 对比和迁移策略选择；动员阶段要建立 Landing Zone、网络基线、安全基线和迁移团队；迁移与现代化阶段按批次执行，每批都包含迁移、验证、切换和回退预案；运营与优化阶段则通过成本、性能、安全、可持续性四个维度持续调优。

其中最关键的是迁移策略的 6R 选择：Rehost、Replatform、Repurchase、Refactor、Retire、Retain。选择依据不是技术偏好，而是业务价值、改造成本、时间窗口和风险容忍度的综合权衡。例如，一个内部报表系统如果三个月后就要下线，Retire 比 Refactor 更合理；一个核心交易系统如果停机窗口只有 4 小时，Rehost 加后续 Replatform 往往比一次性 Refactor 更稳妥。

课程路线图与学习路径

本课程共 30 章，按“认知 → 评估 → 迁移 → 现代化 → 运营”的主线组织。前几章建立迁移与现代化的整体认知框架，包括 6R 策略、Landing Zone 概念和迁移方法论；中间章节深入具体技术域，覆盖计算、存储、数据库、网络、安全与身份、运维交付的迁移与改造实践；后续章节聚焦现代化改造的典型模式，如容器化、无服务器化、数据服务替换和 CI/CD 流水线重构；最后几章回到运营与优化，讨论成本治理、性能调优、安全加固和持续演进。

学习时建议始终带着一个真实或假想的应用系统作为“贯穿案例”。每学完一个技术域，就回到这个案例上问三个问题：这个组件在迁移阶段如何映射到 AWS 服务？在现代化阶段可以替换成什么？替换后的收益和代价分别是什么？这样能把分散的知识点串成一条可执行的迁移与改造路径。