AWS 计算服务迁移全攻略：从传统 IDC 到 EC2、Lambda、ECS 与 LightSail 的平滑过渡实战指南

引言：为什么需要关注云迁移？

2026 年，全球企业云迁移的浪潮已不再是"要不要上云"的问题，而是"怎么上云更稳、更快、更省钱"。据 Gartner 预测，到 2027 年全球超过 70% 的企业工作负载将运行在公有云上。然而，云迁移并非简单的"搬家"——不同业务形态对计算资源的需求千差万别，一刀切地把本地服务器全部扔上 EC2 往往是灾难的开始。

AWS 提供了五类核心计算服务——EC2（虚拟服务器）、Lambda（无服务器函数）、ECS/EKS（容器编排）、Auto Scaling（弹性伸缩） 和 LightSail（轻量云服务器）——每一种都对应着特定的迁移场景。本文将系统性地拆解从传统 IDC 或私有云向 AWS 五大计算服务迁移的完整策略，包括迁移评估、路径选择、数据同步、网络规划与生产切换，并提供可直接落地的决策框架。

---

一、迁移前置评估：三问决定计算模式

在动手迁移之前，必须对现有工作负载进行一次完整的三维评估。这决定了你的应用最终落在 EC2、Lambda、ECS 还是 LightSail 上。

1.1 评估维度一：应用架构类型

1.2 评估维度二：基础设施依赖

需要逐项梳理现有环境中的外部依赖，因为这些直接影响迁移策略：

• 数据库类型与版本：MySQL 5.7 可以直迁 RDS，但 Oracle RAC 可能需要 EC2 自行部署。
• 消息队列：本地 RabbitMQ 可迁移到 Amazon MQ（托管版），或改造为 SQS/SNS 以适配 Lambda。
• 存储方案：NFS 共享存储需改造为 EFS（兼容 NFSv4），对象存储迁移到 S3。
• CI/CD 流水线：Jenkins 可迁至 EC2 或迁移到 CodePipeline + CodeBuild 托管服务。

1.3 评估维度三：业务 SLA 与合规要求

合规方面：如果业务需要数据不出境、专有硬件（如 HSM 加密机），则应优先选择 EC2 裸金属实例而非共享租户的 Lambda 或 Fargate。

---

二、五大计算服务的迁移路径详解

2.1 迁向 EC2：传统"上云虚拟机"模式

适用场景：现有应用不需要架构改造、对操作系统有强依赖、使用 Windows Server 或商业软件许可证（BYOL）。

迁移工具链：

迁移七步法：

// Step 1: 在源服务器安装 AWS Replication Agent
wget https://aws-mgn-agent-us-east-1.s3.amazonaws.com/latest/linux/aws-mgn-agent.rpm
sudo rpm -ivh aws-mgn-agent.rpm

// Step 2: 在 AWS MGN 控制台配置复制设置
// 选择目标区域、实例类型、安全组、子网

// Step 3: 启动数据复制（全量 + 增量）
// 复制期间源服务器不受影响，持续运行

// Step 4: 在目标区域创建测试实例
// 验证应用功能、数据库连接、外部 API 可达性

// Step 5: 网络切换准备
// 更新 Route 53 DNS 权重路由，配置安全组规则

// Step 6: 执行最终切割
// 停止源服务器写入 → 完成增量同步 → 启动目标 EC2

// Step 7: 监控与回滚
// CloudWatch 告警就绪，保留源服务器 72 小时作为回退

关键注意事项：

• IP 地址变更：迁移后公网/私有 IP 都会改变，需要提前更新 DNS TTL 至 60 秒以加速切换。
• 许可证兼容性：Windows Server BYOL 需在 AWS 上使用 Dedicated Host（专用主机）以符合微软许可条款。
• 磁盘性能差异：本地 SSD 的 IOPS 可能远超 EBS gp3 默认值（3000 IOPS），需要提前通过 fio 工具实测并按需配置 EBS io2/io1 类型。

2.2 迁向 Lambda：无服务器化改造

适用场景：独立功能模块（图片处理、API 端点、定时任务）、事件驱动型架构、需要极致弹性的业务。

迁移策略：Strangler Fig Pattern（绞杀榕模式）

这是将单体应用中可拆分的功能逐一切换到 Lambda 的最安全方式：不一次性重写整个应用，而是在原有应用外围逐步用 Lambda 替换特定路由。

// 示例：将本地 Express.js 应用中的 /api/resize-image 端点迁移到 Lambda

import json
import boto3
from PIL import Image
import io

s3 = boto3.client('s3')

def lambda_handler(event, context):
    // 从 API Gateway 传入的请求中获取图片信息
    body = json.loads(event['body'])
    bucket = body['bucket']
    key = body['key']
    width = int(body.get('width', 800))
    height = int(body.get('height', 600))

    // 从 S3 下载原图
    obj = s3.get_object(Bucket=bucket, Key=key)
    img = Image.open(io.BytesIO(obj['Body'].read()))

    // 缩放
    img.thumbnail((width, height), Image.LANCZOS)

    // 上传到目标桶
    out_key = f"resized/{width}x{height}/{key}"
    buf = io.BytesIO()
    img.save(buf, format='JPEG', quality=85)
    buf.seek(0)
    s3.put_object(Bucket=bucket, Key=out_key, Body=buf, ContentType='image/jpeg')

    return {
        'statusCode': 200,
        'body': json.dumps({'url': f'https://{bucket}.s3.amazonaws.com/{out_key}'})
    }

Lambda 迁移三步检查清单：

冷启动优化速查：

// 不好的写法：每次调用都初始化 SDK 客户端（增加冷启动体积）
const AWS = require('aws-sdk');
exports.handler = async (event) => {
    const dynamodb = new AWS.DynamoDB.DocumentClient(); // 在 handler 内初始化
};

// 更好的写法：SDK 客户端放在全局作用域，利用执行环境复用
const AWS = require('aws-sdk');
const dynamodb = new AWS.DynamoDB.DocumentClient(); // 只初始化一次
exports.handler = async (event) => {
    // 直接使用已初始化的客户端
};

2.3 迁向 ECS/EKS：容器化改造

适用场景：已有 Docker 化应用、微服务架构、需要细粒度资源调度的团队。

容器化迁移四种策略：

传统 VM 应用
    │
    ├─→ 策略A: Lift & Shift（原样打包）
    │   将整个应用打成一个 Docker 镜像
    │   快速上云，但未利用容器优势
    │   适用于：快速验证、临时迁移
    │
    ├─→ 策略B: 分解式容器化
    │   拆分为 Web/API/Worker 三个独立容器
    │   独立扩缩，独立更新，故障隔离
    │   适用于：中期架构演进
    │
    ├─→ 策略C: 微服务化
    │   按业务域拆分为 10+ 个微服务容器
    │   每个拥有独立数据库/缓存
    │   适用于：长期架构目标
    │
    └─→ 策略D: 混合模式
        └─ 核心事务 → EC2（暂不改造）
        └─ 新功能   → ECS Fargate（容器化）
        └─ 事件处理 → Lambda（无服务化）

ECS 启动类型对比：

迁移踩坑实录：

• ENI 耗尽：awsvpc 模式下每个 ECS Task 占用一个独立弹性网卡（ENI）。如果子网 IP 池不足（如 /28 仅 11 个可用 IP），大规模部署瞬间耗尽 IP。解决方案：使用 /24 或更大子网，或切换到 EC2 launch type 的 bridge 模式。
• 日志膨胀：CloudWatch Logs 按 GB 计费，Java 应用如果保留了本地 DEBUG 日志级别，月费用可能超过计算本身。解决：awslogs 驱动配置 mode: non-blocking + max-buffer-size: 4m，并设置日志保留期。
• 镜像拉取延迟：中国区（北京/宁夏）从 Docker Hub 拉取镜像不稳定，建议使用 ECR + 镜像缓存，或提前将基础镜像推入 ECR。

2.4 迁向 Auto Scaling：从"固定容量"到"按需伸缩"

适用场景：流量波动大（电商大促、节假日、媒体热点）、需要成本精细化管理。

Auto Scaling 策略选型矩阵：

混合策略实战示例：

// 组合"计划伸缩" + "目标跟踪"实现电商首页架构：

// 底层：计划伸缩——每天 08:00-23:00 保持最小 4 台
// 中层：目标跟踪——CPU 目标 65%，自动在 4-20 台之间调整
// 顶层：步进伸缩——当请求队列深度 > 5000 时，紧急扩容 8 台

// CloudFormation 片段（目标跟踪策略）
Type: AWS::AutoScaling::ScalingPolicy
Properties:
  AutoScalingGroupName: !Ref WebASG
  PolicyType: TargetTrackingScaling
  TargetTrackingConfiguration:
    PredefinedMetricSpecification:
      PredefinedMetricType: ASGAverageCPUUtilization
    TargetValue: 65.0
    ScaleInCooldown: 300
    ScaleOutCooldown: 180

从固定容量迁移到 Auto Scaling 的四步法：

1. 基准采集：运行 CloudWatch 收集至少 14 天的 CPU、内存、请求量数据，确定峰值/谷值倍数。
2. 创建启动模板：将现有 EC2 导出为 AMI，基于 AMI 创建 Launch Template。
3. 灰度切换：创建 Auto Scaling Group（ASG），最小/期望/最大实例数 = 1/1/1，将一台实例移入 ASG 管理。观察 24 小时无异常。
4. 全量切换：将最小/期望/最大逐步扩大至目标值（如 2/4/20），移除旧的独立 EC2 实例。

2.5 迁向 LightSail：轻量级的"一键上云"

适用场景：个人开发者项目、中小型企业官网、WordPress 博客、轻量 API 服务器、开发测试环境。

LightSail 的本质：它是 EC2 的一个"封装套餐"，底层仍是 EC2 实例，但将计算、存储、网络和固定带宽打包成月费套餐，消除了按需计费的不可预测性。

从传统 VPS 迁移到 LightSail：

// 旧环境：某 VPS 商 $20/月，2 vCPU/4 GB RAM/80 GB SSD

// Step 1: 导出当前 VPS 的快照或网站文件
tar -czf /tmp/site-backup.tar.gz /var/www /etc/nginx /etc/mysql

// Step 2: 在 LightSail 控制台创建同规格实例（$20 套餐）
// 选择对应的应用镜像：WordPress / LAMP / Node.js / 仅操作系统

// Step 3: 上传备份文件并解压
scp /tmp/site-backup.tar.gz bitnami@LIGHTSAIL_IP:/tmp/
ssh bitnami@LIGHTSAIL_IP "sudo tar -xzf /tmp/site-backup.tar.gz -C /"

// Step 4: 配置静态 IP（LightSail 免费提供）
// 在控制台 → Networking → Attach static IP

// Step 5: DNS 切换（将 A 记录指向 LightSail 静态 IP）

LightSail 的局限性与升级路径：

---

三、迁移中的数据同步策略

数据同步是迁移中最容易引发事故的环节。不同数据规模需要不同的策略。

3.1 数据库迁移方法对比

3.2 DMS 持续同步实战

// 架构：本地 MySQL 5.7 → AWS DMS → RDS MySQL 8.0

// Step 1: 在本地 MySQL 开启 binlog（ROW 格式）
// my.cnf
[mysqld]
server-id = 1
log-bin = mysql-bin
binlog_format = ROW
binlog_row_image = FULL
expire_logs_days = 3

// Step 2: 创建 DMS 复制用户
CREATE USER 'dms_user'@'%' IDENTIFIED BY 'StrongPassword123!';
GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'dms_user'@'%';

// Step 3: 在 AWS DMS 控制台创建复制实例
// 实例类型：dms.c5.large 或以上（避免 CDC 延迟）

// Step 4: 创建源端点 + 目标端点
// 源端点 → 本地数据库公网 IP（或通过 VPN/Direct Connect）
// 目标端点 → RDS 终端节点

// Step 5: 创建迁移任务
// 迁移类型：Full load + CDC（Migrate existing data and replicate ongoing changes）
// 目标表准备模式：Do nothing（提前在 RDS 建好表结构）

// Step 6: 监控 CloudWatch 指标
// CDCLatencySource → 应保持 < 10 秒
// CDCLatencyTarget → 应保持 < 5 秒

// Step 7: 停机切换
// 停止应用写入 → 等待 CDCLatencySource = 0 → 修改应用数据库连接串 → 启动应用

---

四、网络规划：打通本地与云端的连接

4.1 三种互联方案对比

4.2 迁移期间的混合网络架构

┌──────────────────┐         VPN / DX          ┌─────────────────────────┐
│   本地数据中心     │◄─────────────────────────►│      AWS (ap-southeast-1) │
│                    │                           │                          │
│  ┌──────────┐     │                           │  ┌────────────────────┐  │
│  │ Web App  │─────┼─────── 读写 ──────────────►│  │  RDS（目标数据库）  │  │
│  └──────────┘     │                           │  └────────────────────┘  │
│       │           │                           │           ▲              │
│       ▼           │                           │           │              │
│  ┌──────────┐     │                           │  ┌────────┴───────────┐ │
│  │ 本地 MySQL│─────┼─────── DMS 同步 ─────────►│  │  EC2（已迁移应用）  │ │
│  └──────────┘     │                           │  └────────────────────┘ │
│                    │                           │                          │
└──────────────────┘                           └─────────────────────────┘

迁移策略：
第1周：Web 应用仍跑在本地，通过 VPN 读写 AWS RDS → 验证延迟可接受
第2周：创建只读副本，将读流量切至 AWS → 减轻本地负载
第3周：在 AWS 启动 EC2 实例运行应用副本，灰度 10% 流量到 AWS
第4周：确认稳定后，完全下线本地服务器

---

五、生产切换：零停机迁移的 Golden Path

5.1 流量切换技术选型

5.2 Route 53 权重路由灰度切换步骤

// 假设：example.com 已经切换至 AWS Route 53 托管

// Step 1: 创建两条 A 记录（别名或 IP）
// 记录A：example.com → 本地负载均衡器公网 IP（权重 90）
// 记录B：example.com → AWS ALB DNS（权重 10）
// TTL：60 秒

// Step 2: 监控 30 分钟，确认 AWS 端无异常
// CloudWatch 指标关注：5xx 错误率、平均响应时间、CPU 使用率

// Step 3: 逐步调整权重
// 30 分钟后：权重 70/30
// 60 分钟后：权重 50/50
// 90 分钟后：权重 20/80
// 120 分钟后：权重 0/100

// Step 4: 观察 24 小时后，删除本地记录A

5.3 切换到 Auto Scaling 的"热迁移"模式

如果目标是让应用运行在 Auto Scaling Group 中，推荐以下过渡路径：

当前状态：5 台独立 EC2（手动管理）
目标状态：ASG 管理 4~20 台实例（自动伸缩）

过渡步骤：
Day 1: 基于某台运行中 EC2 创建 AMI
Day 2: 创建 Launch Template（引用 AMI）+ 创建 ASG（min/desired/max = 1/2/2）
Day 3: 将 ASG 实例加入 ALB 目标组，权重 20%
Day 4: 观察无异常 → 权重调至 100%
Day 5: 终止原有 5 台独立 EC2 → ASG min/desired/max 调整至 4/4/20
Day 6: 配置目标跟踪策略（CPU 65%）+ 计划策略（夜间缩至 2 台）

---

六、成本优化：迁移后的降本清单

迁移完成后，很多团队忽略了"迁后优化"这一关键环节。以下是一个快速降本检查清单：

一个典型的降本案例：

某电商团队从本地 IDC（月均 $8,000）迁移至 AWS 后，初始月账单 $6,200。运行两周后运行 Compute Optimizer，发现 12 台 m5.xlarge 实例的平均 CPU 仅 18%，将其中的 8 台替换为 m5.large，1 年 Savings Plan 加上 20% 的预留折扣，最终月成本降至 $3,400——较本地节省 57.5%。

---

七、总结与建议

迁移到 AWS 五大计算服务不是一次性的技术工程，而是一个持续优化的演进过程。以下是最核心的三条建议：

1. 不要试图一次搬完：采用 Strangler Fig 模式，先迁移低风险模块，积累经验后再处理核心系统。LightSail 可以作为快速验证的"前哨站"。

1. 数据同步是成败关键：数据库迁移使用 DMS + CDC 持续同步，文件存储使用 S3 + DataSync，确保 RPO（恢复点目标）趋近于零。

1. 迁后优化不能省：迁移完成只是开始，Savings Plans、右尺寸、Auto Scaling 策略微调才是云成本优势的真正体现。一个"照搬 IDC 配置"的 AWS 账单往往比 IDC 更贵。

最后附上一个简短的决策速查表，帮助你在不同场景下快速选择迁移目标：

---