将S3桶直接安装到EC2实例中是否安全？

如果您使用S3来存储用户上传的数据，特别是在分布式环境中，一个重要的考虑因素是S3是“最终一致的”（尽pipe一些区域是一致的）。 这样做的结果是，您可以成功上传文件，但如果您立即检查其存在，可能会发现它不存在。 对于更新或删除等情况，此问题更为明显，即使读写后一致性也无济于事。

以上内容适用于您上传到S3，无论您采取何种方式。 实际上，人们可能期望的S3的大部分问题都是如此 – 它不是用于存储数据的方法，因为S3的局限性可能是最大的问题。

S3fs使用S3 API – 就像PHP（或其他）SDK一样。 而且，S3的devise是为了处理相当高的并发水平 – 所以（除了一致性问题之外）在多个实例上安装它不应该是一个问题（记住它不是传统的文件系统 – locking，等等在S3端处理）。

也就是说，每个实现都有一些潜在的优点和缺点：

S3fs：

• 不支持部分/分块下载（据我所知） – 所以你必须下载完整的文件来阅读它的任何部分 – 如果你只是使用它来存储（和提供）上传可能不是一个问题。
• 用C ++编写可能的性能增益
• 您的应用程序可以从s3fs的任何更新中受益
• 实现caching（全部文件和文件信息） – 有可能提高速度，降低成本
• 限于熔丝暴露的function

SDK：

• 公开了S3必须提供的全套function – 根据您的使用情况，这可能足以值得使用SDK
• 与您的应用程序可能更紧密的集成 – 返回的错误等可能会让您的应用程序更好地通知（因此更精确）的select
• 任何可能的优势都需要进行编码 – 您的应用程序必须利用这些优势并随时掌握S3的未来变化
• 您的代码更复杂，开销更大

就“安全”而言，可能意味着“防止数据损坏”或“防止未经授权的访问”。 关于前者，SDK可能会帮助处理最终的一致性（以更冗长的错误的forms），但底层存储是相同的，我预计这些差异是微小的。 关于访问控制 – 您可以使用IAM创build一个有限的帐户，但该帐户仍然需要读/写访问您的S3文件。 两者都应该有足够的安全性，无论哪种情况，你的系统都需要被攻破才能访问你的S3存储桶 – 不过我build议使用S3fs（因为凭证通常存储在webroot之外，并且根本不可访问PHP）有一个更好的安全性。

个人观点：如果有一个上传目录（例如一个站点使用它），并且访问相当简单（只需要上传文件，偶尔更新/删除），那么我倾向于使用s3fs。 如果您需要更复杂的访问（例如部分下载，多个桶等）或将要使用S3 SDK用于其他目的，那么我将坚持用于上传的SDK。

我宁愿上传到S3通过PHP库。 在每台服务器上安装S3比较容易。

看看这个例子： http : //aws.amazon.com/code/126

对于我的一个项目，我使用这个lib： http : //undesigned.org.za/2007/10/22/amazon-s3-php-class 。 为我工作得很好。

您可以允许用户直接从浏览器上传到s3，而无需上传到服务器（然后上传到s3）。

这里有一个很好的提示： https ： //leonid.shevtsov.me/post/demystifying-s3-browser-upload/

file upload后，如果需要处理文件（zip，transcode等），你可以使用S3fs