1. 企业云迁移与现代化改造导论

企业上云并不是把服务器从机房搬到云上这么简单。真正决定成败的，是能否分清“迁移”和“现代化改造”这两件事，并理解它们各自解决什么业务问题。迁移（Migration）关注的是把现有工作负载以尽可能低的业务中断搬到 AWS，保持原有架构、操作系统、数据库引擎和运行方式基本不变，典型手段是重新托管（Rehost）或平台调整（Replatform）。现代化改造（Modernization）则是在迁移的同时或之后，改变应用的架构与交付方式，例如把单体拆分为微服务、把自建数据库换成 Amazon RDS 或 Aurora、把定时批处理改成事件驱动、把手工发布改成 CI/CD 流水线。二者不是二选一，而是同一旅程中节奏不同的两个阶段。

为什么企业要同时做这两件事？业务驱动因素通常来自四个方向。第一是成本与弹性：自建机房按峰值采购，平均利用率往往只有 15%～30%，上云后按需付费、按量伸缩，闲置成本显著下降。第二是敏捷与上市速度：新环境从“采购服务器等六周”变成“几分钟创建”，配合基础设施即代码，可以快速试错。第三是韧性与合规：多可用区部署、跨区域备份、托管服务自带的加密与审计能力，比自建更容易满足等保、行业监管要求。第四是创新：托管 AI/分析服务让团队不必先建大数据平台就能直接做数据产品。这些驱动因素决定了迁移优先级——通常先迁低风险、高收益的系统，再逐步改造核心业务。

支撑这一切的是 AWS 全球基础设施。截至当前，AWS 在全球运营着 30 多个地理区域（Region），每个区域由至少 3 个相互隔离的可用区（Availability Zone，AZ）组成，AZ 之间通过低延迟光纤互联，同一区域内多 AZ 部署可实现高可用。区域之外还有边缘站点（Edge Location）用于 CloudFront 内容分发，以及 Local Zones、Wavelength 等贴近终端或 5G 的部署形态。选择区域时要综合考虑：目标用户延迟、数据驻留与合规要求、可用服务清单、以及区域间价格差异。例如面向中国大陆用户且需满足数据本地化，通常选择宁夏或北京区域；面向东南亚用户可选新加坡区域。跨区域复制（如 S3 Cross-Region Replication）用于容灾，但要注意跨区域流量会产生费用。

MAP 框架把整个旅程分为四个阶段。评估阶段要回答“迁什么、为什么迁、先迁谁”，产出应用清单、依赖关系、TCO 对比和 6R 初判。动员阶段是容易被低估却最关键的一步：建立 Landing Zone（多账户结构、VPC 网络、集中日志、身份联邦、安全基线），准备迁移工具链（AWS Application Migration Service、Database Migration Service、Snowball 等），并选一个非核心系统做试点，验证流程和回滚方案。迁移与现代化阶段按批次执行，每批都包含切换窗口、数据同步、验证和回滚预案。运营优化阶段则通过 Cost Explorer、Trusted Advisor、CloudWatch 持续治理成本、性能和安全。

6R 策略是迁移决策的核心工具。Rehost（重新托管）改动最小、速度最快，适合大批量低价值系统；Replatform（平台调整）保留核心代码但替换托管组件，例如把自建 MySQL 换成 Amazon RDS，能快速获得备份、多 AZ 和自动补丁能力；Repurchase（重新采购）用 SaaS 替代自研，如把自建邮件系统换成 Amazon WorkMail；Refactor（重构）是真正的现代化，按云原生重写，收益最大但周期最长；Retire（淘汰）下线不再需要的系统；Retain（暂留）因合规或技术原因暂时保留本地。实际项目中，一个企业往往同时使用多种策略，例如 60% Rehost、25% Replatform、10% Refactor、5% Retire。