AWS 建议将数据和操作系统保存在单独的 EBS 卷上。我有一个使用 EBS 卷在 EC2 上运行的网络服务器。在裸机上，我安装了以下内容：
- webserver, wsgi, pip & related software/config (some in /etc some in /home/<user>)
- server code & static assets in /var/www/
- log files are written to /var/log/<respective-folder>
- maintenance scripts in /home/<user>/
数据库服务器是独立的。对于网络服务器，以上哪些项目会受益于更高的 IOPS，哪些项目无关紧要？我的理解是服务器代码和日志文件应该移动到具有更高 IOPS 的单独 EBS 卷。还是应该将我所有的东西（除了我安装在 /etc 中的软件，即网络服务器）移动到具有更好 IOPS 的单独卷？
我建议您为代码、日志和维护使用单独的 EBS 卷，以防您需要将其移动到另一台服务器。与构建整个服务器相比，这可以让您获得更快的 TTR（解决时间）。
代码不应该在过去的部署中发生很大变化，因此我将在这里专注于通用 SSD，并着眼于缓存层（Varnish（整页缓存）和 CDN（静态资产））而不是磁盘 I/O 问题. CDN 是一个快速的胜利，并减轻了大多数用于读取静态资产的 I/O。在 50GB 时，您可以获得 150 IOPS，并减少静态资产；I/O 应该没问题。
至于日志，如果你是一个高流量的站点，那么你绝对应该关注这里的 I/O，因为你不希望这里有阻塞 I/O。这主要关注访问日志而不是错误日志，因为这些日志不应该超过生产系统上的错误级别。如果您的流量不高，那么使用通用 SSD 应该没问题，在 10GB 时，您可以获得 30 IOPS，这通常就足够了。
您的维护脚本在做什么？如果他们正在生成和输出文件，那么您可以使用 SSD，但如果您需要高 I/O，您应该重新访问代码并优化代码，因为这些磁盘可能会变得昂贵，而且这种成本对于间歇性运行的维护通常是浪费的.
至于您的 Web 服务器等，它应该基于基础架构即代码，通过 OpsWorks 或 Puppet，并且在 I/O 方面不需要太多，因为一旦构建和部署这些通常是基于内存的进程。