山月刀岚月刀最近一直在折腾一个事：把跑了两年的本地服务迁上AWS。最早接触云迁移时，我以为就是把服务器内容打个包扔到云主机上那么简单，结果真上手才发现，迁移过程中最耗费时间的根本不是“上传”这个动作，而是资源梳理、配置校验、数据一致性检查这一大堆琐碎环节。手动操作一遍下来，光是核对十几台服务器的配置就快把人逼疯。
后来我干脆用Python写了一套自动化脚本来干这个活。这套脚本帮我完成了本地资源清单扫描、AWS S3桶创建、数据分片上传、EC2实例启动、安全组配置、迁移后数据校验等一整套流程。整个迁移过程从原来预计的三天压缩到一天半，中间还避开了好几个手动操作时容易踩的坑。这篇文章就把这套方案的完整思路、脚本设计和落地经验拆开讲清楚，给同样要做云迁移的同学一个可以直接参考的路线。
本文适合这几类人看：准备把本地应用迁到AWS但还在纠结怎么做的团队、想用Python脚本替代重复手动操作的运维开发、以及刚接触云迁移但想少踩点坑的个人开发者。我会把从环境准备、脚本编写到正式执行的关键细节都写出来，包括那些不实际跑一遍根本发现不了的坑。
1. 项目概述与迁移方案设计
1.1 为什么要用Python自动化脚本做云迁移
很多第一次做云迁移的人会问：直接用AWS控制台点按钮不行吗？为什么非要写脚本？答案很简单：控制台适合“单次、少量、试错”的场景，但真实迁移面对的往往是几十个目录、几百个配置文件、多台服务器的批量操作。举个最直观的例子，你在控制台上创建一个S3桶只需要两分钟，但你如果要创建五十个桶、再给这五十个桶分别设置生命周期规则、标签和权限策略，纯手动点下来至少需要半天，而且极易漏配置。
Python脚本在这件事上的优势是三重叠加的：
一是可重复性。同一套脚本先在测试环境跑几遍，确认没有问题了，再拿到生产环境执行，流程完全一致，不存在“这次少点了一个按钮”的人为失误。二是可记录性。脚本每执行一步都能打印日志、记录结果，迁移完成后可以回溯每一步做了什么，这对后续审计和排障非常重要。三是可扩展性。迁移不是一次性事件，后续可能要做增量同步、周期校验，写好的函数可以直接复用，不需要重新造轮子。
另外还有一个很容易被忽视的点：AWS提供了boto3这个官方Python SDK，几乎覆盖了所有AWS服务的API操作。这意味着你能在控制台做的事情，基本上都能用代码实现。用Python写迁移脚本，本质上就是把控制台上的手动点击翻译成可复用、可版本管理的代码。
1.2 迁移策略选型：从Rehost到Refactor的本地考量
做迁移方案时，我首先想的不是“怎么写脚本”，而是“用哪种迁移策略”。AWS官方把迁移策略分为七种，常见缩写是7R：Rehost（重新托管）、Replatform（更换平台）、Refactor（重构）、Repurchase（重新购买）、Relocate（迁移）、Retain（保留）、Retire（淘汰）。
我的选择是Rehost为主、局部Refactor为辅。原因很实际：本地那套服务大部分是无状态Web应用加少量有状态数据库，Rehost方案能最快上线，风险和改造成本都最低。但有几处代码原来直接读写本地文件，迁到云上以后需要改成S3对象存储，这一部分就属于轻量级Refactor。
这个选择直接决定了脚本的设计方向。Rehost路线下，脚本的核心职责是“搬”，也就是把本地资源原样搬到AWS对应服务上；而Refactor部分，脚本要额外处理数据格式转换和服务替换。如果一开始就选错了方向，比如明明可以用Rehost解决，却非要做全量Refactor，迁移周期会被拉得非常长，这个坑我见过不少团队踩过。
方案定下来之后，我把脚本的模块划分清楚了，避免在实施过程中改来改去。整个脚本按功能拆成五个模块：环境检查、资源扫描、数据同步、资源创建、校验回滚，模块之间通过配置文件解耦。这样写的好处是，任何一步出问题，只需要单独调试对应模块，不用连坐其他部分。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境准备与工具链部署
2.1 Python运行环境与依赖库安装
这套迁移脚本基于Python 3.10开发，操作系统是Linux。如果你机器上还没装Python，建议优先装3.8以上版本，因为boto3新版对API类型提示的支持更好，写脚本时能少踩很多类型相关的坑。Python安装完成后，建议顺手建一个独立的虚拟环境，不要把依赖装到系统全局环境里，避免污染原有Python环境。
bash复制python3 -m venv aws-migration-env
source aws-migration-env/bin/activate
pip install --upgrade pip
pip install boto3 paramiko configparser
这里装了三个主要依赖：boto3负责调用AWS API，paramiko负责在本地服务器上执行远程命令和SFTP传输，configparser用于读取配置文件。加粗提醒一下：paramiko不是单纯为了“远程执行命令”这个锦上添花的功能，它还是后面做增量同步时校验源文件MD5的关键工具。很多人写迁移脚本只装boto3，结果做到校验环节又临时补装，不如提前规划好。
我还额外装了一个 tqdm 库，用来在长任务传输时显示进度条，这虽然不是功能必需品，但对排障心态帮助极大。你传一个20GB的文件跑了几分钟没有任何输出，会忍不住怀疑脚本是不是卡死了，有进度条能直观看到传输还在继续。
2.2 AWS CLI与认证配置
脚本要调用AWS API，必须配置认证凭证。这里我强烈推荐用AWS CLI来配置，而不是直接在脚本里硬编码Access Key。硬编码的Key一旦被提交到Git仓库，基本上等于把账号密码公开了，这个教训我身边有朋友踩过，后果非常严重。
AWS CLI安装方式很简单：
bash复制curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install
aws configure
执行 aws configure 后，按提示输入Access Key ID、Secret Access Key、默认区域和输出格式。这里有两个容易被忽略的细节：
第一，建议创建一个专门的迁移用IAM用户，只授予它本次迁移涉及的S3、EC2权限，不要直接用根账号。这是最小权限原则，防止脚本出问题时影响面过大。第二，默认区域要选择与目标地域一致的region，比如你的EC2计划建在 ap-northeast-1，那S3也尽量选同一个区域，跨区域访问会产生额外的流量费用，而且传输速度明显变慢。
配置完成后，可以用一条命令验证是否成功：
bash复制aws s3 ls
如果能正常列出Bucket列表，说明凭证有效。这个验证步骤别省，我见过有人在没验证凭证的情况下直接跑脚本，结果第一条API调用就报权限错误，还得回头排查环境问题。
3. 自动化脚本核心模块拆解
3.1 资源配置文件的统一管理
脚本设计里，我认为最重要的一步就是把所有“变量