我见过很多代码示例/插件，可以将资源直接上传到S3。例如，如果您有一个带有头像的用户对象，则文件上载字段将直接加载到S3。
我认为可行的唯一方法是，如果用户对象已在数据库中创建，并且您的S3存储桶+路径类似于
user_avatars.domain.com/some/id/partition/medium.jpg
但是如果你有一个图像标签试图在没有上传头像时访问该URL，那么它会产生不好的结果。你会如何处理存在的检查？
此外，似乎这对大多数有很多联想都不会有效。例如，如果用户有很多歌曲/ mp3，你会在哪里存储它们以及如何访问它们。
此外，您的验证将被拍摄。
我无法想到直接上传到S3（或任何云）是个好主意的情况，希望人们可以澄清正确的用例，或者告诉我为什么我的逻辑不正确。
答案 0 :(得分：3)
为什么要为存储/带宽/备份/等付费。什么时候你可以让云中的某个人为你处理它？</ p>
S3（以及其他基于云的存储选项）可以帮助您解决所有问题。您可以获得所需的所有存储空间，良好的分发网络（几乎肯定比您自己拥有的更好，除非您支付高级CDN）和备份。
允许用户直接上传到S3会占用更多带宽负载。我可以看到跟踪问题，但S3使得处理这种情况非常容易。如果您查看直接上传方法，您会发现可以强制重定向成功上传。
Amazon会将以下内容传递给重定向处理程序：bucket，key，etag
这应该会为您提供在成功后跟踪上传资产所需的内容。直接上传为您提供两全其美的体验。您可以获得跟踪信息并卸载带宽。
答案 1 :(得分：3)
如果你在Heroku上托管你的Rails应用程序，原因很可能是Heroku不允许大于4MB的文件上传：
http://docs.heroku.com/s3#direct-upload
因此，如果您希望自己的用户能够上传大型文件，那么这就是唯一前进的方式。
答案 2 :(得分：0)
记住Web服务器的工作原理。
除非你使用像Node.JS或Erlang那样的异步网页设置（只有2个例子），否则每个上传请求都会影响整个过程文件上传时的线程或。
想象一下，您正在上传一个几兆字节的文件。大多数互联网用户没有非常快的上行链路，因此您的Web服务器花费大量时间无所事事。虽然它没有做任何事情，但它不能为任何其他请求提供服务。这意味着您的用户开始从服务器获得长时间延迟和/或错误响应。这意味着他们开始使用其他网站来完成同样的事情。您可以随时运行更多进程和线程，但每个进程都需要额外的内存，最终意味着额外的$。
直接上传到S3，除了Justin Niessner提到的带宽节省和Thomas Watson提到的Heroku解决方案外，你还让亚马逊担心这个问题。您可以让单进程Web服务器有效地处理非常大的上传，因为它将实际功能转移到亚马逊上。
所以是的，设置起来比较复杂，你必须处理回调以跟踪事情，但是如果你处理的不是真正的小文件（甚至在那些情况下），为什么要花更多的钱呢？ / p>
编辑：修复拼写错误