如何基于PDF内capture_date字段将S3桶数据迁移至Glacier？

方案适用性判断 #

Fargate完全适配该场景，是兼顾成本、可维护性和任务可靠性的优选方案。

Fargate实现思路 #

• 预生成S3存量清单：开启S3 Inventory功能导出桶内所有PDF对象的Key列表，输出为CSV文件存储到独立路径，避免直接遍历S3桶产生的高额请求开销和性能损耗。
• 构建处理镜像：打包包含PDF解析组件（如pdfplumber、PyPDF2）和AWS SDK的运行镜像，上传到ECR。镜像内置逻辑为：拉取S3 Inventory的CSV分片，逐行读取对象Key，下载对应PDF文件并解析提取capture_date字段，将满足迁移条件（capture_date < 2015-05-21）的对象Key写入SQS队列做缓存。
• 执行迁移：可以直接在Fargate任务中调用S3 copy_object接口，指定目标存储类为GLACIER/GLACIER_IR/DEEP_ARCHIVE后删除原对象；也可以单独启动迁移任务消费SQS队列，支持断点续传，避免任务中断后重复处理。
• 增量场景适配：后续新上传的PDF可搭配S3事件触发Lambda，上传后自动解析capture_date并给对象打上对应标签，后续可直接用S3生命周期规则基于标签筛选迁移，无需重复运行Fargate批处理任务。

其他可行方案 #

• Lambda批处理方案：如果单PDF体积较小、单文件解析耗时不超过15分钟，可使用Lambda分批处理S3 Inventory清单，成本比Fargate更低，适合文件总量百万级以下的场景。
• EC2批处理方案：如果总数据量达数十TB、文件量超千万级，可使用按需EC2或Spot实例运行处理逻辑，资源配置灵活度更高，可根据任务量调整实例规格。
• S3 Batch Operations方案：提前解析所有PDF的capture_date并给对应对象打上标签，之后调用S3 Batch Operations官方托管任务批量修改符合条件对象的存储类，迁移过程可靠性更高，无需自行维护迁移任务的异常处理逻辑。

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