1. 企业云迁移全景与AWS价值定位

企业上云从来不是“把服务器搬到云上”这么简单。它本质上是一次涉及组织、应用、数据、网络、安全与运维体系的系统性重构。理解迁移的全景，需要先回答三个问题：企业为什么要迁、AWS 用什么基础设施承接、以及迁移工程如何被组织成可交付的生命周期。本章围绕这三个问题建立后续 29 章的共同语言。

一、迁移驱动因素：从成本到业务敏捷

企业启动云迁移的驱动因素通常可以归为四类，且往往同时存在、互相强化。

• 财务驱动：将资本性支出（CapEx）转为运营性支出（OpEx），关闭自建机房、降低硬件折旧与闲置容量。典型场景是数据中心租约到期或硬件批量过保。
• 业务驱动：新产品需要快速上线、季节性流量需要弹性、需要进入新地域市场。云的区域化部署让“几周上线一个新市场”成为可能。
• 技术驱动：老旧中间件版本停止维护、单体应用难以扩展、需要引入容器、大数据、AI 等能力。云提供了托管服务，减少自建组件的运维负担。
• 合规与韧性驱动：需要满足数据驻留、等保、行业审计要求，或需要跨可用区、跨区域容灾能力，而自建双活成本极高。

需要强调的是，驱动因素决定了迁移策略的优先级。以成本为核心的项目会优先做资源盘点与右 sizing；以敏捷为核心的项目会优先做应用现代化与 CI/CD 改造。识别“第一驱动因素”是迁移立项阶段最重要的判断之一。

二、AWS 全球基础设施：迁移的物理底座

AWS 全球基础设施由区域（Region）、可用区（Availability Zone, AZ）、边缘站点（Edge Location）和本地区域（Local Zone）构成。理解这套层级，是设计迁移目标架构的前提。

• 区域：地理上独立的数据中心集群集合，例如 ap-northeast-1（东京）、ap-southeast-1（新加坡）。区域之间网络隔离，数据默认不跨区域流动，是数据驻留合规的边界。
• 可用区：同一区域内相互隔离的多个物理数据中心，通过低延迟专线互联。生产系统通常跨 2～3 个 AZ 部署，实现单 AZ 故障不影响业务。
• 边缘站点：用于 CloudFront 内容分发、Route 53 解析等，靠近终端用户，降低访问延迟。
• 本地区域：将计算和存储下沉到更靠近特定城市的位置，适合对延迟极敏感的场景。

迁移选区的核心判断维度包括：目标用户延迟、数据合规要求、目标服务在该区域是否可用、以及区域间网络成本。例如面向中国大陆用户且需低延迟的业务，常选择新加坡或东京区域，并通过 CloudFront 加速静态内容。

三、企业级迁移框架：AWS 迁移加速计划（MAP）

AWS 官方推荐的企业级迁移框架是 Migration Acceleration Program（MAP），其核心方法论分为三个阶段：评估（Assess）、动员（Mobilize）、迁移与现代化（Migrate & Modernize）。

• 评估阶段：完成现状调研、应用组合分析、总拥有成本（TCO）对比、迁移就绪度评估。产出物包括应用清单、依赖关系图、迁移优先级矩阵和商业论证。
• 动员阶段：建立 Landing Zone（着陆区），包括多账户结构、网络拓扑、身份与权限、日志与安全基线。同时选定试点应用，验证迁移工具链与流程。
• 迁移与现代化阶段：按批次执行迁移，每批次包含迁移、验证、割接、回退预案。迁移完成后进入现代化阶段，如容器化、数据库托管化、Serverless 改造。

与 MAP 配套的还有 6R 迁移策略：Rehost（重新托管）、Replatform（平台重构）、Repurchase（重新采购）、Refactor（重构）、Retire（退役）、Retain（保留）。6R 不是非此即彼的选择，而是对每个应用单独判断的结果。例如核心交易系统可能选择 Replatform 迁移到 RDS，而边缘报表系统直接 Retire。

四、工程交付生命周期：从立项到运营

迁移工程交付生命周期可以概括为七个阶段，每个阶段都有明确的输入、输出与判断依据。

需要特别注意的是，Landing Zone 是批量迁移的前置条件。没有统一的账户结构、网络互联、身份权限和日志审计，批量迁移会陷入“每迁一个应用就重新搭一套环境”的困境。典型的 Landing Zone 采用多账户架构：管理账户、日志归档账户、安全账户、共享服务账户、生产账户、非生产账户分离，通过 AWS Organizations 和 Control Tower 统一治理。