我需要下载zip存档，解压缩并加载到S3。我想过使用Lambda来处理下载和取消归档，但它有磁盘大小限制。
这样做的最佳服务是什么？我不能使用我的本地机器，因为我希望这项工作可以运行几天。
答案 0 :(得分：1)
AWS Lambda不适合此任务，这是正确的。 500MB磁盘大小限制将不允许您扩展zip文件。
无论如何，你还需要编写一个“管理层”来生成Lambda任务，这实际上是更复杂的任务。
操作中最困难的部分是跟踪进度，以确保所有文件都已转换和上传，同时考虑到可能发生的随机故障。
我会按照这些方针推荐一些东西：
<强> 1。获取源文件列表
不知何故，您需要一个要转换的源zip文件列表。如果有更多文件一直出现（例如，如果它是一个实时系统），这可能会很复杂。您可以随后对出现的其他文件进行第二次运行。
<强> 2。创建工作追踪器
您需要以某种方式跟踪工作，以便系统知道哪些文件已处理以及哪些文件正在处理中（特别是如果您并行工作）。虽然你没有说明输入文件的数量，但它看起来好像是数万个。
一种非常可靠的方法是为每个要处理的文件创建 Amazon SQS消息。然后工人将从这个队列中拉出来（见下一步）。或者，使用简单数据库来存储信息。
第3。做这项工作
最简单的方法是使用以下脚本启动Amazon EC2实例：
从一小部分文件开始，确认过程正常，然后提高数量。
要充分利用带宽和CPU，您可以在实例上运行多个进程。每个人都将作为独立工作者运作。
使用 Amazon EC2竞价型实例降低处理成本。尝试各种实例类型以找到最佳组合 - 有些具有 Instance Store ，可提供非常快速的本地存储（特别是那些使用SSD的存储）。使用某种形式的日志记录将帮助您跟踪进度并确定哪些实例类型似乎表现最佳，以及在每个工作人员上运行的最佳并行进程数。
通过跟踪SQS或数据库中的工作，可以停止/启动该过程而不会丢失进度。它还可以跨多个实例进行扩展，每个实例有多个工作程序。
<强> 4。处理错误
会出现问题（糟糕的zip文件，网络故障，随机错误），因此您需要再次尝试再次尝试并调查特定错误。您的系统需要跟踪此类问题，以便对其进行重新处理。
<强> 5。审核结果
假设您希望所有处理完的文件，您应该进行最后一次传递，将源文件列表与上传文件的最终列表进行比较。
该方法将取决于您如何将文件上传到S3 - 如果根据源对象命名S3对象，则此工作将更容易（例如，A01.zip的源文件将扩展为{ {1}}，A01/file1等。）
底线：您正在做的工作非常简单。跟踪工作将比实际工作需要更多的努力。
答案 1 :(得分：0)
一个可能的解决方案是：获取EC2 nano实例（非常便宜）..附加EBS卷..编写一个小的bash脚本，使用wget / curl下载文件，并使用AWS CLI上传到S3