我们已经探索了弹性文件存储(EFS - 有点贵(和跨多个 EBS 卷同步 S3 存储(容易出现同步问题(，尽管我们在 s3fs(S3 Fuse(的各个方面都存在无穷无尽的问题，但我们使用它的规模，我们的应用程序需要该功能。
我们需要为 VPC 上的 5(五(个自动扩展的内存优化 EC2 实例(LB-ed Web 服务器(提供足够的文件上传性能，这些实例与由最终用户管理并由应用程序维护的"资产"共享相同的文件系统结构。
我们尚未探索的潜在解决方案，用于利用我们的 CloudFront CDN 配置处理在边缘情况下可能高达 2GB 的文件，或者多达 600 个文件(每个"页面"从 5MB 到 100MB 不等(供用户查看/编辑。 这在规模上似乎有问题，就像S3FS一样多(如果它甚至是一个可行的选择的话(。
倾向于成本效益，但仍然对性能有严格的考虑：
-
EFS 是否是 S3FS 功能的可行且经济高效的替代选项？
-
大量EBS卷的成本控制是一个问题，尽管没有被排除在外 作为一个可行的选择，但性能是否值得 增加成本？
-
CloudFront 是否能够处理所述的此类负载？
-
有没有我们可能想要探索的更好的选择，我们一直错过了？
很明显，最好的使用案例是 Amazon EFS，因为它被设计为一个文件系统，可以跨多个可用区挂载在多个 Amazon EC2 卷上。
任何使用 S3 进行存储的解决方案都不是真正的文件系统，因为它只是将 S3 "呈现"为文件系统，而事实并非如此。因此，将有一些开销和潜在的问题。
如果您唯一的问题是价格，那么希望您会发现性能和无缝使用是值得的。任何其他解决方案都有额外的隐藏成本，即维护一个可能出错的附加系统。从长远来看，一个有效且易于维护的系统通常是最佳价值。
您可以自己尝试解决方案(例如文件网关(，看看它是否满足您的需求。