AWS深度学习训练：从外部按需启动EC2实例运行数据转换脚本最佳实践

我来分享几个针对你这个场景的最佳实践，刚好之前帮团队处理过类似的大规模深度学习数据转换任务，结合AWS生态的工具，既能解决当前手动启动EC2的痛点，也能为后续Step Functions自动化铺路：

手动启停EC2太繁琐，推荐用Launch Template+boto3脚本的组合，核心是让实例启动后自动完成所有任务，不用手动登录操作：

• 先创建一个EC2 Launch Template：预配置好适合的AMI（比如AWS官方的Deep Learning AMI，自带Python、numpy、boto3这些依赖）、实例类型（根据你的内存需求选，比如r5.4xlarge，用完就销毁），并给实例绑定一个IAM角色——这个角色需要有访问源S3 bucket、目标S3 bucket的权限，以及CloudWatch Logs的写入权限。
• 用Python写一个简单的启动脚本，通过boto3调用EC2 API启动实例，同时通过User Data注入初始化命令：

import boto3

ec2_client = boto3.client('ec2')

# 启动实例并自动执行转换脚本
response = ec2_client.run_instances(
    LaunchTemplate={'LaunchTemplateName': 'data-conversion-template'},
    MaxCount=1,
    MinCount=1,
    # UserData里的脚本会在实例启动后自动执行
    UserData='''#!/bin/bash
                # 确保依赖最新（如果AMI里没有的话）
                sudo pip3 install --upgrade numpy boto3 s3fs
                # 运行你的转换脚本（可以提前把脚本放在S3，用aws s3 cp下载到实例）
                aws s3 cp s3://your-bucket/scripts/conversion.py /home/ubuntu/
                python3 /home/ubuntu/conversion.py
                # 脚本执行完成后自动关机，避免浪费资源
                sudo shutdown now -h''',
    # 打标签方便后续追踪和清理
    TagSpecifications=[
        {'ResourceType': 'instance', 'Tags': [{'Key': 'Task', 'Value': '3D-Data-Conversion'}]}
    ]
)

instance_id = response['Instances'][0]['InstanceId']
print(f"Started instance {instance_id} for data conversion")

这样实例启动后会自动完成环境准备、脚本下载执行，任务结束后自动关机，完全不用手动干预。

处理数十万小文件+生成100GB级别的数组，脚本本身的效率直接影响任务耗时：

• 用s3fs库直接把S3 bucket挂载到EC2本地目录，像操作本地文件一样读取numpy数组，避免逐个调用boto3下载的开销：

import s3fs
import numpy as np

# 挂载源S3 bucket
fs = s3fs.S3FileSystem()
fs.mount('s3://your-source-bucket', '/mnt/source-data')

# 读取所有2D数组文件
file_list = fs.glob('/mnt/source-data/*.npy')
all_arrays = [np.load(f) for f in file_list]

# 拼接成3D数组（根据你的需求调整轴）
combined_3d_array = np.stack(all_arrays, axis=0)

# 压缩后保存到目标S3
with fs.open('s3://your-target-bucket/combined_data.npz', 'wb') as f:
    np.savez_compressed(f, data=combined_3d_array)

• 尽量用numpy的向量化操作替代循环，如果数据量太大导致内存不够，可以分批次处理：比如每1000个2D数组拼接成一个子3D数组，保存到S3后释放内存，最后再合并（如果需要的话）。
• 开启CloudWatch日志：在脚本里加入logging模块，把进度、错误信息输出到标准输出，EC2实例的IAM角色有CloudWatch权限的话，这些日志会自动同步到CloudWatch Logs，方便你远程查看任务进度和排查问题。

现在手动执行的流程，要改成Step Functions状态机非常顺畅，核心是把各个操作拆成状态节点：

• 启动EC2实例：用Step Functions的AWS SDK集成，直接调用ec2:RunInstances，传入Launch Template和UserData参数。
• 等待任务完成：可以两种方式实现：一是在转换脚本执行完成后，调用SNS发送一个“任务完成”通知，Step Functions监听这个SNS主题；二是用CloudWatch Events监听EC2实例的“已停止”状态，触发下一步。
• 清理资源：实例停止后，Step Functions调用ec2:TerminateInstances彻底销毁实例，避免残留资源产生不必要的费用。
• 错误处理：给状态机添加错误分支，如果实例启动失败、脚本执行出错，自动触发SNS告警（比如发邮件给你），或者重试任务。

另外，如果你不想自己管理EC2实例，也可以考虑用AWS Batch替代——Batch专门用于批量处理任务，你只需要定义作业队列、作业定义（指定镜像、脚本、资源需求），Step Functions可以直接提交Batch作业，Batch会自动启停实例、调度任务，更省心。

• 遵循最小权限原则：给EC2实例的IAM角色只分配必要的权限——比如s3:GetObject（源bucket）、s3:PutObject（目标bucket）、logs:CreateLogStream和logs:PutLogEvents（CloudWatch日志），不要给管理员权限。
• 不要在脚本里硬编码AWS凭证：EC2实例通过IAM角色自动获取临时凭证，直接用boto3/s3fs就能访问AWS服务，安全又方便。
• 把EC2实例放在私有子网：通过NAT网关访问S3，不要让实例暴露在公网上，降低安全风险。

我之前用这套方案处理过120GB的类似数据转换任务，从启动实例到完成销毁，整个流程耗时约2小时，成本不到5美元，效果很稳定。

内容的提问来源于stack exchange，提问作者ddd