从 AMI 启动应用程序时，我们注意到响应时间增加，请求超时错误率增加，然后慢慢减少并恢复正常。我认为这是由于 EBS 延迟初始化（EBS 的一个有据可查的性能特征）造成的。该应用程序具有 24 GB 的 EBS 数据量。
我尝试增加实例大小，但没有发现任何差异。因此，为了找出性能瓶颈，我退后一步，对不同的实例大小运行了一些基准测试，试图找到性能最佳的实例大小纯 EBS 初始化性能，假设这可以作为“在应用程序正常使用期间使用延迟初始化的性能”的良好代理。
然后我遇到了一个大惊喜：
实例执行的操作与!t3.medium相同。c5.18xlarge
怎么会这样？
我正在使用fioAWS 推荐的命令这里：
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 初始化？
更新
- 向 VPC 添加 S3 端点没有什么区别。
- 当我将 EBS 卷大小增加到最大 10,000 IOPS（即 3333 GB）时，速度会上升到大约 45 MiB/s。目前我只在 c5.18xlarge 上进行测试
答案1
背景
EBS 快照存储在 S3 上（这在您上面提供的链接中有记录）。当您还原快照时，它会在需要时从 S3 中提取块（记录在这里，复制如下）。
从现有 EBS 快照创建的新卷在后台延迟加载。这意味着，从快照创建卷后，无需等待所有数据从 Amazon S3 传输到您的 EBS 卷，然后附加的实例就可以开始访问卷及其所有数据。如果您的实例访问尚未加载的数据，卷会立即从 Amazon S3 下载请求的数据，并继续在后台加载其余数据。
再次更新想法
正如 Michael 在下面指出的那样，这里的瓶颈可能在 S3 和 EBS 之间。我很惊讶它的速度如此之低，只有 35MB/秒，也就是 280Mbps，但我猜它正在检索单个 S3 对象。S3 可以承受巨大的带宽，但通常有多个对象。
根据 Michael 的说法，我认为您必须忍受这种相对较慢的恢复。您不必预热卷，您可以让它按需发生，并在实例启动的最初几分钟/几小时/几天内承受影响。
答案2
回答：EBS 快照的初始化速度不受 EC2 实例类型的影响。
截至 2018 年 12 月 1 日。
显然，42 MiB/s 是从 EBS 快照到单个 10,000 IOPS 卷可以实现的最大预热/初始化速率。虽然速度不受实例类型的影响，但在较小的卷（100 IOPS）上会降至 35 MiB/s。速度也不会受到 VPC 上存在 S3 端点的影响。
相比之下，绕过快照过程，直接从活动 EBS 卷复制到另一个 EBS 卷，在 r5d.large 实例上以 128 MiB/s 的速度执行，单线程，使用管道tar|pv|tar，通过 ext4 文件系统。