我正在开发一个包含文件存储和共享功能的项目，经过数月研究利用AWS的最佳方法，我仍然有点担心 .
基本上我的决定是使用EBS存储来存放用户文件或S3 . 当用户想要下载少量文件时，系统将包含即时zip存档 . 此外，当用户下载任何文件时，我不希望URL暴露给文件 .
我提出的两个最佳选择是：
-
拥有一个EC2实例，其中安装了许多EBS卷以存储用户文件 .
-
专业版：它似乎比S3快得多，从EBS卷中压缩文件很简单 .
-
缺点：我相信亚马逊会限制你可以使用多少EBS存储，而且不像S3那样多余 .
-
上传和处理文件后，系统会将这些文件推送到S3存储桶以进行长期存储 . 当请求文件时，我将从S3检索文件并输出回客户端 .
-
专业人员：冗余，没有文件存储限制
-
缺点：看起来很慢，无法在文件系统中将S3存储桶作为卷安装，提供压缩文件意味着将每个文件传输到EC2实例，压缩，然后最终发送输出（再次，慢！）
我的任何假设都有缺陷吗？谁能想到管理大量文件存储的更好方法？
4 回答
如果您的服务将由不确定数量的用户使用，请务必记住可扩展性始终是一个问题，无论采用何种选项，您都需要扩展服务以满足需求，因此方便的假设您的服务将在具有EC2实例池而不是单个实例的Auto Scaling组中运行 .
关于URL的保护只允许授权用户下载文件，有很多方法可以做到这一点，而不需要你的服务充当中间件，那么你将需要处理至少两个问题：
File name predictability ：为避免URL可预测性，您可以将上传的文件命名为哈希，并将原始文件名和所有权存储在SimpleDB等数据库中，也可以设置http标头，如"Content-Disposition: filename=original_file_name.ext"，以建议用户浏览器相应地命名下载的文件 .
authorization ：当用户要求下载您的服务的给定文件时，使用Query String Authentication或Temporary Security Credentials为该特定用户发出临时授权，在一段时间内对该文件进行读取访问，然后您的服务重定向到S3存储桶URL以供直接下载 . 这可以极大地卸载您的EC2池实例，从而可以更快地处理其他请求 .
为了减少S3存储桶的空间和流量（请记住你支付每GB的存储和传输费用），我还建议使用标准算法（如gzip）压缩每个文件，然后再上传到S3并设置 Headers " Content-Encoding: gzip "以便自动解压缩使用用户浏览器 . 如果您选择的编程语言是Java，我建议您查看我创建的插件代码webcache-s3-maven-plugin，以便从Web项目上传静态资源 .
关于压缩文件夹的处理时间，您将经常无法确保文件夹将在短时间内被压缩，以便允许用户立即下载，因为最终可能会有大量文件夹可能需要几分钟甚至数小时被压缩 . 为此，我建议您使用SQS和SNS服务以允许 asynchronous compression processing ，它将按如下方式工作：
用户请求文件夹压缩
前端EC2实例在SQS队列中创建压缩请求
后端EC2实例，使用SQS队列的压缩请求
后端实例将文件从S3下载到EBS驱动器，因为生成的文件是临时的，我建议选择使用至少m1.small实例和 ephemeral 类型的磁盘，这些磁盘是虚拟机本地的，以便减少I / O延迟和处理时间 .
生成压缩文件后，服务将文件上传到S3存储桶，可选地设置Object Expiration属性，这将告诉S3存储桶在一段时间后自动删除文件（再次降低存储成本），以及发布文件已准备好下载的通知SNS主题 .
如果用户仍在线，请阅读主题中的通知，并通知用户zip文件已准备好下载，如果一段时间后此通知未到达，您可以告诉用户压缩时间超过预计，一旦文件准备好下载，服务将通过电子邮件通知他 .
在这种情况下，您可能有两个Auto Scaling组，分别是前端和后端，可能具有不同的可扩展性限制 .
如果您坚持使用S3直接从EC2实例提供zip文件，那么比在本地存储它们更复杂 . 但S3比任何EC2存储卷都更耐用，所以如果文件需要保存很长时间，我建议使用它 .
您说您不希望直接公开文件URL . 如果这只是因为您不希望人们将它们加入书签并在将来绕过您的服务身份验证，那么S3有一个很好的解决方案：
1 - 在私有S3存储桶中存储您要提供的文件（如果您愿意，可以将其压缩） .
2 - 当用户请求文件时，请对请求进行身份验证，然后将有效请求重定向到文件的 signed, temporary S3 URL . 有许多语言可以创建这些URL .
3 - 用户直接从S3下载文件，而不必通过您的EC2实例 . 这样可以节省带宽和时间，并且可以为用户提供最快的下载速度 .
这确实暴露了一个URL，但这可能没问题 . 如果用户保存URL，则没有问题，因为它在您设置的到期时间后将无法工作 . 对于我的服务，我将时间设置为5分钟 . 由于它是经过数字签名的，因此用户无法在不使签名失效的情况下更改URL中的到期时间 .
使用S3是这个用例的更好选择 . 它更好地扩展并且更简单 . 你为什么担心它很慢？ EC2和S3之间的转移非常活泼 .
一些考虑：
EBS卷成本是S3的几倍 .
EBS卷大小限制为16 TB，因此不应成为问题 . 但是，这种尺寸的体积非常昂贵 .
确保您的存储桶与EC2实例位于同一区域 .
使用VPC endpoints 与S3通信 . 这要快得多 .
确保您的EC2实例类型具有您需要的网络带宽 . CPU和网络速度随实例大小而增加 .
我会将所有内容保存在S3上，根据需要下载文件以将其压缩到一个包中 . 然后将zip上传到S3，并向用户提供S3签名URL以从S3下载 .
您可以允许用户从您的EC2实例下载，但许多用户有错误问题，重试问题，带宽缓慢等 . 如果zip文件很小（小于100 MB）在本地提供，否则上传到S3并让S3处理用户下载问题 .
另一种选择是创建一个Lambda函数，用于创建zip文件并在S3上存储 . 现在您不必担心网络带宽或扩展 . Lambda函数可以返回您提供给浏览器的S3 URL，或者Lambda可以通过电子邮件向客户发送链接 . 仔细研究SES . 注意：Lambda文件系统只有512 MB的空间，内存最多可以分配1.5 GB . 如果您生成大于此的zip文件，Lambda将无法工作（此时） . 但是，您可以创建多个zip文件（part1，part2，...）