云 / 系统
选择 EFS 吞吐量模式，不是比较哪个标称数字最大，而是看容量模型是否适合实际负载，以及团队能否把握它的成本和故障风险。
Amazon EFS 提供弹性、预置和突发三种吞吐量模式，适合不同的需求。
突发模式：容量随存储量变化
如果吞吐量需求随 Standard 存储量一起增长，而且高负载之后有足够的低负载时段补回积分，突发模式通常很合适。它经济、简单，但小文件系统能够长期维持的基准吞吐量可能比预想低得多。
只有存储量和吞吐量需求确实同步增长时，才适合选它。已经积累的积分，不是永久容量。持续下降的 BurstCreditBalance 就是在提醒负载与基准不匹配。
弹性模式：容量随实际负载调整
弹性吞吐量会自动适应负载，不使用突发积分。AWS 建议将它用于突增或难以预测的需求，尤其是平均吞吐量远低于峰值时。这样就不必担心积分耗尽，也能减少容量规划的工作。
代价主要在费用上：弹性吞吐量按用量计费，过多或管理不善的 I/O 仍会推高支出。应监控 MeteredIOBytes、设置预算，并排查意外的需求，不能把自动扩展理解为不再需要管理。
预置模式：按明确需求分配容量
预置吞吐量不依赖文件系统大小，而是提供选定的吞吐容量，适合持续需求明确或平均值较接近峰值的负载。优势是可预测，前提是定期复核配置是否仍然合适。
配少了会受容量限制，配多了则浪费费用。当实测数据足够稳定，能支持明确的容量承诺时，这种模式最适用。
实际怎么选
- 使用 Bursting 存储量能合理反映吞吐量需求，低负载时段足以补回积分，而且日常运维会监控积分余额时。
- 使用 Elastic 需求不规律、峰值难以预测，或值得用按量计费来避免积分耗尽风险时。
- 使用 Provisioned 需求已知、相对持续，而且不取决于存储数据量时。
切换前后，都要测量
改模式之前，先记录基准指标、预期峰值与平均需求、积分趋势和应用延迟。更改之后，用同样的指标对比，再查看费用。AWS 也规定了切换到或调整预置吞吐量后的一些时间限制，操作手册中应写清适用条件。
一句话概括
存储量能反映需求时，可以考虑突发模式；负载难以预测时，弹性模式通常更省心；需求稳定且可测量时，预置模式便于按需配置。无论选哪种，都要让容量限制清楚可见。