从 AMI 启动应用程序时，我们注意到响应时间增加，请求超时错误率增加，逐渐减少并恢复正常。我认为这是由于 EBS 延迟初始化（EBS 的一个有据可查的性能特征）。该应用程序具有 24 GB EBS 数据量。
我尝试增加实例大小并没有发现任何区别。因此，退一步尝试隔离性能瓶颈，我运行了一些具有不同实例大小的基准测试，以尝试找到具有最佳纯 EBS 初始化性能的基准测试，假设这将作为“性能”的良好代理在正常使用应用程序期间进行延迟初始化”。
我遇到了一个重大的惊喜：
实例执行t3.medium与c5.18xlarge!
怎么会这样？
我在这里fio使用AWS 推荐的命令：
sudo fio --filename=/dev/nvme0n1 --rw=read --bs=128k --iodepth=32 --ioengine=libaio --direct=1 --name=volume-initialize
（针对设备 /dev/nvme0n1 进行了修改）
较大实例的网络性能名义上是较小实例的 5 倍（25 Gbps 与“高达 5 Mbps”）。
两者都以大约 35 MiB/s 的速度前进。
额外问题：哪种实例类型将为我提供最快的 EBS 和 S3 性能，包括从快照进行 EBS 初始化？
更新
- 将 S3 终端节点添加到 VPC 没有任何区别。
- 当我将 EBS 卷大小增加到最大 10,000 IOPS（即 3333 GB）时，速度会上升到大约 45 MiB/s。我现在只在 c5.18xlarge 上进行测试
背景
EBS 快照存储在 S3 上（这记录在您上面提供的链接中）。当您恢复快照时，它会在需要时从 S3 中提取块（记录在此处，复制如下）。
再次更新想法
正如 Michael 在下面指出的，这里的瓶颈很可能在 S3 和 EBS 之间。我很惊讶它是如此之低，只有 35MB/秒，也就是 280Mbps，但我猜它是从中检索的单个 S3 对象。S3 可以维持巨大的带宽，但通常具有多个对象。
根据迈克尔所说的，我认为你只需要忍受这种相对缓慢的恢复。您不必预热卷，您可以让它按需发生，并在实例启动的前几分钟/几小时/几天内承受冲击。
答：EBS 快照的初始化速度不受 EC2 实例类型的影响。
截至 2018 年 12 月 1 日。
显然 42 MiB/s 是从 EBS 快照到单个 10,000 IOPS 卷可以实现的最大预热/初始化速率。虽然速度不受实例类型的影响，但在较小的卷 (100 IOPS) 上速度确实下降到 35 MiB/s。速度也不受 VPC 上存在 S3 端点的影响。
相比之下，绕过快照过程，直接从实时 EBS 卷复制到另一个卷，在 r5d.large 实例上以 128 MiB/s 的速度执行，使用
tar|pv|tar管道，通过 ext4 文件系统。