我的网站目前托管在具有 EBS 卷的 EC2 上。但我经常在同一个实例上运行 Java 程序（输出到 EBS）来生成/更新网站文件。运行时 CPU 和内存峰值达到 100%，这导致我的网站要么非常慢，要么根本无法打开，直到该过程结束。此外，我为整个月支付了一个大型实例的费用，只是为了每月运行几次这个 Java 程序。
为什么不在本地运行 java 程序并将输出文件更新到 EBS？ 我所在地区的网速太差了。
为什么不输出到S3？ 我的文件很小，但体积很大。EC2 到 S3 之间的传输速度令人无法接受。我甚至尝试了 s4cmd，但传输速度仍然令人无法接受。
为什么不将相同的 EBS 卷安装到 2 个 EC2 实例上？ 我认为这是一种黑客行为。
所以我想切换到 EFS 并连接两个 EC2 实例。一个专用于运行网站。另一个按需实例仅在需要时运行 Java 进程。
我对 EFS 有以下疑问： 1) 我的 Java 程序能否以与 EBS 相同的速度将大文件输出到 EFS？ 2) Amazon 不会对 EFS 出站带宽收取额外费用。它有限制吗？
答案1
重要的提示： 自 2018 年 7 月 12 日起，EFS 允许您购买预配吞吐量。以下答案反映了此功能可用之前服务的行为。以前，小型 EFS 文件系统很容易被流量淹没，因为性能会随着存储数据的大小线性增加……因此，如果只存储几 GB，则对于某些未考虑到这一点的用例而言，有效限制太小了。
为什么不将相同的 EBS 卷安装到 2 个 EC2 实例？我认为这是黑客行为。
您无法将同一个 EBS 卷挂载到多个实例。但是，您可以从具有 EBS 卷的机器创建 NFS 导出，并通过网络挂载它。NFS 是成熟的技术，而不是黑客技术。事实上，从您的角度来看，这几乎与使用 EFS 相同，因为 EFS 确实使用相同的协议——NFS。
Amazon 不会对 EFS 出站带宽收取额外费用。带宽有限制吗？
“出站带宽”对于 EFS 来说不是一个真正有效的概念，因为流量严格地在 EFS 和实例正在访问它。如果您使用可用区域特定的终端节点正确安装它，则 EFS 和 EC2 实例之间的流量永远不会离开可用区域。
如果 Web 浏览器下载了 EFS 文件系统上的文件，则它必须下载该文件通过您的一个实例。因此，出站带宽实际上是 EC2 出站，而不是 EFS 出站。
EFS 和 EC2 之间的可用吞吐量（“带宽”）随着 EFS 文件系统中存储的文件总大小而增加。
Amazon EFS 使用信用系统来确定文件系统何时可以爆发。每个文件系统都会随着时间的推移以由文件系统大小决定的基准速率获得信用，并在读取或写入数据时使用信用。基准速率为每 TiB 存储 50 MiB/s（相当于每 GiB 存储 50 KiB/s）。
累积的突发信用使文件系统能够将吞吐量提高到基线速率以上。文件系统可以以基线速率持续提高吞吐量，并且每当文件系统处于非活动状态或吞吐量低于基线速率时，文件系统就会累积突发信用。
但无论文件系统有多小，都具有 100MiB/s 的突发能力。对于 10GiB 文件系统，您可以每天突发 7.2 分钟至 100MiB/s，或每天突发 28.8 分钟至 25MiB/s，等等。
你认为这不够的结论忽略了操作系统缓存。在你的 Web 服务器上，从 EFS 读取的文件可能保留在该机器的操作系统缓存中，这意味着一旦文件被提供给浏览器，Web 服务器可能不需要在下次下载时从 EFS 读取文件，而可能只需要检查它是否没有改变然后从内存中将其提供给浏览器。除非您禁用它，否则此行为应该是自动的。
奇怪的是，亚马逊将数据大小与流量联系起来。我可能只存储了很少的数据，但这并不意味着我的出站流量也会很低。
这并不奇怪，因为存储数据的大小是影响定价的唯一维度。 EBS 卷通常类似——卷越大，该卷提供的 MiB/s 和/或 IOPS 吞吐量就越大。
再次强调，不要将应用程序的出站流量与后备存储的吞吐量相混淆。这两个值没有紧密的相关性。
对于较小的实例，实例的特性实际上更有可能成为限制因素。例如，t2.small 实例只有 31.25 MiB/s（250 mbps，0.25 千兆位/秒）的可用带宽，因此性能上限不会是文件系统。
使用 EFS 试用您的应用程序并观察文件系统的 CloudWatch 指标。每个工作负载都不同，这实际上是知道它是否能按预期工作的唯一方法。