山月刀岚月刀最近一直在折腾一个事：把跑了两年的本地服务迁上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 资源配置文件的统一管理
脚本设计里，我认为最重要的一步就是把所有“变量”从代码里抽出来，放到一个配置文件里集中管理。原因很简单：迁移脚本要复用，硬编码路径、IP、端口在脚本里，每次换迁移对象都要改代码，改着改着就出错了。
我用的是configparser标准的INI文件格式，结构如下：
ini复制[local]
source_dirs = /data/apps,/data/uploads,/data/logs
config_files = /etc/myapp/config.ini,/etc/myapp/db.ini
exclude_dirs = /data/logs/temp
[aws]
region = ap-northeast-1
s3_bucket = myapp-migration-bucket
ec2_instance_type = t3.large
ssh_key_name = myapp-key-pair
[app]
new_domain = app.example.internal
db_endpoint = database-1.cluster-xxx.ap-northeast-1.rds.amazonaws.com
这个做法的收益等真正执行时才能体会到。脚本跑起来以后，我只需要关心配置文件里的参数是否正确，而不用在几百行代码里找某个路径写在了哪一行。尤其迁移后期调整了很多次目标ECS的实例规格、安全组规则，全部改配置文件后重启脚本即可，代码一行没动。
这里我尤其想说一下 source_dirs 和 exclude_dirs 的设计。原本我只会写迁移哪些目录，后来发现日志目录下面有大量临时文件，根本没有迁移必要，传上去纯粹浪费时间和流量。于是给脚本加了一个排除机制，把日志中的temp目录排除掉，整个包体直接小了四成。做迁移前，梳理清楚哪些该迁、哪些不该迁，比直接无脑全量复制更有价值。
3.2 资源扫描模块的实现逻辑
资源扫描模块解决的是“你本地到底有什么东西”这个问题。很多人迁移失败，不是因为上传出错，而是因为没有完全摸清本地资源清单，迁完之后发现漏了这个目录少配了那个服务。
我用Python的 os.walk 配合自定义排除规则实现递归扫描，同时计算每个文件的MD5值。这个MD5值后面在数据校验阶段会用到，用来确认远程文件与本地文件是否完全一致。
python复制import os
import hashlib
import json
def calculate_md5(file_path, chunk_size=8192):
md5 = hashlib.md5()
with open(file_path, "rb") as f:
while True:
chunk = f.read(chunk_size)
if not chunk:
break
md5.update(chunk)
return md5.hexdigest()
def scan_local_dirs(config):
dirs = config.get("local", "source_dirs").split(",")
excludes = config.get("local", "exclude_dirs").split(",")
exclude_set = {os.path.normpath(d) for d in excludes}
file_index = []
for base_dir in dirs:
for root, _, files in os.walk(base_dir):
normalized_root = os.path.normpath(root)
skip = False
for excl in exclude_set:
if normalized_root == excl or normalized_root.startswith(excl + os.sep):
skip = True
break
if skip:
continue
for name in files:
file_path = os.path.join(root, name)
md5 = calculate_md5(file_path)
file_index.append({
"path": file_path,
"relative": os.path.relpath(file_path, base_dir),
"size": os.path.getsize(file_path),
"md5": md5
})
with open("local_file_index.json", "w") as f:
json.dump(file_index, f, indent=2)
return file_index
这里我建议把扫描结果落盘成一个JSON文件，而不是作为变量保存在内存里及时丢弃。好处有两个：一方面，迁移过程中如果中途断掉，你可以直接看这个JSON文件感受一下本地有哪些文件已经扫描过，不必重新跑一遍；另一方面，这个清单本身可以作为迁移审计资料，证明“当时本地确实有这些文件”。
扫描脚本跑完后，我还会顺手把结果按文件大小排个序，把单个极大的文件标记出来。因为大文件传输策略跟小文件是两套逻辑，单独处理能显著提升传输稳定性和速度，这部分我在第4节代码实现中会详谈。
3.3 数据同步模块：从顺次上传到并发控制
数据同步是所有环节中最耗时的部分，处理不好也是最容易出问题的。最开始我写的版本很简单：拿扫描清单里的文件逐个上传到S3，用boto3的 upload_file 方法。本地小文件多的时候，这个方式也能凑合跑，但文件一多（上千个），串行上传慢得让人想砸电脑。
优化思路是引入并发。Python的 ThreadPoolExecutor 比较适合这个场景，因为上传文件的瓶颈主要在网络和S3服务端，不占用CPU，用多线程不会遇到GIL限制。我把线程数调到8，配合S3的分片上传机制，整体速度提升了近5倍。
但是并发上来了之后也要注意“限速”问题，不是怼得越高越好。有实测经历的话会发现，线程数开太高反而会导致部分请求超时或触发S3的请求限制，本地出口带宽被打满，其他生产服务也跟着遭殃。我的建议是：先从4线程开始，观察CPU、带宽和S3的响应时间，再逐步调大到8甚至16，找到一个适合自己网络环境的平衡点。
4. 核心代码实现与参数讲解
4.1 boto3接入与S3分片上传
S3的一大优点是天然支持分片上传，也就是把一个对象拆成多个part分别上传，全部完成后触发组装。对大文件来说，分片上传比单次上传更可靠，而且支持断点续传和并行上传，这正好契合我的并发设计需求。
python复制import boto3
import math
from concurrent.futures import ThreadPoolExecutor, as_completed
from tqdm import tqdm
s3_client = boto3.client("s3", region_name="ap-northeast-1")
def multipart_upload(file_path, bucket_name, object_key, part_size_mb=8, max_workers=8):
file_size = os.path.getsize(file_path)
if file_size < part_size_mb * 1024 * 1024:
s3_client.upload_file(file_path, bucket_name, object_key)
return
part_size = part_size_mb * 1024 * 1024
num_parts = math.ceil(file_size / part_size)
# 创建分片上传任务
mpu = s3_client.create_multipart_upload(Bucket=bucket_name, Key=object_key)
upload_id = mpu["UploadId"]
parts = []
with open(file_path, "rb") as f:
def upload_part(part_index):
f.seek(part_index * part_size)
data = f.read(part_size)
resp = s3_client.upload_part(
Bucket=bucket_name,
Key=object_key,
PartNumber=part_index + 1,
UploadId=upload_id,
Body=data
)
return {"PartNumber": part_index + 1, "ETag": resp["ETag"]}
with ThreadPoolExecutor(max_workers=max_workers) as executor:
future_map = {executor.submit(upload_part, i): i for i in range(num_parts)}
for future in tqdm(as_completed(future_map), total=num_parts, desc=f"Uploading {object_key}"):
parts.append(future.result())
parts.sort(key=lambda x: x["PartNumber"])
s3_client.complete_multipart_upload(
Bucket=bucket_name,
Key=object_key,
UploadId=upload_id,
MultipartUpload={"Parts": parts}
)
这段代码核心需要看到几个关键点：
第一，part_size_mb=8 是S3推荐的默认分片大小之一，也能用于绝大多数场景。实际上S3的分片允许5MB到5GB之间，如果你的网络长时间稳定，可以适当调大到16MB减少分片数量，反之网络不稳时就保守一点用8MB。
第二，多线程分片上传时，每个线程的操作句柄需要独立控制文件读取位置。这段代码里我用了 f.seek 来定位到对应part的偏移量，如果直接在循环里 f.read(part_size) 可能会出现线程间读错位置的问题。写这段代码时请务必注意这点，否则上传文件的party会串味。
第三，as_completed 顺序是完成的先后，不代表part的自然序号，所以最后需要 parts.sort 确保PartNumber有序才能完成complete操作。这步漏掉会直接导致云端组装失败。
4.2 小文件批量打包上传
大文件走分片并发，小文件就不适合单个上传了。本地有一堆几百KB的配置文件和日志文件时，如果每个都单独发起一次API请求，光请求开销就会耗费大量时间。我采用了压缩打包方案：把特定目录下的小文件先打成tar.gz再上传S3，到了目标端再解压还原。
这个思路跟搬家时先把零碎小物件装进几个纸箱而不是一趟趟搬运是一个道理。实际测试中，3000多个小文件分批压缩成6个压缩包上传，总耗时比直接逐文件上传缩短了将近70%。注意压缩时保留目录结构，解压后才能对得上位置。
python复制import tarfile
def pack_and_upload(source_dir, bucket, object_key):
tar_path = "/tmp/" + object_key.replace("/", "_") + ".tar.gz"
with tarfile.open(tar_path, "w:gz") as tar:
tar.add(source_dir, arcname="")
multipart_upload(tar_path, bucket, object_key)
return tar_path
压缩会增加一定的CPU消耗和本地临时磁盘占用，所以建议选择在业务低峰期执行，而且临时目录的磁盘空间要留够。如果本机配置较低，可以考虑只压缩不压缩（tar格式），以打包来代替压缩，速度更快且CPU开销小，缺点是存储成本会略高。我当时衡量了下磁盘性能和耗时，选择的是普通tar，实测下来对大目录更友好。
4.3 EC2实例启动与配置自动化
数据同步完成后，接着就该在AWS侧创建算力资源了。EC2实例的启动如果手动在控制台操作，需要注意的选项非常多：AMI选择、实例类型、网络配置、安全组、密钥对、用户数据脚本，一个环节错都要返工。用代码创建的优势是整个过程可重复，而且初始配置会通过用户数据脚本（User Data）自动执行。
我使用的示例配置代码涉及安全组创建和EC2实例启动：
python复制def create_security_group(ec2_client, vpc_id, group_name):
resp = ec2_client.create_security_group(
GroupName=group_name,
Description="Migration security group",
VpcId=vpc_id
)
sg_id = resp["GroupId"]
ec2_client.authorize_security_group_ingress(
GroupId=sg_id,
IpPermissions=[
{
"IpProtocol": "tcp",
"FromPort": 22,
"ToPort": 22,
"CidrIp": "你的办公出口IP/32"
},
{
"IpProtocol": "tcp",
"FromPort": 80,
"ToPort": 80,
"CidrIp": "0.0.0.0/0"
},
{
"IpProtocol": "tcp",
"FromPort": 443,
"ToPort": 443,
"CidrIp": "0.0.0.0/0"
}
]
)
return sg_id
def launch_ec2_instance(ec2_client, ami_id, instance_type, key_name, sg_id, user_data_script):
resp = ec2_client.run_instances(
ImageId=ami_id,
InstanceType=instance_type,
KeyName=key_name,
SecurityGroupIds=[sg_id],
MinCount=1,
MaxCount=1,
UserData=user_data_script,
TagSpecifications=[
{
"ResourceType": "instance",
"Tags": [{"Key": "Name", "Value": "migration-app-server"}]
}
]
)
instance_id = resp["Instances"][0]["InstanceId"]
return instance_id
特别提醒：
安全组里放行的 CidrIp 上，SSH入口建议只用你当前办公出口IP，而不是 0.0.0.0/0。早期为了省事想直接全放通，后来检查安全审计记录时发现有不少扫描IP在尝试连接，虽然密钥对复杂度够高没出大事，但这习惯必须改。HTTP和HTTPS端口依据业务需求开，而运维管理端口收得越紧越好。
User Data脚本本质上是实例启动后执行的一段shell命令，常见用途是安装软件、拉取代码、配置依赖。我做迁移时把这台实例需要部署的Nginx、Python依赖、环境变量初始化都写在了User Data里，这样实例一启动就自动完成基础配置，不需要人手动SSH进去一步步操作。
4.4 数据校验与回滚：迁移的最后一道保险
数据上传完成，不代表迁移成功。必须验证远程数据与本地的完全一致性。我采用的方式是：从EC2实例上重新计算S3对象的MD5，跟本地扫描时记录的MD5逐一对比。由于S3的ETag机制与大文件分片和MD5的关系并不总是直接对应，因此对大文件我会额外使用 s3_client.get_object 下载几处抽样校验字节，或者用对象属性中的 ContentLength 和本地大小比对，再结合文件哈希抽样来判断。
python复制import boto3
def verify_s3_object(bucket, key, local_path, local_md5):
resp = s3_client.head_object(Bucket=bucket, Key=key)
if resp["ContentLength"] != os.path.getsize(local_path):
return False
# 下载到临时目录，重新计算MD5比对
tmp_path = f"/tmp/verify_{os.path.basename(local_path)}"
s3_client.download_file(bucket, key, tmp_path)
remote_md5 = calculate_md5(tmp_path)
os.remove(tmp_path)
return remote_md5 == local_md5
如果在校验阶段发现文件不一致，先不要着急删本地数据，保留一份本地快照，同时检查S3的versioning是否开启。开启版本管理后，即使被覆盖的对象也可以通过历史版本找回，这对迁移过程的容错非常有帮助。我这次迁移全程开着版本管理，虽然有部分文件在上传过程中因网络中断记录过一次失败，但最终靠着版本管理恢复出了正确版本。
回滚设计上，流的是“低风险回退”原则：迁移过程中，本地服务不停机，AWS上的新服务先建设并验证完毕，再切换流量。这样出了问题随时可以回退到本地环境，不需要承担“一键切换后新环境不可用”的风险。整个过程分成预迁移、正式同步、验证切换三个阶段，每个阶段都有明确的退出点。
5. 实施过程全记录与优化
5.1 预迁移演练：先用测试环境跑通全流程
我强烈建议所有迁移项目先做一轮预迁移演练，核心理由是：迁移脚本是代码，代码就可能存在逻辑bug，直接在生产环境上试错代价太高。预迁移时我搭了一套完全同构的测试环境，包括本地测试目录、测试S3桶和一台试用EC2。测试过程中发现了一个很隐蔽的问题：本地文件路径中包含中文文件名，os.walk扫描和上传时Mini的编码处理会出现不一致，导致上传后的对象Key乱码。
这个问题如果不上线测试根本发现不了。后来我在逐个文件设置对象Key时统一做了编码规范处理，用 urllib.parse.quote 对非ASCII字符进行URL编码，S3本身接受URL编码的对象Key，而读取时自动还原成原文件名。这个修复虽然只加了两行代码，但避免了一次生产数据的排列组合事故。
预迁移演练的另一个目的是估算迁移时长。我在测试环境里记录了不同大小文件的传输速率，根据本地文件清单的总大小反推出正式迁移大概需要多少时间，再选择在业务低峰期安排正式切换窗口。实测下来，这个预估误差控制在10%以内，对项目管理来说很有价值。
5.2 正式执行与切换流程
正式迁移的执行流程，我是按下面几个步骤走的：
- 先对本地服务做一次完整备份，包括数据库导出和文件快照。
- 运行资源扫描脚本，生成最新的本地文件清单，确认源文件状态。
- 执行数据同步脚本，把文件传到S3，启动EC2实例并自动配置环境。
- 在EC2上恢复数据，修改配置中的数据库连接和主机名。
- 运行校验脚本，对比本地与云端的数据一致性。
- 修改DNS或负载均衡权重，将流量按比例切到AWS侧。
- 观察一段时间，确认新环境稳定后再关闭本地服务。
其中第4步经常被忽略。很多团队迁移后应用起不来，排查发现是应用的配置还指向本地数据库地址或本地文件路径。虽然看起来是小事，但如果不提前在User Data中预置好新环境的配置模板，切换时慌慌张张去改，很容易漏掉某个参数。我是把所有的环境变量和配置文件模板都放在S3上的一个固定路径，EC2启动后自动拉取并覆盖到对应位置，这样新实例无论何时重建，都能拿到一致的配置。
5.3 迁移后优化：稳定之后再做性能调整
迁移完成、服务运行正常只是第一步。接下来还有性能优化和成本优化这两个课题。我在切换后第一周连续观察了几个核心指标：CPU负载、内存占用、网络带宽、API响应时间，以及最关键的账单费用。
这里有个值得分享的经验：AWS的计费模式跟本地IDC完全不同，按量付费模式下，闲置的EC2实例是最大的浪费来源。迁移脚本跑完后我一共开了4台算力实例，实际业务流量根本用不了这么多，高负载期只有2台。后来我花了一个周末把脚本扩展了一下，加入了基于CloudWatch指标的自动伸缩策略，高峰期自动扩容、低峰期自动缩容，节省下来的成本非常可观。
另外S3存储成本也需要注意。迁移期间上传了大量临时文件，有些是重复的大文件，服务切完之后这些文件还在空占地方。我加了一条生命周期策略：临时目录下的对象超过30天自动转成Glacier存储类，超过90天自动删除。定好生命周期规则后，存储账单明显回落，不然每个月白交一笔费用。
6. 常见问题与排查技巧实录
6.1 常见问题速查表
整个迁移项目实施过程中，我没少遇到错误，下面把这些高频问题做成了一张速查表，方便后面有需要的人快速定位：
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| 脚本调用AWS API报“AccessDenied” | IAM用户权限不足或尚未配置正确策略 | 检查IAM策略，至少需要S3 FullAccess和EC2 FullAccess相关权限 |
| 上传大文件到一半断开 | 本地网络不稳定或代理干扰 | 启用S3分片上传，开版本管理，断点重传 |
| EC2实例启动后User Data不执行 | User Data只会在第一次启动时执行，且需加 #!/bin/bash 头 |
检查脚本头，日志查看 /var/log/cloud-init-output.log |
| S3对象下载后MD5不一致 | 大文件ETag不等于MD5，直接比对出错 | 对小文件比对MD5，大文件比较ContentLength加抽样字节 |
| 压缩包解压后文件权限丢失 | tar归档未保存权限位 | 使用tar的 --preserve-permissions 参数重新打包 |
| DNS切换后部分用户仍访问旧服务 | DNS缓存生效延迟 | 切换时将旧服务TTL预调低，再修改解析记录 |
| 配置文件里数据库地址是内网IP | 迁移时未同步更新应用配置 | 统一使用配置文件管理环境变量，云端模板覆盖本地配置 |
6.2 定位“隐性失败”的排查思路
让我展开说一个数据校验阶段的高频问题。脚本报错“校验失败”，但本地文件明明存在，云端对象也显示正常，看起来哪都没问题。这往往是最前几次跑校验脚本时的典型状况。
排查这类隐性失败，我的建议是按下面顺序来：
首先对比文件清单，检查是不是漏传了某些小文件。我用并发的上传模式后，偶尔会因为网络隔离导致个别小文件上传失败，这部分不会立刻报错，而是被Future中的异常吞掉。所以我单独加了失败重试机制：任何一次上传失败，文件路径会写入 failed_files.txt，全部任务结束后再次执行重传。
其次检查是否存在同名但路径不同的文件。如果本地目录结构里有软链接，os.walk默认会遍历链接的绝对路径，导致S3对象Key里出现一堆莫名其妙的路径。我后来扫描时专门加了 followlinks=False 参数，并在收集清单时对软链接单独标记，避免传输时创建错误的目录结构。
最后看S3 Bucket是否开启了默认加密。即使开默认加密，上传时如果显式设置 ServerSideEncryption 参数且值不匹配，也可能出现拒绝访问。这种错误提示看得最直白，往往硬化在日志里，但如果你不看完整日志，很容易跳过这个细节。检视一下S3权限和加密参数，往往能解决不少看似无解的失败。
6.3 我踩过的一个经典坑：端口映射绕了远路
迁移早期，我在安全组配置上犯过一个低级的错误：把应用某个内部管理端口开到了 0.0.0.0/0，然后校验时想从本地直连测试这个端口。结果发现无论如何都连不上，AWS的Network ACL和路由表如何排查都查不出问题。
后来静下心来梳理，发现本地出口网络本身对这个端口做了出访拦截，根本不是AWS侧的问题。也就是说，数据包根本还没出本地网络就已经被阻断了。
这次排查整整耗费了两个小时，教训很深刻：迁移过程中遇到连接类问题，先看控制台、再查安全组、路由表、最后怀疑本地网络策略，层层排查，不要直接从中间开始猜。后来我在项目里加入了一个简单的连通性检查脚本，启动EC2后自动从实例主动请求一个外部健康检查URL，避免从本地外部访问云端端口，从根源上跳过这个坑。
写在最后的一点个人体会
迁移做完之后，我最大的感受是：云迁移这件事真正的难点不是在AWS控制台怎么操作，而是在于把本地架构梳理清楚、把流程设计得可执行、把数据校验做到位。Python自动化脚本在这里扮演的角色，就像是一条流水线，把一件本来需要靠人盯着的重复性工作，变成了可一分钟跑完、可反复运行的标准化流程。
从脚本的第一行代码，到最后一次校验通过，这中间踩过的坑远比我文中写到的多。但回过头看，如果重新再做一次，我依然会采用同样的技术路线，只是会在早期就加上更完善的日志和重试机制，而不是等出错了才回头补补丁。希望你做完自己的迁移项目后，也能有类似的体会——不是畏惧工具复杂，而是学会用工程化的方式管理复杂。